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

RE: [scrumdevelopment] Re: Getting everything tested by the end of a Sprint

Expand Messages
  • Ken Schwaber
    We ask Product Owners to define the highest priority work for the team so any interruption is, by definition, of lower value and not a valid interruption.
    Message 1 of 90 , May 30, 2008

      We ask Product Owners to define the highest priority work for the team so any interruption is, by definition, of lower value and not a valid interruption. Customer down, severity 0 interruptions are, of course, higher value. We ask teams to allocate time each Sprint for responding to these, if they are also maintaining production systems.

      The process a team uses to create an increment of potentially shippable functionality is continually improving. Who does what, who helps each other do what, and the nuances of what are done is as fluid as – yes – a rugby game. So to say that only a QA person does something, or that fixing a bug always takes two sprints is to condemn yourself to playing a game, building an increment, in a manner far less competitive and productive than others. Other people on teams act cross-functionally, applying skills rather than roles, and can fix bugs a whole lot quicker than two Sprints,



      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Baker, Ed
      Sent: Friday, May 30, 2008 1:37 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Re: Getting everything tested by the end of a Sprint


      woynam  wrote: 


      >The premise of Scrum is that we

      start with a few immutable ground
      >rules, including the 3 basic roles and their responsibilities (PO, SM,
      >Team Member), the basic artifacts (product backlog, and Sprint
      >backlog), the 3 basic meetings (planning, daily, and retrospective),
      >and the commitment that the team makes to deliver working software at
      >the end of each Sprint.
      >That's pretty much it. You can talk about all the engineering
      >practices in the world, but if you remove any of the basic steps,
      >you're simply not talking about Scrum any more.

      Is there anything in Scrum that says that all tasks performed in a sprint must be directed towards developing working software for that sprint?  Or is it acceptable to have tasks that go towards the working software delivered in the following sprint?


      In the real world (tm) teams are comprised of people with different skill sets which complement each other.  For example, QA and development engineers.  Now, consider a product maintenance support team that is chartered with fixing customer bugs.  The backlog is a list of bugs.  Each story is a bug.  Each bug is fixed and unit tested by a development engineer.  It is verified, accepted, and closed by a QA engineer.  The sprint backlog is a list of bugs that will be closed during that sprint.  Is this Scrum?


      Now for the wrinkle.  The lifecycle of a bug fix is two sprints.  (The sprints are one week, if that matters.)  The first sprint is used to fix the bug, and the second sprint is used to close it.  The first sprint of a release is used to prime the pump, and the final sprint is used to close the remaining bugs.  Is this Scrum?


    • Ken Schwaber
      We know have enough compelling success stories in various industries that the value proposition is that if you don t do Scrum or something that provides its
      Message 90 of 90 , May 31, 2008

        We know have enough compelling success stories in various industries that the value proposition is that if you don’t do Scrum or something that provides its benefits, your company will either go out of business or have to subcontract to a company that has done the hard work to achieve the benefits. Scrum isn’t magic;  it is the illuminating framework within which the very hard work of self-improvement occurs. Either you do it, or you are left in dust.



        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mark Jean
        Sent: Saturday, May 31, 2008 12:59 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] rationalizing "Scrum, But" (Re: Getting everything tested by the end of a Sprint



        Of all the teams you've worked on, you write that you've been fortunate to be on one that was "Pure Scrum."

        Most "change agents" trying to "get Scrum in" must "sell" it.

        Geoffrey Moore's "Crossing The Chasm" (CTC) high tech marketing bible states "the compelling reason to buy (a new technology) is always a version of the following value proposition:

          Our *Scrum development framework* radically improves
          productivity on an already well-understood critical
          success factor specific to your business, and there is
          no existing means by which you can achieve a comparable

        The problem is - that statement is false for many program managers. They see RUP - or whatever development methodology they're using - working "just fine."  Therefore, they're exceedingly reluctant to "let the developers loose in the asylum."  Why?  The price of failure is high.  Go with what works - even if it's flawed.

        These people who "push back" against Scrum are called (by Moore) "Pragmatists."

        Is it necessary for the Scrum Master / Change Agent to "hold two opposing thoughts" in their noggin - in order to sneak the new technology in through the door?  Of course. Most likely they must appease a pragmatic boss(es).

        So - instead of obsessing only about "Purity" - maybe a new focus could be, "How can we help people 'get Scrum in the door?'" 

        The more Scrum can initially integrate with existing systems - the easier it is to "Cross The Chasm" - get buy in - and work towards the "ideal."

        Another quote from "Crossing The Chasm":

          "If we look deep into that chasm, we see four
           fundamental characteristics of visionaries that
           alienate pragmatists.

             1. Lack of respect for the value of collegues' experiences.

             2. Taking a greater interest in technology than in their industry.

             3. Failing to recognize the importance of existing product infrastructure.

             4. Overall disruptiveness."

        --- In scrumdevelopment@yahoogroups.com, "Michael James" <michael@...> wrote:

        > --- In scrumdevelopment@yahoogroups.com, "Malcolm Anderson"
        > malcolm.b.anderson@ wrote:
        > > It feels like we've been having a conversation about how it's
        > > physically impossible for a vehicle with only 2 wheels to stay
        > > and so we keep talking about which training wheels are more
        > >
        > > I've worked on at least one team that did "Pure Scrum," the
        > > were pretty amazing, and worth getting back on the bicycle for.
        > People who haven't yet mastered bicycling regularly get on this
        > list and wonder why we're so closed minded about adding
        > a third wheel. "Damn purists! If only I could catch up with
        > them, they'd believe my argument that my tricycle is
        > just as fast!"
        > My favorite part is being lectured how a bicycle can't
        > stay up "in the real world."
        > Meanwhile the people further along the path to mastery are
        > talking about how to improve our cycling skills, what are some
        > great places to ride, etc. If they talk about the bicycle at all, it's
        > how to make it lighter (using story points, going to shorter
        > sprints, using eXtreme Programming), not heavier.
        > On this list we don't hear enough from the second group.
        > They're out riding, not thinking about riding.
        > There's nothing new about regarding people as "resources."
        > Frederick Taylor, Henry Ford, the Soviet Army, etc. took
        > these ideas about as far as they could go.
        > The developer/QA caste system isn't new either, yet the
        > same people who are suffering its effects are advocating
        > its perpetuation.
        > --mj

      Your message has been successfully submitted and would be delivered to recipients shortly.