Appreciative Inquiry

a colleague of mine has suggested a new approach towards getting delivery teams to improve the way that they do their work.

It's called appreciative inquiry, the basic idea is that organizations should spend more time focusing on what works, and expanding those practices, rather than focusing on the negative.

It's pitched as as being the opposite of problem solving, the following is a good writeup from Wikipedia.

"
AI focuses on how to create more of the occasional exceptional performance that is occurring because a core of strengths is aligned. The approach acknowledges the contribution of individuals, in order to increase trust and organizational alignment. The method aims to create meaning by drawing from stories of concrete successes and lends itself to cross-industrial social activities. It can be enjoyable and natural to many managers, who are often sociable people.
"

One thing that can be said about agile/lean practices is there is a huge focus on what's broken. Not on what is currently working, i.e. requirements up front or back, unfinished code leads to waste, untested code leads to fertility, etc. A different tactic using the AI approach would be a focus on the benefits of software in the first place, i.e. software leads to good agility abstraction for businesses in general, and use that as a metaphor to expand how we should be approaching delivery software for organizations in general.

Our team plans to use this approach on our next retrospective, I'll make sure to share the results here.

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.