|
In the last three months, I've taught product groups
with dozens of devs and testers, as well as small
teams of about five. I always explain that however
long the iteration is (one or two weeks), the idea is
to get stories to DONE: potentially shippable, not
just seemingly working on your machine.
The question always comes up:
“Seriously? Like, tested and all? Done-done?”
(Sometimes this is accompanied by nervous shifting
in seats. Other times I catch a snickering look of
the “ha!” variety. Occasionally I get a genuine
oh-my-god-what-am-I-getting-myself-into look.)
So I elaborate. You make that happen by working
with smaller and smaller pieces, but make sure those
are still proper stories. You apply evolutionary
design instead of chunking. You simplify. And you
keep the end in mind: the end is working valuable
software, not just typed code.
Even though I've been teaching this for years, and
Agile doesn't appear to be radical news anymore, this
concept is still a huge departure from most folks'
current belief system. Typically, they object because:
- They believe that unless a feature is sizable, it
can't be valuable. And so every feature takes a long
time. They don't try splitting it, or don't know how.
- Those who work in large legacy codebases are
genuinely cautious of making code changes.
- It feels like a waste of time: If the feature is
understood, why not just develop it straightaway,
instead of in small pieces? And what's the point of
testing small pieces anyway?
- The developers feel they don't have time to code,
and the testers feel they don't have time to test.
In fact, a common misperception is that the 10-day
iteration just shrank to six days of coding,
surrounded by one day of planning, two days of
testing, and one day of stabilization. In other
words, a mini-Waterfall. The obvious conclusion is
that both dev & test have a mini-death march every two
weeks.
Do you see yourself, or your team, in the picture I
drew above?
If you do, know that you're not alone. This is a
very common situation even among teams that think of
themselves as agile: maybe they squeeze some testing
in, or have it done in the next iteration, or rely on
a “hardening” iteration. These approaches might help
but if you ask me, they miss the point.
Also be aware that whether you're already using
Agile or you're just starting, getting to the point
of tight, properly “done” iterations with truly
potentially shippable software will TAKE A WHILE. I
know, I was on the receiving end only a few years ago.
How do you get there?
First, suspend your disbelief. However unique your
situation, open your mind to the possibility and
value of such iterations.
Then, accept that the road will be rocky. Some
iterations will feel funny. Some stories will feel
unsplittable. You will have doubts about your choices
along the way. (I hope you get some coaching along
the way, to minimize the pain and tribulations.)
Lastly, plan for less so you can complete more. If
you seemed to have 20 points in an iteration, but
that was mostly coding and little testing, shoot for
15 points of “really done” work.
Of course, your testers should be part of the
planning and estimation process. If they're not, we
should REALLY have a conversation.
Copyright © 2011, 3P Vantage, Inc. All rights reserved.
|