49470Re: [scrumdevelopment] Keeping cross-cutting tasks visible (without technical stories)
- Dec 1 8:48 AMInteresting point of view, Malcolm. You may be pointing out a lack in emphasis on the Product Owner role in many training and use situations. I don't think it is a fault of the Scrum framework, however.Phrases seen in Scrum writings with regard to the Product Owner role: "...owns the ROI of the product..." "..represents the customer..." "...owns the Product Backlog..." and the odious "...single wringable neck..." And even the title of the role means *owner* of the product.What part of these terms does not mean stewardship? You are pointing out that Product Owners are not getting the message, *despite* what the Scrum training and literature states. Maybe an oath would help but I don't think the message of product stewardship is lacking in Scrum.I had some other ideas to write but Ron was faster with his elaborations, which I don't think I can say any better.Nice discussions!AlanOn Wed, Dec 1, 2010 at 8:21 AM, Malcolm Anderson <malcolm.b.anderson@...> wrote:
This issue in Scrum of how to keep up the technical maintenance has always bothered me.
I was cruising along with your answer, singing praises to your ability to make the unclear, clear.
Until you got to the point where you seem to encourage a lack of transparency.This sounds like "lying to your product owner" (and the product owners that I've worked with, do know that "the team can do twelve")
>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.
This goes against the value of transparency.
It also takes away the PO's right to incur short term technical debt in order to make a particular deadline.
One of the weaknesses of Scrum is that we think, it's self evident that product owners are responsible for maintaining the health their product while they provide value to their customer.
I believe that this all comes down to Stewardship, and not making it clear to the product owner that they need to be Stewards to their product.
I've got 3 questions, the answers to which I believe are currently "No, No and No"
1) Is there a Product Owner body where Product Owners discuss with other product owners how to be a better product owner?
2) Is the concept of Stewardship a part of the PO training?
3) Has the PO body taking on a commitment to maintaining and improving the health of their products?
Until the answer to the above 3 questions is Yes, Yes, and Yes, this is going to be an issue with Scrum.
Until we have some kind of "Product Owner Oath of Stewardship," this is going to be an issue with Scrum.
Until stewardship is self evident to people other than Scrum Masters, this is going to be an issue with Scrum.
Scrum Coach & Agile EngineerOn Wed, Dec 1, 2010 at 6:16 AM, Ron Jeffries <ronjeffries@...> wrote:
Hello, Roy. On Wednesday, December 1, 2010, at 3:29:27 AM, you
wrote:If one is to do Scrum well, one needs to understand Scrum well.
> I think this notion of only ever doing things that have value to
> 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 >>