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.

2 Responses to You Can’t Break it Down Until…

  1. says:

    Agile boat building.

    Floating box.
    Build a better bigger floating container. Now more kids want to get in.
    Add more to the better floating box.
    Expand the boat (now called a boat).
    Add a small state room to the small boat.
    Meanwhile you have a playhouse and about about five boats in less time. Yeah you don’t have a boat that you dreamed of yet. Maybe you want to build something else now.

    Not quite sure if what your saying is agile. Looks like water fall.

    Jonathan Bricker | Applications Developer, Fisher FIRST 2.0 Development | Fisher Division
    Emerson Process Management | 301 S. 1st Ave | Marshalltown | IA | 50158 | USA
    T +1 641-754-3605
    H +1 641-366-3991

    • Tom Perry says:

      Yes, it is definitely not iterative 🙂

      I like your idea – it’s good. In some sense, that’s what I did, namely build a smaller boat first. So that much was iterative. However, given the plans that I was using, and my own ignorance of boatbuilding it was hard to see the opportunity for iteration (not impossible, just hard to recognize). Two things would have helped that: A plan that incorporated iteration, and a little more experience with the process (apparently one little boat was not enough).

      So I like what you are suggesting. I learned that there are things that can make iteration hard, but certainly not impossible.


      ps. The little boat is now a playhouse, and I’m working on building my third boat…but don’t tell my wife!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: