The shortest amount of time that could possibly work – shrinking your iterations

It’ll never work

It’s hard to believe this with my looks, but back in Liverpool I sang and played guitar in a band. One day, in rehearsal we were working on a new song, and I asked the guitarist to play an unusual arrangement.^[1] His response was, “it’ll never work – the chords are going to clash together.”

Now bear in mind, at this point we are in a rehearsal room, with guitars strapped around our necks and plugged into amplifiers. It would have taken thirty seconds to try this out and see (or in this case, hear) whether or not it worked, but instead a long argument about music theory ensued. Eventually we played it, and it worked.^[2]

In retrospect, to get the guitarist to try out the idea, what I should have done (instead of arguing about music theory), was to say, “you know, you might be right, but let’s try it – if it doesn’t work, we’ll know pretty quickly and we’ll try something else.”

A resistance to short iterations

One of the things I almost always find when working with customers is a reluctance to shorten their development cycles. Although they begin to adopt a lot of good development practices and are enthusiastic about the benefits of an agile approach, they’ve been conditioned over the years to think that there’s nothing achievable in a week or less, and they want to start out with iterations a month long or more.

This resistance to change was recently summed up by Mike “GeePaw” Hill as a case of the “Yabbits.”

Yabbitting is when people go through a sequence of resistance statements, where each statement begins with the words, “Yeah, but…”.

While Yabbits can be annoying, Mike goes on to state their value:

Yabbits don’t always, or even usually, represent real resistance to change. On the contrary, they are probes, whose intent is to test an idea’s prima facie validity.

A person who offers you yabbits is typically more open to an idea than a person who says nothing at all.

So when faced with this resistance, remember that these objections are often coming because people care and because they have real concerns. I should have been happy that the guitarist cared enough about how the song would sound, rather than just going along with my idea.

Often it is easy to show someone who is resistant to change a way forward by asking them to try something for a little while and show them that there is little risk in trying it out. This approach avoids getting embroiled in an argument about about some esoteric theory of agile software development (or music theory!) For some practices, the change may be perceived as risky, but for others, like shortening an iteration, or playing a new arrangement of a song, the risk is minimal.

The shortest amount of time that could possibly work

The problem with having long cycles (particularly when transitioning from a traditional approach to an agile one) is that the cycles tend to behave like mini waterfalls: most of the work gets done at the end of the cycle, the testers have most of the features dropped into their laps in the last few days of the cycle, and a lot of the real tools and practices needed for a sustainable pace (for example continuous integration, build automation, automated regression test suites and improved communication) often don’t happen early enough in the project for the team to get real benefit from them and ease their transition.

The benefits of a short iteration far outweigh the risks. The only real risk is that you won’t get much done in the iteration, and the overhead of setting up the iteration will be high. However, shortening the cycle means that you will not waste time in high ceremony activities, and any pain points or roadblocks will become evident very quickly. In addition, the risk of not achieving much soon disappears as you become much better at slicing requirements down into small but valuable features. You will also improve several techniques that will help you work at a sustainable pace.

To summarize, you will see the following benefits:

• Risks and inefficiencies are exposed earlier.
• High overhead activities like long meetings that don’t get you closer to your goal of releasing a valuable feature are removed or reduced.
• The team will work together, swarming on a single feature until it is complete, rather than continuing to work across many features in the traditional manner.
• Improved communication between the team and the business owners is necessary to keep the work flowing.
• Automation becomes a necessity, rather than a nice to have.
• Less temptation and opportunity to revert to old practices and do mini waterfall.

So given all of these benefits,  how short should an iteration be?

Ward Cunningham famously rephrased Occam’s razor when applied to software development as:

…ask yourself, “What’s the simplest thing that could possibly work?”

Let’s redefine an iteration in this way:

Ask yourself, “What’s the shortest amount of time that could possibly work?”

In other words, find the shortest time-frame in which you can get something of value to the business done.

How short is that? Almost certainly shorter than you think.

How do you get there? Luckily, several people smarter than me have some ideas.

The disappearing iteration meme

There has been a recent meme about shortening iterations, with several people blogging on the topic from different approaches.

