You Can’t Break it Down Until…
One of the first things that agile or iterative development demands of us is that we should break down our work into very small chunks. This challenge is one of the first hurdles faced by teams that are adopting sprints and trying to make all of their work fit into a tiny little 2 week time box. I’ve seen it over and over again. The first question folks ask is, “How can I break this down into pieces small enough to fit in the sprint?” I often get reactions that range anywhere from frank denial to outright disbelief. It just can’t be done!
I know. I get it. I really get it. The first time you deal with breaking down a big project is like running into a cognitive wall. I remember the first iterative project that I did. I understood the model. The concepts made sense: break things down into small chunks and then iterate. Easy. Only it wasn’t. I remember sitting in front of my monitor thinking, “What meaningful piece of functionality could we do in a sprint?”
Nothing came to mind.
It was dreadful. We were working on a new product, something completely new to the market. I had no idea what I was doing. That’s not to say that I was incompetent. Far from it. I knew that I didn’t know much. In the end, we overcame the challenges on the project and I conveniently forgot most of those lessons and moved on. Typical.
I had another reminder the other day. Recently I finished building a boat. Truth be told, this was one of the largest personal projects I’ve ever accomplished. It took me nearly three years to build the boat from boards-on-the-floor to sailing off the boat ramp. That’s a long time, but it’s a big boat. I’m quite proud of my accomplishment, but there is one thing that sort of bothers me: building a boat wasn’t a very agile process.
What I mean is there wasn’t much opportunity to iterate or deliver in an incremental fashion. Boats are funny like that – if you take to the water before the boat is ready, you run the very real risk of sinking your ship. Three years is a long time to go without honestly knowing if a boat will float.
There are some very good reasons it took so long:
1) This was not a team effort. It was just one guy. I’m good, but I’m not a team. It’s harder to iterate quickly on complicated work without a team. We can put this under the heading of “Obvious.”
2) I didn’t know how to break the problem down into smaller, meaningful pieces. Fundamentally, I didn’t understand the problem well. I didn’t have much experience with boat-building or woodworking. It’s hard to iterate when you don’t understand the problem domain well.
3) The plans and design were not arranged with iteration in mind. There were no intermediate steps that would allow incremental delivery. There was not even a halfway point to check and see if the boat just floats. It’s hard to iterate if the design and plans don’t allow for it.
4) There wasn’t enough experimentation. Good boat-building and construction usually incorporates frequent re-measurement and “test fittings”. The old saw, “Measure twice, cut once” certainly applies here. I made a lot of mistakes and they cost me time. It’s harder to go fast when you aren’t testing and experimenting.
I attribute much of the difficulty with breaking big projects down to these four key reasons above. You can overcome these issues with time and experience (your own or someone else’s). In my case, it took me a while.
However, after 3 years of working on that boat in my garage, I now find myself doing something completely different. Now I can wander out and create a long list of tiny tasks quite quickly and spontaneously. I know much more now. I can see hundreds of little tasks that need to be done. Little stuff, literally just a few minutes of work. I spent most of my time measuring and trial fitting. Lots of little experiments and more than a few failures. I’m much more successful that way. So I guess there is an agile way to build a boat – it just took building a boat to discover it.