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)

Tuesday night #xtc after the innovation games

I was talking to @benjaminm and telling him how excellent I thought his rendition of the red bead game was. And I was also talking to him about how I thought John Seddon's ideas were great but that I didn't think telling people that they were stupid (which is what he seems to do in his talks) is a particularly effective method of helping them change. Benjamin said that Seddon doesn't do that when he's actually consulting. He keeps quite and tries to find people that he calls "curious" members of management that might not be so hypnotised by the system that they're in that they can't still be interested in the actual problems of the work.

Benjamin seemed to like the comment I'd made at the red bead game about the RBG being a way of teaching Learned Helplessness as it's described in Seligman's book. I wondered if the people that Seddon finds in big organisations are the people who refuse to learn helplessness - just as about one third of Seligman's miserable electrocuted dogs refuse to learn it. I also talked about "The Psychology of Military Incompetence" and how some people must somehow manage to not get crushed by what Dixon calls "bullshit" otherwise we would never get any good military leaders.

Oh dear, sounds like I did most of the talking.

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

Comments on John Seddon's Re-Thinking Lean Service

We'll cover the differences between failure demand and value demand, and how you might look harder at the nature of demand in your organisation in my course on 27th November - "Building the Lean Web Development Team"

Things I get out of this Podcast, my instinct was right. In order to get the best out of the Toyota Production System, you have to stick with the meta-principles. The details, about how to build cars of the rate of demand, rather unsurprisingly don't apply to software development - or web development.

His major insight, which doesn't attack "genuine" lean thinking, but which completely alters the way that it's implemented in software is saying that the Toyota Production System was shaped by the shape of demand. Curiously, although Womack and Jones and Taiichi Ohno talk about the nature of the economic cycle being the reason that Taiichi Ohno approached building cars in the way he did, Seddon doesn't mention this. But this is important as well. It's what I call the "Delta Blues" it's not enough to know what demand is now, or what it has been, you need to know how it changes over time. Is there a pattern? This isn't the stock market. Previous performance is a guide to future performance.

The other major, contribution of this piece which is especially important for web developers is the distinction between value demand and failure demand. I see now that the lack of this distinction has almost made a nonsense of trying to implement Agile practices in a web development environment. When you're making things in a factory in a "traditional" way, a substantial amount of the work that you do is work that you've planned to do (value demand). In web development, when I sit in on sprint retrospectives, it turns out that about half of the work that was done in any sprint wasn't planned, it was reactive to the customers need, mostly because things hadn't gone the way they should have (failure demand). A large amount of this seems to be farting about with hosting, browser compatibility, caching causing old files to still be visible. All that kind of stuff.

Seddon's point is that if you really want to improve the efficiency of your service company (and lets for now, assume that a web development company is a service company) then you have to understand and tackle the failure demand and set up systems to deal with it. There's hardly anything about this in Agile, there's nothing about this that I've seen in the writing about Lean for software.

One thing that you can do, which I'm certain is not being done, is to train the people who field the reports of failure demand in the technologies and techniques that they need to deal with the most common failure demand problems.

What Seddon says is that you have to look hard at your business and see what the crucial problems are. Then you have to try to find solutions. One of the ways to find solutions is hypothesis testing - try a bunch of different solutions, but make it clear to yourself what solutions you are trying and that they are just hypotheses.

Some counter-intuitive things that emerged form Taiichi Ohno's investigations which probably do transfer to services is that end-to-end time is cost, not activity. So many companies that I go into are obsessed with keeping their designers and programmers busy the whole time. Even some of the programmers and designers don't like to be seen to not be scheduled at capacity, or over-capacity. Some managers have seriously said to me that they don't think their developers will work hard enough unless they schedule for them far more work than they can possibly do in the time. Obsession with activity cost obscures the end-to-end cost. i

Some questions that you need answers to if you're a web development agency.

• What is the normal relationship between value demand and failure demand? I.e. If a project seems to be a "£10K" value demand project, how much failure demand will it generate?
• What is the nature of that failure demand? How much of it is preventable through changes in procedures?
• What is the pattern of demand throughout the year? Even over the years? What can you do in times of low demand to improve the performance of the company?

Some criticisms of Seddon's approach. He's an academic. So he assumes that everybody else in the world is stupid. I think most of the people I meet are pretty smart and doing the best they can with the information they have. Telling people that they're STOOPID just doesn't work as a consultancy approach. But for me, having thought about this a lot over the last few years, his analysis is compelling. I think the division between value demand and failure demand is absolutely crucial for web development companies to understand.

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