Loading ...
Sorry, an error occurred while loading the content.

49474Re: [scrumdevelopment] Keeping cross-cutting tasks visible (without technical stories)

Expand Messages
  • Malcolm Anderson
    Dec 1, 2010
    • 0 Attachment
      Ron, Alan

      I probably should not blog at midnight.


      Ron, you'll get a track back too, I promise.


      On Wed, Dec 1, 2010 at 10:48 AM, Alan Dayley <alandd@...> wrote:

      Interesting 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!


      On 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.

      >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 sounds like "lying to your product owner" (and the product owners that I've worked with, do know that "the team can do twelve")
      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.


      Malcolm Anderson
      Scrum Coach & Agile Engineer

      On 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

      > 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.

      If one is to do Scrum well, one needs to understand Scrum well.
      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.

      Ron Jeffries
      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)

    • Show all 28 messages in this topic