Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

scrumdevelopment · Scrum Users

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 7471
  • Category: Development
  • Founded: Feb 1, 2000
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Hear how Yahoo! Groups has changed the lives of others. Take me there.

Messages

Advanced
Messages Help
Messages 17723 - 17752 of 56890   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#17723 From: "entretriens" <entretriens@...>
Date: Fri Dec 1, 2006 4:00 pm
Subject: QA pileup
entretriens
Send Email Send Email
 
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.

#17724 From: "Jeff Heinen" <jheinen@...>
Date: Fri Dec 1, 2006 4:16 pm
Subject: Dealing With Overcommitment
vercinget_xx
Send Email Send Email
 
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@...
 

#17725 From: Vickydhiman <vickydhiman@...>
Date: Fri Dec 1, 2006 4:10 pm
Subject: Handling High Performers
vickydhiman
Send Email Send Email
 
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.

#17726 From: "Laurent Ploix" <laurent.ploix@...>
Date: Fri Dec 1, 2006 4:42 pm
Subject: Re: Which is the best way to improve the productivity of the development team?
lauploix
Send Email Send Email
 
From my experience as a PM, here are the main issues I encountered :

- switching from a task to another too often (see previous post)
- being too much under pressure (idem)
- and also : spending all your time correcting bugs that you introduced in the previous versions.

The last one is one of the worst, because :

