ALM and Agile

In talking with James about a presentation around application lifecycle management (ALM), I got to thinking:

1. What really is ALM apart from project management tooling? One of those “is this just a synonym for existing nouns, or a new noun” questions. I’m not naive enough to think that there’s a black and white answer. That said,
2. Along those lines, can you have ALM apart from process? Where do you get the process from? Rational ha[s|d] a nice setup with RUP and their suite. I still see RUP posters in people’s offices and they certainly set the definition for what software development was at the time.
3. Does ALM work in an Agile world?

Agile ALM

The third question is, of course, what I’m interested in. It seems to me that there are only best-of-breed tools available for “Agile ALM.” Microsoft seems to have internalized Agile in it’s process (at least that I’ve seen) and tools…but that leaves out all the non-MSFT developers. And, to be fair, I’m not expert enough on the Microsoft dev world to say they have good Agile tooling or not. Once IBM’s Jazz comes out, we might have another contender on our hands.

In the meantime, if you wanted one suite of applications that worked together, I’m not sure you could point at any one vendor or OSS duct-taper. The important thing with any tool is to avoid a Conway’s Law effect: the tool an organization uses will determine the architecture of the software it produces.

I always end up leaving out projects and vendors I know and/or don’t know in lists like these, so apologies in advance. I know there are OSS ones I’m leaving out. We’ll see you in the comments!

Beyond Excel

That could be one reason many Agilists prefer the Excel method of product management, along with post-it notes and whiteboards. If that works, I say do it. But, for distributed and fuddy-duddy teams/management, that battle can be taxing to win. It’s like everyone’s favorite distracto-fight: Enterprise Ruby, sub-titled both, “we don’t need no stinkin’ transactions and other ‘fightin’ words'” and “it will never scale as well as my filing technique.”

Which ever side of the river you choose, it seems apparent that there could be better suite level tools for doing Agile software development. I used Rally while I was at BMC and had mixed feelings about it: it got the job done, but I felt like it was too heavy-weight and RUP’ish at the time. To be fair, it’s been almost a year since I last used Rally. They may have changed quite a bit.

Agile Problems Looking for an ALM Solution

What would an Agile ALM suite have? These are the issues you’d need to sort out:

• Stories – the requirements/use cases of Agile. Gathering effective stories is one of the most difficult things for organizations to figure out how to do correctly. The tools often do not help. Input for these comes from everyone, including customers. See FiveRun’s use of BaseCamp (or CampFire?) right in their product to gather user input.
• Tests – acceptance tests (as opposed to unit tests) are the way that stories are verified. QA should write these once a story is written. If you can’t come up with acceptance tests, something is wrong with the story.
• Code – software is code, afterall. Developers need unit tests, to be able to link their work to stories and acceptance tests and to be able to answer the question every morning “what did I do yesterday?” Developers hate numbers being associated with their work unless that number is high dollar figure. The tool should address that cultural fact.
• UI – Agile has not addresses how usablity is involved in software too much. As we know, “pretty is a feature.” I’ve seen UI people struggle with how to fit in the process. Tools could help.
• Tech Pubs – the situation is even worse for documentation folks. DITA and wikis may help.
• Management – while Agile may look to be “stealing” jobs from management, it’s actually pushing down work where it can be done more effectively. Management becomes less planners with big sticks and more team champions with big sticks, and facilitators. As the Army saying goes, “the Army is run by it’s Sergeants, not officers.” Long term, I suspect this means that management and product management will merge in software, the end result being much different than those two roles separated, as they are today. As middle-management is both the biggest help and impediment to change, this is where the fastest gains and potential problems can be. How can tools make management feel better about change?
• Operations – in reality, most operations people don’t want to update their software every 2 weeks…or 4…or 52. The answer to this is more of an architectural one than anything else (plugins vs. “whole” versions of the software), but any ALM tool will need to facilitate that kind of development. How does any ALM tool help make a plugin?

The point of differentiation between existing tools and the dream Agile ALM Suite would be integration between the different tools, processes, and people involved. Many tools, like the Jazz demos we’ve seen and some of SameTime’s offerings (both from IBM) have potential for that kind of integration. Eclipse Mylar looks like a good platform as well.

Given that context, what would it look like? I suspect it’d be very similar to Web 2.0 technologies behind-the-firewall as both come from the same abstract principals of…people over process.

Disclaimer: FiveRuns, IBM, BMC, and Eclipse are clients.

Tags: alm, jazz, eclipse, mylar, sametime, suite, prjmgmt, techpubs