Hello Scrum Group,
For QA, I wonder if anyone had any recommendations for handling final
QA (just prior to UAT) for large scale projects with many
interdependencies? Developers use TDD and cruise control for unit
testing, QA people are involved from the beginning of the iteration to
oversee/advise test writing (this helps immensely), but the challenge
comes in the end when we do the full integration tests.

I tried to think of ways to stagger the effort, but all the code has
to be tested together at one time, which leads to that typical QA rush
at the end.

It's not that bad as the number and degree of breaks are few, but the
  QA test process is lenghty in itself. Is there something obvious that
I don't see. Much appreciation for any advice or reference to noteable
resources.

On 12/1/06, Jeff Heinen <jheinen@...> wrote:
> [when teams repeatedly fail to deliver on commitments] I've been
> coaching scrum masters that this is a signal to step in and not allow
> it to continue. The scrum master should limit the committed work
> based on established velocity, and coach the PO on how to effectively
> prioritize the backlog and adjust the scope in order to get their date.

Jeff - sounds like the right focus to me. I also talk to teams about
"committed vs. expected", and say that it's great to do more than you
commit to, but you need to get your commitments done so people can
learn to rely on you.

On the PO side, you might also consider the release burndown. At some
point, the contradictions become sort of too obvious to ignore. "We
said 60 but got 30; it was just a one-time thing." "We said 60 but got
30, we'll catch up by doing 90 next month. (And then we have to do 120
to catch up the month after that.)"

