RE: [scrumdevelopment] Re: Getting everything tested by the end of a Sprint
Intuit and other large software enterprises can turn around a new release in one day. They figured out how to make regression less than huge, to the regret of their competition.
It may take a few days to determine why the software is failing. This type of problem solving is a specialized skill. A QA engineer sitting with the developer while the developer is debugging the code does not help the bug get closed any faster. Once the root cause of the failure is determined, the fix can usually be made pretty quickly, and is often just a change in one or two lines of the code.
The QA engineer can write the story test while the developer is debugging the problem.
Once fixed, the developer could himself execute the story test, but his time is better spent debugging the next problem.
Occasionally, a bug fix is made to a vital piece of code that affects major portions of the product. This can trigger a huge QA effort to ensure that all aspects of the product still function properly. For the sake of argument, assume we are talking about legacy code that is not well covered by automated testing.
Note that the bug fixes are being delivered in service packs that are installed by thousands of customers. The cost of introducing a regression is huge.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Malcolm Anderson
Sent: Friday, May 30, 2008 1:53 PM
Subject: Re: [scrumdevelopment] Re: Getting everything tested by the end of a Sprint
Just out of curiosity, why can't the fixing and the closing be done at
the same time?
Why can't the tester be sitting with the developer going through it.
Possibly with 2 boxes, but still together.
I would think that you would hit "done-done" that much faster.
Is there some reason this wouldn't work?
On Fri, May 30, 2008 at 12:36 PM, Baker, Ed <ed.baker@...> wrote:
> woynam wrote:is
>>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
> it acceptable to have tasks that go towards the working software deliveredIs
> 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.
> this Scrum?the
> 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
> bug, and the second sprint is used to close it. The first sprint of athe
> release is used to prime the pump, and the final sprint is used to close
> remaining bugs. Is this Scrum?
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.
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
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 firstname.lastname@example.org, "Michael James" <michael@...> wrote:
> --- In email@example.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 morerealistic.
> > 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.