Iterating is Costly

August 2, 2011

Agile development’s iterative philosophy sounds great: deliver working software in short periods of time (weeks), allowing the users and/or stakeholders to review the work and suggest changes. These changes get prioritized and incorporated into the team’s product backlog. If the changes are important enough, they get worked on in the next sprint (iteration).

So you iterate. The problem is, iterating is a rework strategy. If you are iterating, you are increasing the number of increments required to deliver the forecasted feature set.

As a new product manager, I’m in the process of recommending a change to one of our products under development. I found what everyone agrees to be a serious limitation, one that is going to cost us several weeks of rework to correct. A change like this introduces a certain amount of organizational anxiety, and it certainly torpedoes the timing of other go-to-market planning already in progress. People are grateful that I uncovered this issue, but no one likes making the payment.

How do you avoid this problem?

Keep it small, keep it themed. The product that we have under development will have future releases. We’re introducing something new, and early on it was easy to see all of the things that we could provide. And like most software projects, it was equally easy to underestimate what it would take to deliver a subset of those features, let alone what we now understand to be a series of releases.

By thinking too broadly too soon, we actually coupled functionality together that should have remained separate and distinct. As a result, we are now faced with the prospect of reworking our foundation; but if we are going to deliver the right product to the market, it is necessary to make this change now. We need to be solid on our delivery that is now encapsulated within a narrowly-focused, specific product theme.

Invest in paying attention. Prior to my assignment, we had a part-time product owner/product manager. This is an organizational fault, creating a problem of “continuous partial attention” that became amplified because this is not only a new product for us, it involves expertise that we had to build because the core capabilities of the product lie outside of our industry knowledge and experience. We needed full-time care and attention (and then some, based on my dance card), not part-time involvement.

Someone needs to be looking at the big picture, how the parts come together, assessing the impact of change on the product as a whole, and communicating. Once I determined that we had a problem, I worked with a variety of individuals across the organization to develop a solid solution, documenting it and communicating it so that everyone could understand it and buy into it.

The goal is to be as crisp as possible about the problem(s) that the feature is targeting before you develop it. It’s a judgment call, but there are times when you want to define as much as possible about the feature before you fully implement it. Build prototypes, communicate how the user interface will look and how the underlying software will behave and discuss it with users or stakeholders, and then implement it.

This leads me to my final point.

Create artifacts. Agile development does not mean “no documentation.” I’ve never been an advocate of writing requirements the size of War and Peace; heavier is not better. However, the act of creating key artifacts forces you to think things through. You should always document enough to capture your thoughts and make sure that they hang together – and that you can share your thoughts effectively with others.

Can you explain the product in few pages? How do the features work together at a high-level? Create artifacts that will be useful in training – they can be revealing. In my case, I found that our product had some constraints that weren’t really necessary, impacting the flexibility that we wanted to plug.

9 comments

Eric Krock said...

Nice article! I agree that iterating has a cost. Trying to fit demonstrable, user-facing pieces of functionality into fixed-length sprints can create extra overhead compared to going dark for a period of time and then coming back up.

The advantage I see to iterating, though, is that it prevents major disasters where you expect engineering to go underwater for 6 months and then come back up, and then at the end of 6 months they realize they need another 6 months, and so on ... I think the ongoing overhead cost of iterations is far more than justified by giving the organization reality checks at the end of every sprint so it knows sooner when it's behind schedule and can adjust sooner instead of later.

I also agree that reasonable artifacts can be extremely helpful for an Agile team. I look forward to your future posts!

August 4, 2011 at 2:22 PM
Dave Moran said...

@Eric,

Thanks for your comments! I agree, iterating does add extra overhead, but it can prevent major disasters as you point out.

My feeling is that sometimes, people get too casual with the iterative nature of Agile development, and the cumulative effect of a series of small iterative, re-working of functionality can add up. While you can't avoid a certain amount of re-work, making basic mistakes can contribute to re-work that could otherwise be avoided.

August 4, 2011 at 7:56 PM
Greg Gehrich said...

There is always rework because people and processes are not perfect. The only question is when it occurs.

Iteration pushes the rework earlier in the development cycle where it is less costly to fix.

August 19, 2011 at 10:55 AM
Dave Moran said...

@Greg,

Agreed, none of us are perfect. But I feel that there are options available to limit the amount (and cost) of rework, hence the motivation for this particular post.

August 19, 2011 at 5:32 PM
Regina Hilary said...

Thanks for the best blog.it was very useful for me.keep sharing such ideas in the future as well.this was actually what i was looking for,and i am glad to came here!
kids games free | games games | shooting games | tank games | apple shooter | stick war 2 | unblocked games

July 22, 2016 at 4:52 AM
2048 game said...

Wonderful blog! I found it while searching on Yahoo News. Do you have any suggestions on how to get listed in Yahoo News? I’ve been trying for a while but I never seem to get there! Many thanks.
2048 game | five nights at freddy's 4 | plants vs zombies | five nights at freddy's 3 | fireboy and watergirl | fireboy and watergirl 4||red ball | age of war

September 14, 2016 at 4:50 AM
Lisa Melisa said...

Your website is very attractive and neat. I expect this website to be more creative and innovative full thank you very much for the article you create, it is very nice interesting. obat polip hidung

December 1, 2016 at 10:21 PM
Ayu Martina said...

Your website is very attractive and neat. I expect this website to be more creative and innovative full. obat usus buntu

December 1, 2016 at 10:23 PM

Post a Comment