- If you spend 40% of your time correcting bugs, you have a 60% productivity (I know some teams where it's about 80% of the time debugging :-( )
- So you'd better commit some good code from the beginning, and one of the most efficient way to do so is to have a powerful testing infrastructure (see http://lauploix.blogspot.com), with unit tests, integration tests, and so on
- As we discovered, spending 20% of the time writing good unit tests is much more efficient on the long term than writing code and delivering it right away

Laurent

So. Experience having your code being tested soon and extensively. You will see the "maintenance" part of your time decreasing a lot... and by difference, the time you will spend writing actual code will grow.

2006/12/1, Alex Pukinskis <Alex.Pukinskis@...>:

In my experience there are 3 factors that reduce the productivity of a development team:

  1. They don't have clear direction as to what they should be building and what it means for them to be done.
  2. There are organizational impediments (management problems) that are slowing them down
  3. They have been tasked with a goal they all know is impossible.

Here are some examples:

One team was slowed down because of increasing technical debt.  They had so much pressure from the business to deliver features fast that they compromised on quality for a while, and their architecture hadn't kept up with the features they were building.  Because work was being pushed into their Sprints by the product owner, they didn't have enough slack to keep up with their debt.  

One team was slowed down because the business was requiring them to work on several projects at once.  There was so much context-switching that they couldn't get much done.

One team was working on a project producing software that was unlikely to be used, but hadn't been cancelled.  The managers observed that the team of 10 got exactly the same amount of work done every iteration, even when 5 people were on vacation.

I would recommend examining whether you can work on any of these three areas, by:

  • Making sure the team has a product owner who creates a backlog of features and collaborates closely with the team to define detailed acceptance criteria and acceptance tests.
  • Making sure the team has a ScrumMaster who is keeping track of organizational impediments reported in the daily standup meeting and retrospectives, and is working to remove those impediments
  • Making sure the team owns their own estimates, and gets to decide as a group how much work they should take on each sprint
  • Making sure that the plans reflect the team's estimates as the estimates change over time.

-alex

On 12 01 2006 2:28 AM, "Nam Dao Xuan Thien" <dxtnam@...> wrote:

Dear ALL,
 
Recently, when I work as a project manager, I did tracking project activities and member hours per unit time/day. I found that the productivity of the development team is not good. So I think what I should do now is to find the best way to improve the productivity of development team. Can you tell me your experiences in improving the productivity of the development team?
 
I am thinking that when I find out one way to follow, I need have a formal discussion with management board, can you tell me your advices in case I introduce the new culture in the company?
 
Also, if you have any URL references, please send them to me.
 
Thank you and best regards
 
Nam





--
Laurent Ploix
http://lauploix.blogspot.com/

#17727 From: Nicholas Cancelliere <nicholas@...>
Date: Fri Dec 1, 2006 1:02 am
Subject: Re: Distributed Daily Standup - how do make them work?
nickaustin74
Send Email Send Email
 

I am in the same situation as you right now.  I am a Scrummaster for a team of developers that are located in both the UK and the US.  We hold our stand-ups at 9:30a CST (3:30p London).  Instead of focusing the questions on "what Im am doing today, what I did yesterday" take the context into "since our last meeting I have, and right now I am..."  This gets the focus off the time difference (since it is the ending of the day for London but the start of the day for the US).

We bring all the US team into one room and huddle around the conference phone (speaker) and they do the same in the UK.  We rotate who starts to be "fair" so one day the US team leads off, the other the UK team.

We use Skype for the day-to-day chatter and collaboration, but not the standup.

We use video conferencing for our planning meetings and we schedule them early in the day 7:30a CST so that we have 4 to 5 hours (and the UK team stays late 6:30p their time) to cover all items in the sprint backlog and elaborate them.  A little painful, but the sacrifice is so that we all get enough time together which is very important (and it's only once a month).

We use a web-based Agile planning tool to keep in sync.  Excel doesn't work well because you never know who has the right version and the most up-to-date.  If you're going to collaborate you need tools that use real-time data across the ocean (ideally).

The UK team is all in an open-shared space, but the US team is using cubicles.  

I hope this helps give you some ideas.

Sincerely,
-Nick



On Nov 14, 2006, at 11:24 AM, Mark Levison wrote:

How do you make distributed daily standups work. We have seven developers working in one location and two working in the UK. I can't change the situation and so am trying to find ways of making the team work. So I want to know how other distributed teams conduct the standup?

  1. Do you bring the main group together in one place and teleconference in the others?
  2. Does everyone sit in front of their machines and use Skype? (currently our team still has neighbouring cubes - we don't have a team room).
  3. Do you use a webcam?
  4. Do you replace the task board with Excel? ScrumWorks? Other software?
    1. if you use software how do get the public commitment of the taskboard?
    2. if you use software how do you get people to stay focused on the tasks in the standup?
  5. If you continue to use a task board how do you make it meaningful to the overseas developers?
trying hard to make a distributed team work.
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/



#17728 From: "William Wake" <william.wake@...>
Date: Fri Dec 1, 2006 5:28 pm
Subject: Re: Dealing With Overcommitment
wwake2
Send Email Send Email
 
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

#17729 From: "Clinton Keith" <ckeith@...>
Date: Fri Dec 1, 2006 5:34 pm
Subject: RE: Re: Valid uses of this list (was: RUP and Agile)
clintonnkeith
Send Email Send Email
 
--- 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

#17730 From: "Mark Levison" <mlevison@...>
Date: Fri Dec 1, 2006 5:02 pm
Subject: Re: Re: Good Scrum Executive Summary Articles?
marklevison
Send Email Send Email
 
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/

#17731 From: "ryanpcooper" <ryan.p.cooper@...>
Date: Fri Dec 1, 2006 5:39 pm
Subject: Re: Dealing With Overcommitment
ryanpcooper
Send Email Send Email
 
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@...
>

#17732 From: Ron Jeffries <ronjeffries@...>
Date: Fri Dec 1, 2006 2:17 pm
Subject: Re: RUP and Agile
RonaldEJeffries
Send Email Send Email
 
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

#17733 From: Jeff Langr <jeff@...>
Date: Fri Dec 1, 2006 5:55 pm
Subject: RE: Re: Valid uses of this list (was: RUP and Agile)
jlangr
Send Email Send Email
 
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

#17734 From: Ron Jeffries <ronjeffries@...>
Date: Fri Dec 1, 2006 5:58 pm
Subject: Re: Dealing With Overcommitment
RonaldEJeffries
Send Email Send Email
 
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

#17735 From: Rosemarie Camacho <rosemarie@...>
Date: Fri Dec 1, 2006 5:48 pm
Subject: New administrave assistant email address
rolos4slp
Send Email Send Email
 
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
Attachment: vcard [not shown]

#17736 From: Ron Jeffries <ronjeffries@...>
Date: Fri Dec 1, 2006 6:06 pm
Subject: Re: Re: Valid uses of this list (was: RUP and Agile)
RonaldEJeffries
Send Email Send Email
 
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

#17737 From: Ron Jeffries <ronjeffries@...>
Date: Fri Dec 1, 2006 6:08 pm
Subject: Re: Re: Dealing With Overcommitment
RonaldEJeffries
Send Email Send Email
 
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

#17738 From: "Stephen Bobick" <sbobick2@...>
Date: Fri Dec 1, 2006 6:12 pm
Subject: Re: RUP and Agile
sbobick2
Send Email Send Email
 
People who constantly change the subject can be impediments.

I didn't follow the thread closely enough to know if the person who was banned "did" that.  But I have been in groups where certain disgruntled/scheming employees had a knack for sidetracking conversations.  That's an impediment.

-- Stephen

On 12/1/06, Ron Jeffries <ronjeffries@...> wrote:

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



#17739 From: "William Wake" <william.wake@...>
Date: Fri Dec 1, 2006 5:51 pm
Subject: Re: Re: Dealing With Overcommitment
wwake2
Send Email Send Email
 
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

#17740 From: "Clinton Keith" <ckeith@...>
Date: Fri Dec 1, 2006 6:20 pm
Subject: RE: Re: Valid uses of this list (was: RUP andAgile)
clintonnkeith
Send Email Send Email
 
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

#17741 From: Ron Jeffries <ronjeffries@...>
Date: Fri Dec 1, 2006 6:22 pm
Subject: Re: Dealing With Overcommitment
RonaldEJeffries
Send Email Send Email
 
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

#17742 From: "Wolfgang Schulze Zachau" <wolfgang@...>
Date: Fri Dec 1, 2006 6:26 pm
Subject: RE: Handling High Performers
wolfiesz
Send Email Send Email
 
Do the other team members realize how much better he is ? Maybe this is the right time for a little dose of honesty on all sides.
 

Regards,

Wolfgang

 


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.


#17743 From: "Jeff Heinen" <jheinen@...>
Date: Fri Dec 1, 2006 6:28 pm
Subject: RE: Re: Dealing With Overcommitment
vercinget_xx
Send Email Send Email
 
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
>
>
>
>

#17744 From: "Jeff Heinen" <jheinen@...>
Date: Fri Dec 1, 2006 6:36 pm
Subject: RE: Dealing With Overcommitment
vercinget_xx
Send Email Send Email
 
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
>
>
>
>

#17745 From: "Clinton Keith" <ckeith@...>
Date: Fri Dec 1, 2006 6:36 pm
Subject: RE: Re: Dealing With Overcommitment
clintonnkeith
Send Email Send Email
 
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.

#17746 From: "lisasolace" <lsalas@...>
Date: Fri Dec 1, 2006 6:44 pm
Subject: Meeting your goals by punting work items
lisasolace
Send Email Send Email
 
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?

#17747 From: "Mark Smeltzer" <mark.smeltzer@...>
Date: Fri Dec 1, 2006 5:19 pm
Subject: Re: Handling High Performers
mark.smeltzer
Send Email Send Email
 
Sounds a bit like me :)
 
One of the problems with being a high performer is finding a company that you want to stick with... in my experience, most situations end up something like you described. No matter how adequate my starting salary/responsibilities are, in the past I have always grown at a pace that exceeded my employer's expectations and then they were put in the awkward position of trying to decide whether to give me disproportionate raises to their other employees. The bottom line is that I never stick around long with a company that fails to reward me for the progress I make in the name of "fairness" -- if they simply can't afford it and I like the company enough, of course I consider staying (money isn't everything).
 
If the high performance is something you wish to encourage and even cultivate, putting together a straightforward set of incentives could reward this individual and provide encouragement to the rest of the team. Consider these kinds of rewards: bonuses for completing more than X effort units per Sprint, allowing individuals who complete X effort units (that pass quality control) the option to take the rest of the Sprint off, etc. Personally, I love the "go home early" type bonuses. If you do want to implement a rewards program, it would be best to develop it incrementally with lots of feedback from your team.
 
On the other hand, if you don't implement a rewards program, you're only other option may simply be to give the high performer a raise proprotional to his merit. In the end, this may actually be your best option -- because if he becomes disgruntled and he really is a high performer, he shouldn't have a problem finding better pay someplace else.
 
- Mark
 
On 12/1/06, Vickydhiman <vickydhiman@...> 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.
 
Thoughts?


Access over 1 million songs - Yahoo! Music Unlimited.




--
________________________________
Mark Smeltzer, President
Living Agile Consulting Services
http://www.livingagile.com/consulting

#17748 From: Ron Jeffries <ronjeffries@...>
Date: Fri Dec 1, 2006 7:08 pm
Subject: Re: Dealing With Overcommitment
RonaldEJeffries
Send Email Send Email
 
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

#17749 From: "Wolfgang Schulze Zachau" <wolfgang@...>
Date: Fri Dec 1, 2006 6:52 pm
Subject: RE: Re: Dealing With Overcommitment
wolfiesz
Send Email Send Email
 
Don't they (and everybody else) realize that this is just window dressing? In the end of the day, you will have to deliver something when that deadline comes. Read Ron's blog about deadlines as a management responsibility. BTW: very well written, Ron.
I have to point out regularly in retrospectives what DONE actually means, and that the team has failed to achieve it. This puts the damper on a bit, but it also spurns them on, because they know they can do it (and they know that because they have done it before).
As I said earlier today on a different thread: this is calling for a bit of honesty in my opinion.
That deadline won't move. Neither will your velocity (at least not in the short term). Somethings gotta give. I believe your team needs a wakeup call, it needs to be faced with the harsh realities of life. Maybe the PO needs to be included as well.
What does he say to this overcommitment?
 

Regards,

Wolfgang


#17750 From: Ron Jeffries <ronjeffries@...>
Date: Fri Dec 1, 2006 7:15 pm
Subject: Re: Handling High Performers
RonaldEJeffries
Send Email Send Email
 
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

#17751 From: Ron Jeffries <ronjeffries@...>
Date: Fri Dec 1, 2006 7:06 pm
Subject: Re: Re: Dealing With Overcommitment
RonaldEJeffries
Send Email Send Email
 
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

#17752 From: Ron Jeffries <ronjeffries@...>
Date: Fri Dec 1, 2006 7:11 pm
Subject: Re: Re: Dealing With Overcommitment
RonaldEJeffries
Send Email Send Email
 
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

Messages 17723 - 17752 of 56890   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help