Monday, April 27, 2009

Higher Agile Project Performance...

Recent VersionOne user forum discussion:
How to yield higher agile project performance? Should we implement one agile method, such as scrum, and follow process rigorously, or mix with different agile methods?
I'll paraphrase my response:

As mentioned previously, I'm a believer in Shu Ha Ri. This means, follow the book until you know the why behind the prescribed actions. Do not modify the process unless you know what is removed with your proposed changes. Many people lose more than they gain if they change a process before it is fully understood.

Many waterfall projects could be successful if the team studied and followed the PMI process as documented. Agile will be corrupted just as quickly as waterfall if people keep bastardizing it blindly as they have been. If you are interested in expert opinions on bastardized agile process, check out Jeff Sutherland's view's on ScrumButt and the Nokia test.

My proposal: apply Scrum for people, business, team, project management improvements or apply XP for engineering practices and technical quality issues. You could apply both simultaneously, though this might increase risk with too much change at once. Scrum requires a top down implementation, while XP should be a bottom up implementation (I'm speaking of the top/bottom of your organization).

Eventually, you can yield a higher agile project performance with a blended process approach based on your environment, but you can't jump directly there in the beginning. Also, the person driving your Ri level approach should be experienced (not just trained) in the things being blended. If you do not have this person, then the changes need to be a gradual evolution (one per iteration) allowing for correction.

I would debate that the average team should get through twelve iterations before trying to tweak this. For one month iterations, this is a year. For two week iterations, you might be ready after six months. Why base this on number of iterations and not time? Because you should be learning with each cycle and improving from your retrospectives. Agile is about learning and adapting, not practicing (or feeling pain) over time.

The last option I would throw out is that you don't implement anything by the book... you simply add one practice every two weeks or month. The practice added is one that addresses your biggest pain of the moment. Over time, you will back into a blended agile process that works well. Unfortunately this requires two things... lots of time and patience, and someone with experience to make the right selections at the right pace and help the team implement it in isolation of the rest of the practices. I've seen this work only where the person driving has had experience with a successful multi-year mature agile implementation in the past. If you are going to choose this path, I would suggest the following sequence: retrospectives, standups, large visible charts. Why would you choose this path? Because nobody has bought into agile and you just want to solve the current problems with agile patterns.

No comments:

Post a Comment