49465Re: [scrumdevelopment] Keeping cross-cutting tasks visible (without technical stories)
- Dec 1, 2010Hello, Roy. On Wednesday, December 1, 2010, at 3:29:27 AM, you
> I think this notion of only ever doing things that have value toIf one is to do Scrum well, one needs to understand Scrum well.
> the customer has been somewhat misunderstood, or misapplied. There
> are most certainly things that need to be done that do not have an
> immediate, direct, or even obvious value to a customer ... but
> they still must be done. So what if user stories are not written
> for them, and so what if they really don't fit the notion of user
> stories (however defined). Being afraid to get it done because
> Scrum doesn't seem to cover that situation just leads to
> development paralysis.
Deviating from it every time something "seems" odd will not help a
team to prosper. It troubles me that so much of your advice, Roy,
deviates substantially from what Scrum and Agile teach, even when
there are perfectly good Scrum / Agile answers.
So here's so what.
The fundamental point of Scrum is for the PO to prioritize work
for the team, so that the best possible product can be delivered
within the desired time and budget. The PO will get the best
product if work is chosen that is of high "business value". (Low
development cost is also a concern in choosing the work, but may
will be substantially less important than value.)
Clearly, the PO is capable of driving out more value when a larger
percentage of the team's time comes under her control, since
otherwise, she is directing a smaller flow of work, which will
inherently reduce total value. Therefore it is undesirable to
slice away a strip of the team's development time and make it
unavailable for stories.
However, so-called "technical stories" have a value proposition
which is almost completely different from an ordinary story. A
technical refactoring story may promise faster velocity sometime
in the future, while an ordinary story is something that real
users actually want. It is therefore very difficult, perhaps
impossible, to compare an ordinary story and a technical story for
value. Therefore it is undesirable to present technical stories at
all, since they are so difficult to prioritize.
This seems, if one doesn't think about it very hard, to be a
dilemma. We can't take away the PO's time, we can't prioritize the
technical stories. We can't have them at all. We are doomed.
Like most dilemmas, this one is solved by using a third
alternative. It turns out that [almost?] every bit of technical
work, if it should be done at all, is done in support of one or
more stories. IN PARTICULAR, the kind of work the OP is talking
about, creation of tests and creation of clean code, is inherently
part of creating stories.
Why inherently, one might ask. Because for code to be DONE, it
must work, and to know whether it works, we must test it. Because
we are working incrementally, we will revisit much of the code
many times and we might break it, so it is wise that the tests be
recorded for reuse, i.e. automated.
Further, since we are building the system incrementally, we are
building the design incrementally. We do not have the time (nor,
likely, the ability) to define the design correctly up front. We
do not have the time to build it up front even if we did have the
ability to define it. We must, perforce, evolve the design.
Therefore, for each feature to be DONE, its design must be fit for
the current purpose.
Therefore, testing, and design improvement, are /inherently/ part
of the work of doing stories.
How does this help us with our dilemma? We have, through our human
failings, fallen behind on the testing and design. What are we to
do? We do not want to slice time away from the Product Owner. The
Product Owner cannot correctly prioritize these strange technical
stories. We are doomed.
No. All we need to do is to bear down a bit on improving the code
we work on, doing all it takes to bring it back up to the proper
definition of DONE, namely "well-tested and well-factored". We
make the code a bit better every time we pass through it.
At first, maybe this takes a little longer per story. This is not
a real concern, as no one but the team really knows if the team
can do twelve this Sprint or only ten. The team commits to what
they can do. They do it, and the world becomes a better place.
Better yet, soon, surprisingly soon, it doesn't take longer after
all. Since we are improving the code and tests in the areas we
work in, velocity picks up quite quickly in the areas we work in.
We wind up going faster than before, because we are going better.
Our Product Owner retains her ability to prioritize the whole of
our work, and our code improves. No confusion, no political
discussion, no need to make promises about the future that we may
not be able to keep.
We don't need technical stories or tricky negotiations. We just do
the job we were always supposed to do, namely make each story
DONE, fully tested, with a good design in place.
Thousands of years ago, the first man discovered how to make fire.
He was probably burned at the stake he had taught his brothers to
light - Howard Roark (The Fountainhead, Ayn Rand)
- << Previous post in topic Next post in topic >>