Experience Reports from the Agile Trenches: What's Really Working, What's Not Working, and Why

A couple of weeks back, I was invited to speak at the Rational Software Conference 2009.

I had the pleasure to to take part at the Experience Reports from the Agile Trenches: What's Really Working, What's Not Working, and Why panel hosted by Scott Ambler.

It was a great opportunity for me to discuss my experiences in deploying agile techniques and tools as a part of Deloitte. The panel was attended by Mark Lines, Nate Oster, Anthony Crain, Scott Ambler (facilitator), Jeff Anderson, Shawn Hinrichs, and Matt Heinrich.

There were a lot of interesting questions raised by the audience, some of these include:
1) how do you deal with agile in a regulatory environment?
2) how does agile work in distributed/offshore scenarios?
3) how do you address skeptical business owners that agile can work?
4) where does agile work? And where doesn't it?
5) How does agile work on large teams?

Rather than go through the specifics of each question-and-answer, I thought I would point out what I thought was the most interesting disconnect between the answers given by the members, including myself.

Basically, the panel could be divided into individuals with a more Unified Process oriented bias, and those that seem to follow a more pure form of agile. (I fell into the latter camp.)

One perspective raised by Anthony, was that there was nothing really wrong with the way the rational unified process works in its current form. The agile counterpoint was that rup, when performed incorrectly, resulting in a overly complex, waterfall style approach.(okay a mini-waterfall)

Some members of the rational Camp (**ahem** Anthony) didn't particularly see any issue with this. They raised a valid point that that many software organizations currently are performing using a macro waterfall strategy. They typically deploy software every 3 to 4 months. Getting them to use the rational unified process and employing every 6 to 8 weeks is a huge improvement.

For my part, I can't disagree with this, but, a miniature waterfall is not the best way to be agile. more importantly,IMHO this is missing the point of trying to be agile in the 1st place.

Agile and lean development processes are implemented because of their potential to reduce waste. According to lean manufacturing principles, inventory is one of the biggest causes of waste and inefficiency. In software delivery terms waste is expressed as unfinished code, which can be expressed as:
1) documentation representing code that is not in production
2) a particular branch of code that has not been merged into the trunk
3) code that is not being used by users

I'm sure I've forgotten a couple of examples, but the point is plain, artifacts that are developed can quickly become a source of inefficiency if they lay around too long. The sooner you can take an idea and get it through the lifecycle than the less "secondary artifacts" you have to manage, these include change requests, defects, test cases and the list goes on and on and on...

of course, this doesn't address my major issue with the RUP. Namely that it simply, is just too complicated. Of course, rather than reiterate all my issues with the approach, I invite any reader to take a look at my article on the pros and cons of the rational unified process for more details.

Also, I recommend taking a look at how I combine agile and RUP to create a process that is both agile and scalable.

I also had a conversation with one of the panelists afterwards (okay it was Anthony again), who rates the comment that agile wouldn't exist if we were able to understand RUP in the 1st place. I think the important point here, is that products whether they be methodologies, software, or something else, need to be simple, and well understood by consumers in order for them to be effective. This is another point that is fundamental to agile that I think is lost on many within the RUP, things sometimes need to be complicated in order to be effective, but taking simplicity as a value in taking every effort to work towards simplicity is essential to creating any effective product, especially a software development lifecycle framework.


That all being said, RUP, and the unified process in general is still one of the best families of software processes out there. Let's hope it keeps receiving criticism, and improving as a result.