A few weeks ago I watched an Agile introduction course being run by my colleague. The course teaches about Scrum using Lego. Attending the course was a very persuasive “conventional” project manager. When some of the team had finished building their model cars and trucks (i.e. had completed their stories) and there were no more models/stories in the Sprint backlog, this project manager automatically assumed that more models/stories should be taken from the product backlog and added into the Sprint. The result was that at the end our Lego Sprint there was almost as much unfinished “work-in-progress” as there was finished work that had been planned at the beginning of the Sprint.
This week I ran the same course. The make-up of the team running the course was different, and there were no project managers involved. When it came to the point where some of the team members had run out of work, the team asked me what they should do. I don’t remember exactly what I said, but it was something non-committal that seemed to steer them away from bring any stories into the Sprint. The effect of this was very interesting. Team members who weren’t involved in building the final model (which was causing trouble, and in the end, wouldn’t be built by the end of the Sprint) started to do some other activities:
Tidied up the Lego that was laying around on all the desks.
Made sure that the burn-down chart and the Scrum board were up to date.
Watched the two team members who were still assembling a model.
(I can’t guarantee this but I think this might have gone on) reflected on how the Sprint had gone and wondered how they could make it better next time.
In an address to new graduates, the novelist, David Foster Wallace tells an old joke about three fish. Two young fish are swimming along and the meet an older fish swimming in the opposite direction.
“Morning guys, how’s the water?” Says the elder fish and swims off. One of the younger fishes turns to the other and says “What the hell is water?”
For the young fish, water is what Moshe Feldenkrais calls “the elusive obvious” - the thing that is so present that we don’t even notice it.
When we’re trying to do our best in software projects, we have to deal with a several of these “elusive obviouses”. What reared its head when the project manager, almost without thinking, added extra work into the Sprint was one of the most powerful and difficult to see. Something that I call the “Prime Directive”:
Everybody should be busy all the time.
From the point of view of Agile this interferes with, one, if not two, of Agile’s explicit values:
Working software (over comprehensive documentation)
Response to Change (over following a plan)
The emphasis on Working Software interferes with the Prime Directive because it insists that when you get stuck on a story, you stop, scratch your head and think. And then keeping thinking, maybe chatting to your team mates, go out for a breath of fresh air, chat to the people who are going to test it, until you figure out a way to finish it. So you can demonstrate it at the show and tell, so you can show progress.
The Prime Directive suggests that when you get stuck, in fact the moment you get stuck, you put down the thing that has caused you to get stuck and pick up something easier, just to make sure you keep typing at all costs (interesting phrase). Of course in software development, the only way to be able to do this is to mark the thing that you were stuck on as “Ready for Testing”, knowing that you’ll see it again in a few days’ time in the guise of a handful of defects. The Prime Directive also stops you lifting your head, taking stock, day dreaming a little maybe and thinking about maybe doing what you’re doing in a better way. It robs us of those valuable moments that Tom De Marco calls “Slack”.
What about Agile’s emphasis on Response to Change. How does this conflict with the Prime Directive? Well, let’s go back to our first Lego exercise where lots of work-in-progress - unfinished vehicles - at the end of the Sprint. What would happen if at the end of this Sprint there was a total change of direction on the project (and guess what? next time I run it, there probably will be). What if after being asked to build civilian vehicles for an entire Sprint, the Sprint end rolls around and now all of a sudden, there’s a war on (this can be arranged)? All of the vehicles that were started and not finished now start to look like what they are - waste. A waste of time, effort, money and spirit.
And in this scenario, what about the good things that didn’t spontaneously happen? Who’s going to tidy up the Lego? Who’s going to make sure that the burn-down charts and the Scrum board are up to date? Not only is it hard to see the Prime Directive, it makes you blind to other useful and powerful truths. Taiichi Ohno, of Toyota, who managed to construct the world’s largest and most successful car company (these are real cars) managed to see beyond the Prime Directive. The innovative approach that Toyota has to manufacture is sometimes described as “Learning to see”. They started to see having extra parts and partially constructed cars hanging around the factory that weren’t going to be sold for what it was - waste and began to focus on making cars at exactly the rate they were needed - just in time. They also started to see that if the workers who worked on the production line cleaned up their own stations, and the surrounding areas when they had “spare” time production line wasn’t moving the factory was cleaner, tidier and filled with less clutter.
It is very hard to see beyond the Prime Directive - one project manager this week told me that leaving people without specific work to do was “Not an option.” But if we can, the benefits are huge. Working software (stories that are really finished), a good understanding of where we are and the progress that we’ve made (updated Scrum boards and burndowns) and maybe, even, a tidy office.