It's not clear if the team is making the estimates/commitments, or
they're being dictated by the PO. I've definitely had to hold back a
PO, and say "let the team promise what it really feels it can." ("No
pouting":)

> I've found that teams seem to become more productive when they first
> establish a pattern of success and really understand what it means
> to be done.
Amen!

--
    Bill Wake  William.Wake@...  www.xp123.com

--- MICHAEL SAHOTA <sahotam@...> wrote:
>> IMHO, it is valuable to talk about other methodologies and how
>> Scrum relates to them. It is valuable to talk about how other
>> concepts can complement Scrum.

Jeff L wrote
> I too get a lot of mileage out of reading these discussions. I
> think it's a bit odd to promote a method that claims to be best
> used in concert with other (engineering) methods, yet shun
> "methodologists" and any discussion that explores Scrum's
> relationship (or not) with other methods such as RUP.

> For my part I agree that methodology discussions that do
> not relate to Scrum need to be carried on elsewhere.
> That's fair, and I think that most people on this group
> would completely support that.

I support it.  The explosion of religious discussions that arise from
things like RUP, AUP, WTF, etc create noise with respect to the scope of
this list:
"For updates and interchange between the users of Scrum and those just
beginning to use Scrum. Restricted to those who want to build products
and software using Scrum. For discussion on how to do so. Not for
methodologists, but for practitioners."

I joined for this narrow focus.  There are plenty of lists where one can
hear the debates in full.

A good Scrum Master will put a halt to discussions that start to drift
outside the scope of the daily Scrum.  The role of a moderator on a list
with a stated scope is similar.

Clint

entretriens - you didn't say who were addressing but I assume its me.

On 12/1/06, entretriens <entretriens@...> wrote:
> I'm not sure if it's worth addressing here, but do you think that
> something should be added regarding the need for a supportive,
> understanding and involved leadership? This is elemental.
>
> I say this because one failure I witnessed more than once is that
> organizations try to adopt the process with primary motives of
> improving revenue and not embracing some it's fundamentals, which
> almost always leads to cutting corners in the processes and then to
> substandard results. In the end, it is Scrum/Agile to blame.
>
> Maybe something should be added to clue the executive audience in to
> what a successful Scrum implementation might need from them?
>
I'm interested - would you take a stab at drafting one or two sentences?

The original purpose for this posting is to help me do a very very
short presentation tomorrow. The presentation will 10 minutes, an
instance of the Scrum game 20-25 minutes. With 5-10 minutes to debrief
at the end of the game.

> Thanks for the draft by the way, it's a convenient reference. I have
> my own too.

Your welcome.
Cheers
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

I would say this is decidedly NOT the right approach. We also
essentially arrived at a velocity by dividing the 'required' scope by
the number of iterations (except our unrealistic 'velocity' came from
an outside influence, not the team itself). This is coupled with a
"not enough time for pairing/testing" mindset (we use XP; for those
not familiar with the terminology, think of it as "not enough time for
disciplined engineering practices"), resulting in silos of knowledge,
lots of bottlenecks, and low quality code resulting in a lot of bugs.

As a result, each iteration ends with a lot of stuff half-done and
very little actually done, as we optimistically try to cover all the
bases. This destroys the product owner's ability to plan ahead and
prioritize effectively, which results in frequent changes of direction
(Interestingly, scope affects priorities: as our product owner
realizes we aren't going to get everything done, priorities shift,
resulting in a change of direction). The combination of frequent
changes of direction and a lot of 'dead' code due to many
partially-implemented features results in a decline in velocity over
time. This, unfortunately, makes the problem even worse.

My recommendation to the Scrum Master in such a situation is to
strictly limit the amount of work accepted to the team's
empirically-proven velocity. I think that once there is some stability
in delivery, velocity will increase naturally over time.

Cheers,
Ryan
http://www.onagile.com


--- In scrumdevelopment@yahoogroups.com, "Jeff Heinen" <jheinen@...>
wrote:
>
> As a scrum master, how do you deal with chronic overcommitment and the
> resulting sprint failures? For example, when a team is routinely
> committing to 60 story points worth of work, but has a demonstrated
> velocity of around 30 for several sprints, I've been coaching scrum
> masters that this is a signal to step in and not allow it to continue.
> The scrum master should limit the committed work based on established
> velocity, and coach the PO on how to effectively prioritize the backlog
> and adjust the scope in order to get their date. I've found that teams
> seem to become more productive when they first establish a pattern of
> success and really understand what it means to be done. Then they seem
> to steadily increase their productivity, building on previous success
> until they reach a steady state of high productivity that's
> significantly higher than when they started. I'd rather have a team
> undercommit and get done early, and then pull in more backlog, rather
> than always ending a sprint with stuff not done.
>
> Often this situation occurs when an important project has a hard
> deadline and the PO *thinks* the scope is fixed (although on closer
> examination the backlog in these situations often seems to have a lot of
> stuff in it that isn't really required for the finished product; lots of
> nice-to-haves but not necessarily adding a lot of business value). The
> team looks at all of the backlog and simply divides it up among the all
> the sprints and commits to that work, not because they realistically
> think they can get it done, but because the date is fixed, the PO is
> putting a lot of pressure on the team to meet the date, and that's they
> only way they can meet the deadline.
>
> Is this the correct approach? Other suggestions?
>
> Jeff Heinen
> Director, Quality and Support Engineering
> Qpass - Amdocs Digital Commerce Division
> 2211 Elliott Avenue| Suite 400 | Seattle, WA 98121
> o: +1.206.695.9509 | m: +1.425.785.9813 |
> f: +1.206.447.0669 | jheinen@...
>

Hello, Ken.  On Friday, December 1, 2006, at 8:17:31 AM, you wrote:

> Another short thought. For those of you who are ScrumMasters, is your job to
> remove impediments and to stop predators from detracting the team from its
> mission?

The word predators sounds pretty strong. And I don't think open
conversation is usually considered an "impediment".

Ron Jeffries
www.XProgramming.com
How do I know what I think until I hear what I say? --  E M Forster

Quoting Clinton Keith <ckeith@...>:
> I support it.  The explosion of religious discussions that arise from
> things like RUP, AUP, WTF, etc create noise with respect to the scope of
> this list:
> "For updates and interchange between the users of Scrum and those just
> beginning to use Scrum. Restricted to those who want to build products
> and software using Scrum. For discussion on how to do so. Not for
> methodologists, but for practitioners."
>
> I joined for this narrow focus.  There are plenty of lists where one can
> hear the debates in full.

I too joined it to figure out how to "build products and software
using Scrum," and "discussion on how to do so." Unfortunately, since
Scrum answers only part of the challenge, such discussion would
necessarily need to involve other process. Not religious debate, mind
you, but open discussion about techniques.

As an example, I appreciated Ambler's posting of an article where
someone discussed how they were able to mesh Scrum and RUP ideas--a
potential practical solution. That was a response to Mr Schwaber's
statement that that RUP and Scrum are contrary, not mappable. Which I
think is an emphatic and religious methodologist's stance, not one of
someone trying to figure out how to make things work.

Jeff Langr
http://langrsoft.com
Agile Java, Crafting Code With Test-Driven Development

Hello, Jeff.  On Friday, December 1, 2006, at 11:16:26 AM, you
wrote:

> As a scrum master, how do you deal with chronic overcommitment and the
> resulting sprint failures? For example, when a team is routinely
> committing to 60 story points worth of work, but has a demonstrated
> velocity of around 30 for several sprints, I've been coaching scrum
> masters that this is a signal to step in and not allow it to continue.
> The scrum master should limit the committed work based on established
> velocity, and coach the PO on how to effectively prioritize the backlog
> and adjust the scope in order to get their date. I've found that teams
> seem to become more productive when they first establish a pattern of
> success and really understand what it means to be done. Then they seem
> to steadily increase their productivity, building on previous success
> until they reach a steady state of high productivity that's
> significantly higher than when they started. I'd rather have a team
> undercommit and get done early, and then pull in more backlog, rather
> than always ending a sprint with stuff not done.

I'm sorry, this seems to me to be an advanced question and I am not
allowed to enter into advanced discussions.

Ron Jeffries
www.XProgramming.com
I have tried in my way to be free.  -- Leonard Cohen

This posting is to introduce Carole Marks.  Carole Marks will be taking
over the email correspondence for any registration or renewal
questions.  We were testing her new email address and I accidentally hit
send before updating the new address in the from field.  Please only
email Carole at cmarks@....  If you could disregard the
email I sent from her personal mailbox that would be very helpful.

Thank you,

Rosemarie Camacho
Administrative Assistant
Scrum Alliance

Hello, Clinton.  On Friday, December 1, 2006, at 12:34:45 PM, you
wrote:

> A good Scrum Master will put a halt to discussions that start to drift
> outside the scope of the daily Scrum.  The role of a moderator on a list
> with a stated scope is similar.

What happened to that self-organization thing?

Ron Jeffries
www.XProgramming.com
New and stirring things are belittled because if they are not belittled,
the humiliating question arises, "Why then are you not taking part in
them?"   -- H. G. Wells

Hello, ryanpcooper.  On Friday, December 1, 2006, at 12:39:36 PM,
you wrote:

> My recommendation to the Scrum Master in such a situation is to
> strictly limit the amount of work accepted to the team's
> empirically-proven velocity. I think that once there is some stability
> in delivery, velocity will increase naturally over time.

Unless I am mistaken, which is quite possible, the way Scrum works
as described in Scrum 101 is that the TEAM decides how much of the
backlog they can consume, and they commit to getting that much fully
done. They adjust until they're good at it.

That's not happening where you are ... what is happening instead?

Ron Jeffries
www.XProgramming.com
Accroche toi a ton reve.  --ELO

On 12/1/06, ryanpcooper <ryan.p.cooper@...> wrote:
> I would say this is decidedly NOT the right approach. We also
> essentially arrived at a velocity by dividing the 'required' scope by
> the number of iterations [...]

I should have explicitly said - I also think that doing this
[generating "expected velocity" given features and date] is *not* the
right way to set commitments (or velocity).

I do agree with the steps Jeff outlined to deal with this: focusing on
actual velocity, improving the backlog, and making sure "done means
done."

--
    Bill Wake  William.Wake@...  www.xp123.com

From: Jeff Langr
> I too joined it to figure out how to "build products and
> software using Scrum," and "discussion on how to do so."
> Unfortunately, since Scrum answers only part of the challenge,
> such discussion would necessarily need to involve other
> process. Not religious debate, mind you, but open discussion
> about techniques.

The dividing line between topics like "using XP with Scrum" on one side
and "changing Scrum" or "creating Scrum 2.0", etc on the other is very
thin.  As a relative newcomer to Scrum I am using the practices of Scrum
while trying to understand the principles and values behind it.
Discussions about how RUP can mesh with Scrum might be worth a link, but
not 40 messages IMO.  These discussions seem relevant to the
methodologists, consultants and other "high-power thinkers" that gave us
Scrum, XP, etc to begin with but from my perspective they dilute the
value of this list as stated in its scope.

Give us mortals a break and throw your thunderbolts up in the clouds!
:)

Clint

Hello, Jeff.  On Friday, December 1, 2006, at 11:16:26 AM, you
wrote:

> As a scrum master, how do you deal with chronic overcommitment and the
> resulting sprint failures?

I'm curious: How is the team getting its commitments now? What do
you imagine to be causing them to overcommit all the time?

Ron Jeffries
www.XProgramming.com
Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning. --Albert Einstein

---

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Vickydhiman
Sent: 01 December 2006 16:10
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Handling High Performers

In a team we have there is "one" high performer. Using our existing metrics which "the whole team" agrees on [independent peer reviews and performance appraisals including the ones from the customers" - performance of this individual is 4-5 times that of the nearest individual. However, this individual always feels he is stuck with a poor team and we are anxious to retain him for obvious reasons. If we give him same raise as everyone else, then also he would feel bad for obvious reasons. The team feels this individual is too much into his own self. However, does not seem to hamper other individuals beyond raising expectations of better performance from them.

 

Thoughts?

---

Access over 1 million songs - Yahoo! Music Unlimited.

What's happening is that we have fixed deadline and the team is very
motivated to try and meet it. This is leading them to keep trying to get
more done than they are currently capable of, which has lead to an
atmosphere were failing a sprint is not seen as a bad thing. The result
is that they don't really understand what it means to be successful. In
my experience, teams achieve the highest level of productivity when they
build on a history of success. A team that enters a sprint, knowing that
there's no way they can achieve everything they've taken on, isn't
really committed. They aren't self-organizing to achieve goals, but
rather scrambling to pack as much in as they can.

> -----Original Message-----
> From: scrumdevelopment@yahoogroups.com
> [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
> Sent: Friday, December 01, 2006 10:09 AM
> To: scrumdevelopment@yahoogroups.com
> Subject: Re: [scrumdevelopment] Re: Dealing With Overcommitment
>
> Hello, ryanpcooper.  On Friday, December 1, 2006, at 12:39:36
> PM, you wrote:
>
> > My recommendation to the Scrum Master in such a situation is to
> > strictly limit the amount of work accepted to the team's
> > empirically-proven velocity. I think that once there is
> some stability
> > in delivery, velocity will increase naturally over time.
>
> Unless I am mistaken, which is quite possible, the way Scrum
> works as described in Scrum 101 is that the TEAM decides how
> much of the backlog they can consume, and they commit to
> getting that much fully done. They adjust until they're good at it.
>
> That's not happening where you are ... what is happening instead?
>
> Ron Jeffries
> www.XProgramming.com
> Accroche toi a ton reve.  --ELO
>
>
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@eGroups.com
> Yahoo! Groups Links
>
>
>
>

Management pressure coupled with a strong motivation to help the company
succeed. The intentions are all good. What's happening is that the team
does not grasp that limiting their commitment to what they can actually
do will ultimately lead to greater productivity. They haven't learned
*how* to be successful or develop a rhythm of success, so the habits
they are developing lead to gauranteed failure.

> -----Original Message-----
> From: scrumdevelopment@yahoogroups.com
> [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
> Sent: Friday, December 01, 2006 10:23 AM
> To: scrumdevelopment@yahoogroups.com
> Subject: Re: [scrumdevelopment] Dealing With Overcommitment
>
> Hello, Jeff.  On Friday, December 1, 2006, at 11:16:26 AM, you
> wrote:
>
> > As a scrum master, how do you deal with chronic
> overcommitment and the
> > resulting sprint failures?
>
> I'm curious: How is the team getting its commitments now?
> What do you imagine to be causing them to overcommit all the time?
>
> Ron Jeffries
> www.XProgramming.com
> Learn from yesterday, live for today, hope for tomorrow.
> The important thing is to not stop questioning. --Albert Einstein
>
>
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@eGroups.com
> Yahoo! Groups Links
>
>
>
>

From: Ron Jeffries
> Unless I am mistaken, which is quite possible, the way Scrum
> works as described in Scrum 101 is that the TEAM decides how
> much of the backlog they can consume, and they commit to
> getting that much fully done. They adjust until they're good
> at it.

The problem we've seen is with the practice "adjust until they're good
at it".

If the lowest priority stories are going to be dropped to hit the zero
backlog anyways, then the only motivation is the team's own level of
commitment and ownership to the backlog.  I'd like to hear stories about
how teams get there.

We've been working as a scrum team for almost two years now, and the
one thing that continually ticks me off is that at the end of the
sprint, we end up punting all those items that were barely limping
along during the sprint, just so we can look like we're done with the
items in our backlog.

We are a content development team that works on a continuous
publishing basis (releasing various pieces of content about once a
month) and we don't always control our destiny when it comes to
having control over our backlog. Another side-effect is that writers
are notoriously bad at predicting work load. We've tried adding in
buffers to account for our ever-growing sprint backlog - but
inevitably, we don't bump items back into the product backlog until
we see that it's absolutely hopeless 5 days before the end of the
sprint. I know I could draw a hard line and force the issue, but that
makes the team extremely distressed. So many times, they've been
heros and been able to get more work (albeit different work than
planned) done in a typical sprint.

Am I just making too much out of meeting the goals we have planned -
even if we've planned equal amounts of work? Does it really matter
since we don't really need to hand off a completed product at the end
of a sprint?

Hello, Jeff.  On Friday, December 1, 2006, at 1:36:10 PM, you
wrote:

> Management pressure coupled with a strong motivation to help the company
> succeed. The intentions are all good. What's happening is that the team
> does not grasp that limiting their commitment to what they can actually
> do will ultimately lead to greater productivity. They haven't learned
> *how* to be successful or develop a rhythm of success, so the habits
> they are developing lead to gauranteed failure.

This is pretty advanced, so I probably shouldn't say anything, but
in fact it doesn't matter whether they'll be more productive or not.
What matters is that the way management comes to trust a team is
when they say what they'll do, and then do what they say. So long as
a team over-commits, they are lying to management every time around.

I'd advise against lying to management. It's a well-known CLM.

Ron Jeffries
www.XProgramming.com
Without practice, no emergence. -- Dougen Zenji

Hello, Vickydhiman.  On Friday, December 1, 2006, at 11:10:25 AM,
you wrote:

> In a team we have there is "one" high performer. Using our existing metrics
which "the
> whole team" agrees on [independent peer reviews and performance appraisals
including the
> ones from the customers" - performance of this individual is 4-5 times that of
the nearest
> individual. However, this individual always feels he is stuck with a poor team
and we are
> anxious to retain him for obvious reasons. If we give him same raise as
everyone else, then
> also he would feel bad for obvious reasons. The team feels this individual is
too much into
> his own self. However, does not seem to hamper other individuals beyond
raising
> expectations of better performance from them.

I am of course interested in high performers. However, I am more
interested in TEAM performance. Therefore, if someone wants high pay
in my organization, I assess them more on how they advance the team
than on their own individual work.

Ron Jeffries
www.XProgramming.com
Talent determines how fast you get good, not how good you get.
   -- Richard Gabriel

Hello, Clinton.  On Friday, December 1, 2006, at 1:36:37 PM, you
wrote:

> From: Ron Jeffries
>> Unless I am mistaken, which is quite possible, the way Scrum
>> works as described in Scrum 101 is that the TEAM decides how
>> much of the backlog they can consume, and they commit to
>> getting that much fully done. They adjust until they're good
>> at it.

> The problem we've seen is with the practice "adjust until they're good
> at it".

> If the lowest priority stories are going to be dropped to hit the zero
> backlog anyways, then the only motivation is the team's own level of
> commitment and ownership to the backlog.  I'd like to hear stories about
> how teams get there.

Dropping stories does not mean you met your commitment, it means you
failed to meet your commitment.

What is causing the team not to estimate in such a way as to have to
drop no stories? Why do they not value making their commitments?

Ron Jeffries
www.XProgramming.com
Hold on to your dream.  --ELO

Hello, Jeff.  On Friday, December 1, 2006, at 1:28:25 PM, you
wrote:

> What's happening is that we have fixed deadline and the team is very
> motivated to try and meet it. This is leading them to keep trying to get
> more done than they are currently capable of, which has lead to an
> atmosphere were failing a sprint is not seen as a bad thing.

Someone should help them see that failure is not as good as success.
I would have thought that everyone knew that, so I'm not sure how to
help beyond that simple suggestion.

> The result
> is that they don't really understand what it means to be successful.

I would think it would be relatively simple, at the end of the
Sprint, to point out that we drew the line here, and only got done
to here.

Then in planning, when they draw the line (do they draw the line, or
does someone else tell them where the line is???), ask them if
they're really going to get that much really done.

Raise the line until they say yes. Rinse, repeat.

It's not about success or failure, really. It's about correctly
predicting what's going to happen.

This next is heresy and will surely get me burned at the stake: a
shorter Sprint will help with this.

> In
> my experience, teams achieve the highest level of productivity when they
> build on a history of success. A team that enters a sprint, knowing that
> there's no way they can achieve everything they've taken on, isn't
> really committed. They aren't self-organizing to achieve goals, but
> rather scrambling to pack as much in as they can.

Your problem isn't productivity, in my opinion. It is
predictability.

Ron Jeffries
www.XProgramming.com
That's my opinion and I agree with it. -- Julio Santos