Michael Feathers recently wrote about Zeno length iterations, where he proposes an experiment:

Suppose that you had an iteration of one week, followed by an iteration of 2 days, followed by an iteration of 1 day, followed by an iteration of one-half a day, and so on…

…you can deliver business value in shorter times than you can currently imagine.

From Michael’s perspective, one of the main benefits of short time boxes is that they force trade-offs and produce creative solutions. He concludes by saying:

Look at your product today.  If you only had one day to develop and deploy some feature, before putting the product on ice and letting it generate revenue as is forever, what would it be?

While I think Michael’s experiment is a little abstract, the point he is making is that you can deliver value with very small chunks of code – smaller than you think today.

Kent Beck recently proposed a different experiment in extremely short iterations, for a different reason, continuous deployment immersion:

Get the whole team in a conference room Monday morning. Choose a feature you are going to add. Have one person come up to the one machine in the room. Write one line of code. Deploy.

If you can’t deploy, erase that line of code and write a different line of code first. Deploy.

Once the deployment is done, write another line of code. Deploy.

About this time some of the rest of the team is going to be bored watching all the manual steps in the deployment. Have them go off and automate the most tedious, boring, or error-prone step. Bring the automation back to the conference room and start using it.

Kent suggests that by doing this, you will start to automate your deployment, automate your tests and understand a lot more about slicing up your features into smaller chunks.

By Friday afternoon you may not have made much progress on your feature (but you may be pleasantly surprised), but you will understand deployment much better than you do now. You will also understand how to slice development more finely and rearrange the pieces. You will also understand the value of automation.

He also (with tongue in cheek) concludes that it’s a crazy idea, but in reality, there is also a lot of value here. Forcing everyone to think about where their pain points are and making the pain points happen often (due to shortening the cycle) means that the team will be motivated to remove and automate those pain points and ultimately work more efficiently.

James Shore and Arlo Belshee also recently gave a very entertaining talk at the Lean Software and Systems 2010 conference, entitled “Single-Piece Flow in Kanban: A How-To.”

In it they propose stripping down a lot of the complexity of Lean and only having two queues, On Deck, and In Progress.

Ideally, only one item (Minimum Marketable Feature, or MMF to use Lean terminology) would be in progress at any time. Instead of moving the MMF through the traditional production line of Kanban (for example, through requirements definition, story queue, development, testing and deployment), you instead create a detective’s blackboard by putting all of the information about the MMF onto the board. The name comes from detective TV shows, where all of the information about a crime is displayed on a blackboard. This information might translate to tasks or information about the feature.

The whole team swarms on this single feature until it’s completed and then it is removed from the board and the next item added from the On Deck queue. What is fascinating about this talk is that while Jim and Arlo disagree about some details and definitions (including their definitions of an MMF), they both agree that this is a more efficient way to build software.

Try it!

While there are several approaches to shortening the iteration, or taking a Lean approach and not having iterations at all^[3],  the best approach for you is the one that you try. Whether you take Michael Feathers’ approach of shortening the iteration length to find a workable minimum, Kent Beck’s approach of starting with a single line of code at a time, James Shore and Arlo Belshee’s Lean approach of swarming on a single feature, or some other means doesn’t really matter. What does matter is not being scared to shorten the cycle until things are a little uncomfortable and real work needs to be done to make efficiencies such as automation or continuous integration, or coming up with creative ways to solve problems and chunk up work.

Don’t get bogged down in figuring which way will be the best to shorten your iterations – that is like arguing about music theory when you have guitars in your hands. Instead, just pick an approach and try it.

You’ll soon arrive at the shortest iteration that works for your team, and it’s almost certainly shorter than you think.

And before you become a Yabbit and say “it’ll never work” ask yourself this: “what’s the risk?”

1. For the music geeks amongst you, one guitarist would play the three chord trick in the chorus, and the other guitarist would play the relative minor chords at the same time [↩]
2. We recorded the song some time later and I think that those chords played together still sound rather nice [↩]
3. For more information on Lean and Kanban development, read Jeff Patton’s excellent post, Kanban development oversimplified [↩]