I’m not sure I buy Cockburn’s machismo angle, in his
article “Are Iterations Hazardous to Your Project?”, as the complete reason for the prevalence of 2 week iterations. As we’ll see, I think the underlying problem isn’t so much machismo as it is, well, not being wise enough to do otherwise as needed.
But I like his summary of why you’d want your iteration to be a
month instead of 1-2 weeks:
Usually, as I am witnessing it, the pressure that drives
teams to form pipelines is the machismo around short iterations. For
many teams, if they used an iteration length of one month, they could
jointly develop the requirements, database, code and tests for a set
of user stories all in one iteration, and then possibly even deploy it
and get feedback from their user base. However, they won’t set up a
one-month iteration, because then they will be viewed as sissies in
iteration-length bragging matches.
There’s a Lot of Work To Do
I’m interested in that middle sentence: in my experience, cramming
all those things into less than a month is difficult. I can see that
if you had an almost purely UI-centric, smallish application, and you knew
exactly what you were implementing, iterations of less than a month
wouldn’t be a problem. But when you’ve got lots of complicated,
undefined/unknown, non-user facing sub-systems that have to work
together, it gets difficult to come up with something demo’able —
running, tested features — that isn’t lame in less than a month.
To summarize my thinking: yes, if you know what you’ll be coding
and integration is easy, 2 weeks is great. The problem is that there’s
a whole lot more than coding and integration to do, and often-times
those activities are crammed into the 2 week iteration.
For example, you’ve got to: figure out what you’re supposed to
code; come up with designs and/or prototypes; figure out your testing
strategy; do your documentation, internal and external; put everything
together for the demo; and then do all the unexpected things that come
up, like figure out why the previous version of the product that
paying customers are using keeps shitting the bed.
Perfect Planning Doesn’t Happen
That’s all assuming that all your planning and story-carding is
done perfectly so that the everyone can hit the ground running. Of
course, that whole this planning and story-carding is often put into
the 2 week window as well. Defining
the problem sufficiently to efficiently come up with the solution
takes a lot longer than we ever think, but we hardly ever give it
enough time. We’ll always “do it better” this time, as with all things
That is, it’s rare and difficult for an organization to achieve the
pipeline’ing that’s needed to effectively use two week iterations.
Month Iterations are Training Wheels
What I’m saying is that most places probably aren’t mature enough
to do 2 week iterations. They’re not good enough at the process of
creating software to work that fast. Usually, the fact that they’re
adopting a new methodology indicates that how they’ve been doing
things wasn’t too functional in the first place.
As an indication of this lack of maturity, most people I talk with
take a sort of flippant attitude about Agile: “it means we don’t have
to do so much planning or documenting.” In fact, in my experience,
it’s the opposite, with a twist: you don’t have to do worthless
planning and documenting, you have to do thorough, but lean,
planning and documenting.
In my mind, if your going to be coding for two weeks, you’re
probably going to need 2 weeks for planning, designing, and all the
other project managing that 2 weeks of coding requires. Putting all
those activities into 2 weeks doesn’t seem like a good idea. And it
certainly seems to cause you commit the error that Cockburn warns
about: the end-result of your 2 week iteration isn’t
customer-deliverable. It needs more work before you’d think to give it
to an actual customer or user.
Dividing Up the Work is a Bad Idea
The temptation here is to get another group of people — product
managers or analysts — to do all that definition for the
development team. These people take the 2 weeks to write-up
everything. And then you have true waterfall pipelining. You end up
with a sort of process/methodology version of Conway’s Law:
the software development process and organization uses will directly
reflect the managerial and communication structure of that
The bad things about separating the roles out like this are:
- Transferring that plan-think to the development team will be
slow, error prone, and tedious. Ideally, the same group of people
has defined things and, thus, no transfer is required.
- With separate teams comes tribal thinking, that is, “us
vs. them.” When software is created in this type of context, it’s
much more difficult to write good software that users will love
(For more on the tribe problem, check out my
recent post on The Paradox of Scaling Responsibility and this
anecodatal-ish discussion the problem in the auto-industry)
Predicting the Future
Of course, you’ll end up having to re-plan a lot of stuff while
you’re coding it — that is one of the major epiphanies of
Agile-think, not that you don’t need to plan or document. This
suggests that you’ll want to spread out planning into your
coding. Indeed, you do. So, the idea of having 2 weeks for planning,
then 2 weeks of coding seems silly. Really, you need 4 weeks of doing
More importantly, as Cockburn says,
The length of an iteration is secondary in importance to completing
deployment-ready functionality. Replace your worrying about how short
you can make an iteration to worrying about how long it takes to move
from opening a new requirement until that requirement is integrated
into the deployment base with acceptance tests.
Point being, I’m not really attached to 2, 3, 4, or 6 weeks. I’m
more attached to the idea of clearly-enough defining your end-goal,
and then expanding your iteration to fit that goal.
A Theory on What to Do
If you find yourself in a situation like this, what I’d want are
- Lengthen the iterations to a month to start with.
- Make the “planning people” and anyone else working on the product
part of the team (and I mean, really part of the team, not
some half-ass just show up at meetings and take notes sort of
- Make the roles in the team fluid: developers might do some
might do some coding, QA might write some code, planners might do
some QA or coding.
As the team gets better at defining their goals and stories, you
can vary the iteration length as required to meet the customer
deliverable at the end of the iteration. But, as you’re learning, keep
things at a month to give the team time to learn how to better manage
the process of software development.
Being resistant to the idea that you’d have to learn this is where the machismo angle fits in, esp., as is commonly the case, if by “machismo” you mean “stupid” ;>
Ask “Is it Working?”
As with any process improvement, the most important thing is to
frequently and seriously ask if the changes are working. Using rapid
feedback to improve your efficiency and quality is, perhaps, the least
used tool in the Agile tool-box.
If there isn’t a constant stream of constructive-complaining from
the team, they’re either the best software team in existence, or
they’re hiding something from management. As the other side of that
coin: management should be constantly responding to that
constructive-complaining and seeking out ways to improve
things. Otherwise, they
just don’t get it.
Granted, it takes a lot of professionalism on the team’s and
management’s part to even admit/think “maybe we’re not such
hot-shit. We should figure out what we do wrong and fix it.” I mean,
why would you get paid so much if you weren’t hot shit?
Of course, that question was answered
Charles and I have talked about the IUV article in one of our podcasts, Episode 23.