Brownout on Agile Boulevard

Watching the tweets from #xpdays leads me to think that there is strong and growing interest in Agile and Lean Methods. I think this is a good thing.

But there is a problem, and the problem is confusion. There are a lot of supposedly ″different″ Lean and Agile methods and each one comes with an army Lean and Agile Coaches, Consultants and Trainers, all claiming that their method and their method only is the best.

The result of this confusion seems to be what I have called ″Agile Brownout″.

″Brownout″ is a term that used in countries where the electricity supply is less than perfect. A brownout isn't a black out. All the lights don't go off. But because too many outlets are drawing from the same source, all the lights go yellow and dim. And in the Lean/Agile field it seems that now there are more lights drawing on the grid than at Blackpool 'luminations. Scrum/XP/Lean/Kanban/TDD/BDD to name just a few.

The solution to this problem for many consultants seems to be to shout very loudly and insist that all the other lights should be switched off. Theirs is the one true light and it can only made to shine by extinguishing the others. My solution is a little different. To struggle on with the metaphor, my solution is to point out that:

depending what it is you want to see, you probably want to use a different light.

To my mind, each of the delineated Lean/Agile methods tends to have a niche where it works best. But for any kind of project, there's probably a bit of each that could be useful. Really, if you're a project manager, you owe it to yourself to check out what each of the methods offers. Since my specialist focus area is on tiny-to-small-to-medium sized web development teams, I'm just going to run over what I think are the good bits from a range of approaches.

PRINCE2

This is the language big organizations speak. You have to write the kind of documents that PRINCE2 recommends if you're ever going to have a chance of pulling down any big money for a project. And as a means of reporting progress on a project back to a big organization. But that doesn't mean you have to use this method to manage development for that, you should use scrum.

Scrum

Daily stand-up meetings, regular sprint planning, demonstrations and retrospectives are all good ways of managing actual development and tracking its progress. Extracting stories into a prioritized, effort-estimated backlog is enormously valuable by itself, if you institute no other Agile practice. Even if a team is working on multiple projects (as web development teams often are) the relief of stress and increase of focus that instituting this kind of basic management can produce is still powerful and heartening (and surprising).

XP (Extreme Programming)

Practices that are often labeled as Extreme Programming, such as TDD, Continuous Integration and Re-factoring are very useful if the software component of the web dev that you're doing is of any reasonable size or complexity. The thing to remember here is that any test coverage is better than none. And the emphasis on delivering working software at the end of iteration? That's gold.

Lean

For me, with Lean, it's the ideas and the huge benefits of an alternative view of what we're trying to do. Seeing web development as a value stream makes you focus on the value that you're delivering to your customer. This makes you look at the things you're doing day-to-day in a very different light. Focus on flow makes delivering (working? Right?) websites to the customer as soon as is absolutely possible a top priority and this in turn highlights obstacles. Remove those obstacles and you're in the money.

Kanban

Before you do anything else, limit the work in progress. I was especially impressed by David Anderson's point that you don't have to persuade anybody about the benefits of Agile methodologies to just start reducing the work in progress and seeing the benefits of that single move. Using a simple physical display to show everybody (including yourselves) what you're working on and limit the number of things that you're working on is almost equally simple and powerful.

John Seddon

This isn't a method, it's a person. It's worth reading his book if only to be introduced to the concepts of value demand and failure demand (slaps forehead). Why didn't I think of that? Seddon says you should try to solve the problems presented by the work and so, unless you're trying to make cars in Japan at the rate of demand, you're probably going to be solving a set of problems not directly addressed by the Toyota Production System.

I cover all of these approaches on my upcoming course ″Building the Lean Web Development Team″, running in central London on 20th January 2010.

For further information, contact mark.stringer@gmail.com (07736 807 604)