scrumdevelopment : Messages : 48203-48233 of 56954

Hello, Roy.  On Wednesday, September 1, 2010, at 12:25:43 AM, you
wrote:

> Of course, the question of how efficient and effective the
> developers are does arise. And how can we measure that efficiency
> and effectiveness. And how can we evaluate it, for the purpose of improvement.

Is there some way to measure efficiency and effectiveness for teams
all of whose work /is/ in-sprint?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
I try to Zen through it and keep my voice very mellow and low.
Inside I am screaming and have a machine gun.
Yin and Yang I figure.
   -- Tom Jeffries

#48204

From: "yoshidog78" <timswise@...>
Date: Wed Sep 1, 2010 1:23 pm
Subject: For those with muliple tools in the bag, here's a Kanban game

yoshidog78

For those with multiple tools in the bag, here's a Kanban game

I would appreciate any feedback on this attempt at a Kanban game. It is
currently given during training sessions on lean/kanban after my scrum training
of course!

http://www.scribd.com/doc/36358058/Building-boats-A-kanban-game

Thanks in advance!

Reply | Messages in this Topic (1)

#48205

From: "Michael" <mikeabugow@...>
Date: Wed Sep 1, 2010 2:15 pm
Subject: Re: What to do when the team is not firing on all cylinders?

mikeabugow

Hi All,

My goal is to help this team respond to their sprint backlog effectively, and to
help the P.O. say no to the out of sprint work that continually comes up. 
Myself and one of the other ScrumMasters in my division agree that a Kanban
approach would be more appropriate for this type of development team. 
Unfortunately, upper-management does not feel that switching to Kanban is a
worthwhile exercise.

The team sees itself as getting more work done than ever before, and feels they
are doing a good job when they get the little amount of actual planned work
completed along with all of the planned for out of sprint work.

Mike

--- In scrumdevelopment@yahoogroups.com, Bachan Anand <bachans@...> wrote:
>
> Michael ,
> Great post !!
>
> On Tue, Aug 31, 2010 at 8:14 AM, Michael <mikeabugow@...> wrote:
>
> >
> >
> > Alan,
> >
> > Agreed, this is a case of education and fear. I have discussed this with
> > the team in multiple retrospectives, and their group opinion is they are
> > doing fine because they are getting so much work accomplished. Even though,
> > most of the work is out of sprint,
> >
>
> Is your objective to stop out of Sprint work or to have a more effective way
> of handling the new stories that comes up. How long are your sprints,
> intention of the question is to explore whether the Sprint duration has
> anything to do with out of Sprint .
>
> > which they set aside story points for every sprint. (My only victory thus
> > far as their SM.)
> >
> > We started tracking out of sprint work so not only the team, but also so
> > management could see how little actual planned for work is being
> > accomplished during the sprint. This tracking, unfortunately become the
> > accepted norm.
> >
> > Mike
> >
> >
> > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
> > Alan Dayley <alandd@> wrote:
> > >
> > > This appears to be a case of the team not knowing what they are missing.
> > In
> > > other words, they don't see a problem to solve so they refuse the
> > solution
> > > as not needed. Education is the answer and may take a while.
> > >
> > > Another likely issue is that they fear application of more control around
> > > the interruptive work. If they choose to track the flow of the
> > > interruptions that means they sometimes will have to stop accepting
> > another
> > > task. Maybe they fear having to work with and regulate incoming requests.
> > > Again, education of the team and the people making requests is necessary.
> > >
> > > I find two major sources of objections to pair-programming.
> > >
> > > First, many individuals like to be specialists and see value in being The
> > > One with the answers for specific needs. They see specialization as job
> > > security. This fear has some basis in fact and has to be addressed by
> > > providing confidence that their individual value is secure as possible,
> > even
> > > if someone else also has similar skills and knowledge.
> > >
> > > Second pair-programming is seen as inefficient. Two people working on one
> > > task is percieved as wasteful since a second task by the second person is
> > > not being worked on. Education about pair programming benefits in code
> > > quality, cross-training, culture and team building is needed there.
> > >
> > > A quick approach to get past the education need is to couch the new idea
> > as
> > > an experiment. For example, if they still object to pair-programming,
> > > suggest that the team try it for just one sprint. One experiment is worth
> > a
> > > thousand or more white papers and a million presentation slides!
> > >
> > > Alan
> > >
> > > On Mon, Aug 30, 2010 at 10:53 AM, Michael <mikeabugow@> wrote:
> > >
> > > >
> > > >
> > > > Hi All. I have relatively small Scrum team that is responsible for
> > database
> > > > design, and maintenance. Unfortunately, this team is treated as an
> > > > operations type team, but is still expected to run as an Agile Scrum
> > team.
> > > > Greater than 60% of their work is out of sprint tasks. I have suggested
> > that
> > > > they try incorporating Kanban as part of their development cycles.
> > > > Unfortunately, neither the team, nor their P.O. sees this as a viable
> > > > alternative to having constant out of sprint work given to them.
> > > >
> > > > Also, each member of the team is considered a specialist in their
> > > > day-to-day work by the other team members. I have suggested the team
> > try
> > > > pair-programming so that they each can pick up any task at any time.
> > Again,
> > > > the team has not seen the value in this.
> > > >
> > > > Any suggestions on how I can help this highly specialized, and
> > constantly
> > > > distracted team?
> > > >
> > > > Thanks,
> > > > Mike
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

#48206

From: Kevin Johnston <kevj121@...>
Date: Wed Sep 1, 2010 3:45 pm
Subject: Re: Re: What to do when the team is not firing on all cylinders?

kevj121

Hi mike

Why is the out of sprint work being done first if you have a backlog maybe it should be added to it and prioritised?

Regards

Kevin

Sent from my iPhone

On 1 Sep 2010, at 15:15, "Michael" <mikeabugow@...> wrote:

Hi All,

My goal is to help this team respond to their sprint backlog effectively, and to help the P.O. say no to the out of sprint work that continually comes up. Myself and one of the other ScrumMasters in my division agree that a Kanban approach would be more appropriate for this type of development team. Unfortunately, upper-management does not feel that switching to Kanban is a worthwhile exercise.

The team sees itself as getting more work done than ever before, and feels they are doing a good job when they get the little amount of actual planned work completed along with all of the planned for out of sprint work.

Mike

--- In scrumdevelopment@yahoogroups.com, Bachan Anand <bachans@...> wrote:
>
> Michael ,
> Great post !!
>
> On Tue, Aug 31, 2010 at 8:14 AM, Michael <mikeabugow@...> wrote:
>
> >
> >
> > Alan,
> >
> > Agreed, this is a case of education and fear. I have discussed this with
> > the team in multiple retrospectives, and their group opinion is they are
> > doing fine because they are getting so much work accomplished. Even though,
> > most of the work is out of sprint,
> >
>
> Is your objective to stop out of Sprint work or to have a more effective way
> of handling the new stories that comes up. How long are your sprints,
> intention of the question is to explore whether the Sprint duration has
> anything to do with out of Sprint .
>
> > which they set aside story points for every sprint. (My only victory thus
> > far as their SM.)
> >
> > We started tracking out of sprint work so not only the team, but also so
> > management could see how little actual planned for work is being
> > accomplished during the sprint. This tracking, unfortunately become the
> > accepted norm.
> >
> > Mike
> >
> >
> > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
> > Alan Dayley <alandd@> wrote:
> > >
> > > This appears to be a case of the team not knowing what they are missing.
> > In
> > > other words, they don't see a problem to solve so they refuse the
> > solution
> > > as not needed. Education is the answer and may take a while.
> > >
> > > Another likely issue is that they fear application of more control around
> > > the interruptive work. If they choose to track the flow of the
> > > interruptions that means they sometimes will have to stop accepting
> > another
> > > task. Maybe they fear having to work with and regulate incoming requests.
> > > Again, education of the team and the people making requests is necessary.
> > >
> > > I find two major sources of objections to pair-programming.
> > >
> > > First, many individuals like to be specialists and see value in being The
> > > One with the answers for specific needs. They see specialization as job
> > > security. This fear has some basis in fact and has to be addressed by
> > > providing confidence that their individual value is secure as possible,
> > even
> > > if someone else also has similar skills and knowledge.
> > >
> > > Second pair-programming is seen as inefficient. Two people working on one
> > > task is percieved as wasteful since a second task by the second person is
> > > not being worked on. Education about pair programming benefits in code
> > > quality, cross-training, culture and team building is needed there.
> > >
> > > A quick approach to get past the education need is to couch the new idea
> > as
> > > an experiment. For example, if they still object to pair-programming,
> > > suggest that the team try it for just one sprint. One experiment is worth
> > a
> > > thousand or more white papers and a million presentation slides!
> > >
> > > Alan
> > >
> > > On Mon, Aug 30, 2010 at 10:53 AM, Michael <mikeabugow@> wrote:
> > >
> > > >
> > > >
> > > > Hi All. I have relatively small Scrum team that is responsible for
> > database
> > > > design, and maintenance. Unfortunately, this team is treated as an
> > > > operations type team, but is still expected to run as an Agile Scrum
> > team.
> > > > Greater than 60% of their work is out of sprint tasks. I have suggested
> > that
> > > > they try incorporating Kanban as part of their development cycles.
> > > > Unfortunately, neither the team, nor their P.O. sees this as a viable
> > > > alternative to having constant out of sprint work given to them.
> > > >
> > > > Also, each member of the team is considered a specialist in their
> > > > day-to-day work by the other team members. I have suggested the team
> > try
> > > > pair-programming so that they each can pick up any task at any time.
> > Again,
> > > > the team has not seen the value in this.
> > > >
> > > > Any suggestions on how I can help this highly specialized, and
> > constantly
> > > > distracted team?
> > > >
> > > > Thanks,
> > > > Mike
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

#48207

From: Alan Dayley <alandd@...>
Date: Wed Sep 1, 2010 3:52 pm
Subject: Re: Re: What to do when the team is not firing on all cylinders?

alandond

The question remains: Why do you want the PO to say no to the out of sprint work?

I agree that the team doing the majority of their work outside of Scrum is a problem for the Scrum process. �But, is it a problem for the company? �What pain is being felt by the team or PO or customers or someone that "saying no" will help solve? �What value does refusing out of sprint work bring that is more valuable than the current status?

The point is that people who don't feel the pain or see a significant possible benefit, won't want to change. �Answering the above questions may help you find the way to implement the change. �Or may help you see a different path.

Alan

On Wed, Sep 1, 2010 at 7:15 AM, Michael <mikeabugow@...> wrote:

�

Hi All,

My goal is to help this team respond to their sprint backlog effectively, and to help the P.O. say no to the out of sprint work that continually comes up. Myself and one of the other ScrumMasters in my division agree that a Kanban approach would be more appropriate for this type of development team. Unfortunately, upper-management does not feel that switching to Kanban is a worthwhile exercise.

The team sees itself as getting more work done than ever before, and feels they are doing a good job when they get the little amount of actual planned work completed along with all of the planned for out of sprint work.

Mike

--- In scrumdevelopment@yahoogroups.com, Bachan Anand <bachans@...> wrote:
>
> Michael ,
> Great post !!
>
> On Tue, Aug 31, 2010 at 8:14 AM, Michael <mikeabugow@...> wrote:
>
> >
> >
> > Alan,
> >
> > Agreed, this is a case of education and fear. I have discussed this with
> > the team in multiple retrospectives, and their group opinion is they are
> > doing fine because they are getting so much work accomplished. Even though,
> > most of the work is out of sprint,
> >
>
> Is your objective to stop out of Sprint work or to have a more effective way
> of handling the new stories that comes up. How long are your sprints,
> intention of the question is to explore whether the Sprint duration has
> anything to do with out of Sprint .
>
> > which they set aside story points for every sprint. (My only victory thus
> > far as their SM.)
> >
> > We started tracking out of sprint work so not only the team, but also so
> > management could see how little actual planned for work is being
> > accomplished during the sprint. This tracking, unfortunately become the
> > accepted norm.
> >
> > Mike
> >
> >
> > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,

> > Alan Dayley <alandd@> wrote:
> > >
> > > This appears to be a case of the team not knowing what they are missing.
> > In
> > > other words, they don't see a problem to solve so they refuse the
> > solution
> > > as not needed. Education is the answer and may take a while.
> > >
> > > Another likely issue is that they fear application of more control around
> > > the interruptive work. If they choose to track the flow of the
> > > interruptions that means they sometimes will have to stop accepting
> > another
> > > task. Maybe they fear having to work with and regulate incoming requests.
> > > Again, education of the team and the people making requests is necessary.
> > >
> > > I find two major sources of objections to pair-programming.
> > >
> > > First, many individuals like to be specialists and see value in being The
> > > One with the answers for specific needs. They see specialization as job
> > > security. This fear has some basis in fact and has to be addressed by
> > > providing confidence that their individual value is secure as possible,
> > even
> > > if someone else also has similar skills and knowledge.
> > >
> > > Second pair-programming is seen as inefficient. Two people working on one
> > > task is percieved as wasteful since a second task by the second person is
> > > not being worked on. Education about pair programming benefits in code
> > > quality, cross-training, culture and team building is needed there.
> > >
> > > A quick approach to get past the education need is to couch the new idea
> > as
> > > an experiment. For example, if they still object to pair-programming,
> > > suggest that the team try it for just one sprint. One experiment is worth
> > a
> > > thousand or more white papers and a million presentation slides!
> > >
> > > Alan
> > >
> > > On Mon, Aug 30, 2010 at 10:53 AM, Michael <mikeabugow@> wrote:
> > >
> > > >
> > > >
> > > > Hi All. I have relatively small Scrum team that is responsible for
> > database
> > > > design, and maintenance. Unfortunately, this team is treated as an
> > > > operations type team, but is still expected to run as an Agile Scrum
> > team.
> > > > Greater than 60% of their work is out of sprint tasks. I have suggested
> > that
> > > > they try incorporating Kanban as part of their development cycles.
> > > > Unfortunately, neither the team, nor their P.O. sees this as a viable
> > > > alternative to having constant out of sprint work given to them.
> > > >
> > > > Also, each member of the team is considered a specialist in their
> > > > day-to-day work by the other team members. I have suggested the team
> > try
> > > > pair-programming so that they each can pick up any task at any time.
> > Again,
> > > > the team has not seen the value in this.
> > > >
> > > > Any suggestions on how I can help this highly specialized, and
> > constantly
> > > > distracted team?
> > > >
> > > > Thanks,
> > > > Mike
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

#48208

From: Kevin Johnston <kevj121@...>
Date: Wed Sep 1, 2010 4:01 pm
Subject: Re: Re: What to do when the team is not firing on all cylinders?

kevj121

Hi mike

Why is the out of sprint work being done first if you have a backlog maybe it should be added to it and prioritised?

Regards

Kevin

Sent from my iPhone

On 1 Sep 2010, at 15:15, "Michael" <mikeabugow@...> wrote:

Hi All,

My goal is to help this team respond to their sprint backlog effectively, and to help the P.O. say no to the out of sprint work that continually comes up. Myself and one of the other ScrumMasters in my division agree that a Kanban approach would be more appropriate for this type of development team. Unfortunately, upper-management does not feel that switching to Kanban is a worthwhile exercise.

The team sees itself as getting more work done than ever before, and feels they are doing a good job when they get the little amount of actual planned work completed along with all of the planned for out of sprint work.

Mike

--- In scrumdevelopment@yahoogroups.com, Bachan Anand <bachans@...> wrote:
>
> Michael ,
> Great post !!
>
> On Tue, Aug 31, 2010 at 8:14 AM, Michael <mikeabugow@...> wrote:
>
> >
> >
> > Alan,
> >
> > Agreed, this is a case of education and fear. I have discussed this with
> > the team in multiple retrospectives, and their group opinion is they are
> > doing fine because they are getting so much work accomplished. Even though,
> > most of the work is out of sprint,
> >
>
> Is your objective to stop out of Sprint work or to have a more effective way
> of handling the new stories that comes up. How long are your sprints,
> intention of the question is to explore whether the Sprint duration has
> anything to do with out of Sprint .
>
> > which they set aside story points for every sprint. (My only victory thus
> > far as their SM.)
> >
> > We started tracking out of sprint work so not only the team, but also so
> > management could see how little actual planned for work is being
> > accomplished during the sprint. This tracking, unfortunately become the
> > accepted norm.
> >
> > Mike
> >
> >
> > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
> > Alan Dayley <alandd@> wrote:
> > >
> > > This appears to be a case of the team not knowing what they are missing.
> > In
> > > other words, they don't see a problem to solve so they refuse the
> > solution
> > > as not needed. Education is the answer and may take a while.
> > >
> > > Another likely issue is that they fear application of more control around
> > > the interruptive work. If they choose to track the flow of the
> > > interruptions that means they sometimes will have to stop accepting
> > another
> > > task. Maybe they fear having to work with and regulate incoming requests.
> > > Again, education of the team and the people making requests is necessary.
> > >
> > > I find two major sources of objections to pair-programming.
> > >
> > > First, many individuals like to be specialists and see value in being The
> > > One with the answers for specific needs. They see specialization as job
> > > security. This fear has some basis in fact and has to be addressed by
> > > providing confidence that their individual value is secure as possible,
> > even
> > > if someone else also has similar skills and knowledge.
> > >
> > > Second pair-programming is seen as inefficient. Two people working on one
> > > task is percieved as wasteful since a second task by the second person is
> > > not being worked on. Education about pair programming benefits in code
> > > quality, cross-training, culture and team building is needed there.
> > >
> > > A quick approach to get past the education need is to couch the new idea
> > as
> > > an experiment. For example, if they still object to pair-programming,
> > > suggest that the team try it for just one sprint. One experiment is worth
> > a
> > > thousand or more white papers and a million presentation slides!
> > >
> > > Alan
> > >
> > > On Mon, Aug 30, 2010 at 10:53 AM, Michael <mikeabugow@> wrote:
> > >
> > > >
> > > >
> > > > Hi All. I have relatively small Scrum team that is responsible for
> > database
> > > > design, and maintenance. Unfortunately, this team is treated as an
> > > > operations type team, but is still expected to run as an Agile Scrum
> > team.
> > > > Greater than 60% of their work is out of sprint tasks. I have suggested
> > that
> > > > they try incorporating Kanban as part of their development cycles.
> > > > Unfortunately, neither the team, nor their P.O. sees this as a viable
> > > > alternative to having constant out of sprint work given to them.
> > > >
> > > > Also, each member of the team is considered a specialist in their
> > > > day-to-day work by the other team members. I have suggested the team
> > try
> > > > pair-programming so that they each can pick up any task at any time.
> > Again,
> > > > the team has not seen the value in this.
> > > >
> > > > Any suggestions on how I can help this highly specialized, and
> > constantly
> > > > distracted team?
> > > >
> > > > Thanks,
> > > > Mike
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

#48209

From: Kevin Johnston <kevj121@...>
Date: Wed Sep 1, 2010 4:13 pm
Subject: Re: Re: What to do when the team is not firing on all cylinders?

kevj121

Hi mike

Why is the out of sprint work being done first if you have a backlog maybe it should be added to it and prioritised?

Regards

Kevin

Sent from my iPhone

#48210

From: Dan Rawsthorne <dan.rawsthorne@...>
Date: Wed Sep 1, 2010 4:15 pm
Subject: Re: Template of task breakdown for a user story

drawstho

I think that this is probably a bad idea, as it structures the work,
rather than let the team self-organize around the work. I have the same
problem with talk boards with a lot of columns - trying to let process
replace thinking. It's an interesting problem...

Dan Rawsthorne, PhD, CST
Senior Trainer/Coach, CollabNet
drawsthorne@..., 425-269-8628

Hiren Doshi wrote:
>
>
> In a few Agile/Scrum training and coaching engagements that I have
> been involved with, I shared the template of ‘*task breakdown for a
> user story*' and found that teams find it very useful. This task list
> also defines ‘done’ criteria for the story. I am sharing the same
> template with everyone in this forum for your reference.
>
> http://www.practiceagile.com/2010/08/template-of-task-breakdown-for-user.html
>
>
>
>

#48211

From: Maurice le Rutte <maurice.lerutte@...>
Date: Wed Sep 1, 2010 4:31 pm
Subject: Re: Template of task breakdown for a user story

scrumnl

Is it a bad idea to have a standard set of 'reminder' tasks or this instance of tasks as defined by the blog post?

We have used several standard tasks in our breakdown too, as in 'update the release notes', 'update test script','test on integrated hardware'. We didn't write them down, but we knew we had to do them and when making the sprint planning we added them. Mostly somebody would remark as 'and of course we have to do...'.

The risk of process replacing thinking is only if people who get coached/trained by Hiren go back to their teams and say 'I have learned that we should do the following tasks...'. But for that I'd actually have to be present at a training session and follow a client around.

Maurice le Rutte.

Op 1-9-2010 18:15, Dan Rawsthorne schreef:

I think that this is probably a bad idea, as it structures the work,
rather than let the team self-organize around the work. I have the same
problem with talk boards with a lot of columns - trying to let process
replace thinking. It's an interesting problem...

Dan Rawsthorne, PhD, CST
Senior Trainer/Coach, CollabNet
drawsthorne@..., 425-269-8628

Hiren Doshi wrote:
>

-- http://www.scrummaster.nl / http://twitter.com/scrumnl

#48212

From: Malcolm Anderson <malcolm.b.anderson@...>
Date: Wed Sep 1, 2010 4:31 pm
Subject: Re: Re: What to do when the team is not firing on all cylinders?

malcolm9999

Michael

4 questions.

What is "upper-managements" feelings about what you have already accomplished?�

What measurements of progress have you been able to give "upper-management"?

What is / are "upper-management's" biggest concerns about the company's growth?

How many people is "upper-management" comprised of?

Malcolm

On Wed, Sep 1, 2010 at 10:15 AM, Michael <mikeabugow@...> wrote:

�

Hi All,

My goal is to help this team respond to their sprint backlog effectively, and to help the P.O. say no to the out of sprint work that continually comes up. Myself and one of the other ScrumMasters in my division agree that a Kanban approach would be more appropriate for this type of development team. Unfortunately, upper-management does not feel that switching to Kanban is a worthwhile exercise.

The team sees itself as getting more work done than ever before, and feels they are doing a good job when they get the little amount of actual planned work completed along with all of the planned for out of sprint work.

Mike

--- In scrumdevelopment@yahoogroups.com, Bachan Anand <bachans@...> wrote:
>
> Michael ,
> Great post !!
>
> On Tue, Aug 31, 2010 at 8:14 AM, Michael <mikeabugow@...> wrote:
>
> >
> >
> > Alan,
> >
> > Agreed, this is a case of education and fear. I have discussed this with
> > the team in multiple retrospectives, and their group opinion is they are
> > doing fine because they are getting so much work accomplished. Even though,
> > most of the work is out of sprint,
> >
>
> Is your objective to stop out of Sprint work or to have a more effective way
> of handling the new stories that comes up. How long are your sprints,
> intention of the question is to explore whether the Sprint duration has
> anything to do with out of Sprint .
>
> > which they set aside story points for every sprint. (My only victory thus
> > far as their SM.)
> >
> > We started tracking out of sprint work so not only the team, but also so
> > management could see how little actual planned for work is being
> > accomplished during the sprint. This tracking, unfortunately become the
> > accepted norm.
> >
> > Mike
> >
> >
> > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,

> > Alan Dayley <alandd@> wrote:
> > >
> > > This appears to be a case of the team not knowing what they are missing.
> > In
> > > other words, they don't see a problem to solve so they refuse the
> > solution
> > > as not needed. Education is the answer and may take a while.
> > >
> > > Another likely issue is that they fear application of more control around
> > > the interruptive work. If they choose to track the flow of the
> > > interruptions that means they sometimes will have to stop accepting
> > another
> > > task. Maybe they fear having to work with and regulate incoming requests.
> > > Again, education of the team and the people making requests is necessary.
> > >
> > > I find two major sources of objections to pair-programming.
> > >
> > > First, many individuals like to be specialists and see value in being The
> > > One with the answers for specific needs. They see specialization as job
> > > security. This fear has some basis in fact and has to be addressed by
> > > providing confidence that their individual value is secure as possible,
> > even
> > > if someone else also has similar skills and knowledge.
> > >
> > > Second pair-programming is seen as inefficient. Two people working on one
> > > task is percieved as wasteful since a second task by the second person is
> > > not being worked on. Education about pair programming benefits in code
> > > quality, cross-training, culture and team building is needed there.
> > >
> > > A quick approach to get past the education need is to couch the new idea
> > as
> > > an experiment. For example, if they still object to pair-programming,
> > > suggest that the team try it for just one sprint. One experiment is worth
> > a
> > > thousand or more white papers and a million presentation slides!
> > >
> > > Alan
> > >
> > > On Mon, Aug 30, 2010 at 10:53 AM, Michael <mikeabugow@> wrote:
> > >
> > > >
> > > >
> > > > Hi All. I have relatively small Scrum team that is responsible for
> > database
> > > > design, and maintenance. Unfortunately, this team is treated as an
> > > > operations type team, but is still expected to run as an Agile Scrum
> > team.
> > > > Greater than 60% of their work is out of sprint tasks. I have suggested
> > that
> > > > they try incorporating Kanban as part of their development cycles.
> > > > Unfortunately, neither the team, nor their P.O. sees this as a viable
> > > > alternative to having constant out of sprint work given to them.
> > > >
> > > > Also, each member of the team is considered a specialist in their
> > > > day-to-day work by the other team members. I have suggested the team
> > try
> > > > pair-programming so that they each can pick up any task at any time.
> > Again,
> > > > the team has not seen the value in this.
> > > >
> > > > Any suggestions on how I can help this highly specialized, and
> > constantly
> > > > distracted team?
> > > >
> > > > Thanks,
> > > > Mike
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

#48213

From: David A Barrett <dave.barrett@...>
Date: Wed Sep 1, 2010 4:39 pm
Subject: Re: What to do when the team is not firing on all cylinders?

barrettdab

I think I'd take a different approach to this.

If the problem is that the team is spending too much time on "out of Sprint" items, then pull those activities into the Sprints. Create some simple rules (I'd suggest based on the amount of effort required to complete one of these "out of Sprint" activities and its urgency) to decide when an activity is appropriate to being handled in an ad hoc manner, and when it needs to be added to a PB and prioritized. And then make sure the Team lives by those rules.

Create a PB for maintenance items. When you do your Sprint planning, consider the Maintenance PB alongside your development project PB and decide which is the most important to the organization.

The big thing here is that you're currently letting virtually anyone in the company highjack the Development Team who, probably, don't have the knowledge or authority to decide what should be done right now, and what shouldn't. So by giving them some clear guidelines to push back on ad hoc jobs that smell big and non-urgent, it goes back to the PO and the management of the departments requesting the ad hoc tasks to decide what needs to be done first.

I think you'll be surprised at how little people get upset when you tell them that some big job will need to wait until it can be prioritized into a Sprint. The other thing that you'll find is that people will started adding stuff to the maintenance PB all by themselves (and then following up with their department management to make sure that it gets a high priority) or that they'll start coming to the Team and asking, "This is big and not too urgent. Do I need to put it on the PB". Finally, they'll figure out that they need to plan in order to get stuff done and they'll actually start putting the stuff into the Maintenance PB as soon as they know about instead of waiting until the last minute.

The big win is transparency. The fact is, the guys in Marketing know that they're planning a big mailing in October, and they've known it for 6 months. And when they come to you on September 28th, 1 week into your 4 week Sprint, because they need you to add 2 new servers to the web server farm to handle the increased traffic that it will generate, and they also need some "rush" programming done to track the visits in some special way then that's going to take 6 man days to complete, then you tell them, "To do that, we'll need to terminate the current Sprint and re-plan". And, of course, the PO needs to do that. And the PO might tell the Marketing guys to pound sand. Or not, but the Marketing guys may look like a bunch of twits because they sat on this info for months. But the Team is NEVER pulled in two directions on this.

Dave Barrett

This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

Ce courrier �lectronique est confidentiel et prot�g�. L'exp�diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d�sign�(s) est interdite. Si vous recevez ce courrier �lectronique par erreur, veuillez le supprimer et m'en aviser imm�diatement, par retour de courrier �lectronique ou par un autre moyen.

#48214

From: Ilja Preu� <iljapreuss@...>
Date: Wed Sep 1, 2010 4:43 pm
Subject: Re: Template of task breakdown for a user story

ipreussde

In my experience, it just happens naturally that a team comes up with a set of standard tasks that they think of for every story, and that is a good thing.

I guess a collection of stories of how different teams came up with different sets of "standard tasks", and how they helped them, might be useful for coaching new teams.

My gut says that one extensive list presented to an inexperienced team is likely to do more harm than good.

Cheers, Ilja

2010/9/1 Maurice le Rutte <maurice.lerutte@...>

Is it a bad idea to have a standard set� of 'reminder' tasks or this instance of tasks as defined by the blog post?

We have used several standard tasks in our breakdown too, as in 'update the release notes', 'update test script','test on integrated hardware'. We didn't write them down, but we knew we had to do them and when making the sprint planning we added them. Mostly somebody would remark as 'and of course we have to do...'.

The risk of process replacing thinking is only if people who get coached/trained by Hiren go back to their teams and say 'I have learned that we should do the following tasks...'. But for that I'd actually have to be present at a training session and follow a client around.

Maurice le Rutte.

Op 1-9-2010 18:15, Dan Rawsthorne schreef:
�

I think that this is probably a bad idea, as it structures the work,
rather than let the team self-organize around the work. I have the same
problem with talk boards with a lot of columns - trying to let process
replace thinking. It's an interesting problem...

Dan Rawsthorne, PhD, CST
Senior Trainer/Coach, CollabNet
drawsthorne@..., 425-269-8628

Hiren Doshi wrote:
>

-- http://www.scrummaster.nl / http://twitter.com/scrumnl

#48215

From: Maurice le Rutte <maurice.lerutte@...>
Date: Wed Sep 1, 2010 5:28 pm
Subject: Re: What to do when the team is not firing on all cylinders?

scrumnl

I've read some excellent responses in this thread to which I have little to add. However in your post there is an intriguing line that says "this team is treated as an operations type team, but is still expected to run as an Agile Scrum team".

Who expects the team to be doing Scrum, but who has the power to ignore all that and treat it differently? If they are supposed to be doing Scrum and it is backed by management I assume there is a ScrumMaster. Then why doesn't the ScrumMaster shout a big 'no' when interrupting work is brought into the sprint?

Maurice.
--

http://www.scrummaster.nl / http://twitter.com/scrumnl

#48216

From: "barrettdab" <dave.barrett@...>
Date: Wed Sep 1, 2010 6:13 pm
Subject: Re: What to do when the team is not firing on all cylinders?

barrettdab

But this is reality for many, many developers.  In many companies, the
programmers that built something become the SME's when support issues come up. 
Not just bug fixes, but ad hoc reporting, performance management, data fixes,
consulting and training, and God knows what else.  And if all the experts are
working on new development?  Tough.  Business has to keep on going day to day.

Personally, I think it would be a real shame if we said to everyone working in
those circumstances (which I strongly suspect is a large majority of programmers
out there in the real world), "Sorry, unless you're in a team totally dedicated
to single, multi-iteration project doing greenfield development without any
maintenance responsibilities, you can't do Scrum".  Mostly, because it's not
true.

#48217

From: Kevin Johnston <kevj121@...>
Date: Wed Sep 1, 2010 6:23 pm
Subject: Re: What to do when the team is not firing on all cylinders?

kevj121

Hi barretdab

You are correct, I work in this kind of environment but the way I see it if we
the scrum team let quality drop we have to deal with the support that cones with
it! Hopefully this motivates the team to do what is needed to ensure velocity is
maintained by focussing on quality and applying the xp engineering disciplines.

Regards


Kevin

Sent from my iPhone

Sent from my iPhone

#48219

From: Maurice le Rutte <maurice.lerutte@...>
Date: Wed Sep 1, 2010 7:14 pm
Subject: Re: Re: What to do when the team is not firing on all cylinders?

scrumnl

Op 1-9-2010 20:13, barrettdab schreef:

But this is reality for many, many developers. In many companies, the programmers that built something become the SME's when support issues come up. Not just bug fixes, but ad hoc reporting, performance management, data fixes, consulting and training, and God knows what else. And if all the experts are working on new development? Tough. Business has to keep on going day to day.

True.

Things like reporting, appraisels, drinking a cup of hot chocolate, getting trained, going to the toilet, having meetings are a fact of (business) life, and necessary. It is not overhead and if it doesn't get out of hand there is nothing wrong with it and I won't be claiming that a developer should be coding for 100% of his available type.

I didn't list support, for a good reason. "Support" is a rather big area to address. If the company doesn't have a kind of customer support I would strongly advise to try to get a separate customer support. I've seen a separate customer support role in even the smallest companies. And if not then the PO or SM could take up the role. As a ScrumMaster I've done that, filtering out many requests that would otherwise had to be handled by the developers directly. The cool thing about doing this is that you get a rather good idea where the team is lacking some practices.

Defects always seem to be urgent, especially if people have learned that the only way to get their complaints fixed is by being a nuisance. Therefore you need good triage. You can develop some simple guidelines for classification, but even then the hard part is to stick with it.

Now there will be some defects of the type 'urgent & important'. This kind of defects can't be put on the backlog for next sprint and must be handled now. It is a valid reason for a sprint termination. And the most important thing is then looking at why you ever released a product with this kind of defect and what will be changed to avoid it next time.

If the large part of the defects that is flowing in is of this type you should either take a good look at your triage or accept the fact that what you've done in the past wasn't good enough and stop developing new stuff until you have fixed the quality issues. You can't build on a flaky foundation.

Personally, I think it would be a real shame if we said to everyone working in those circumstances (which I strongly suspect is a large majority of programmers out there in the real world), "Sorry, unless you're in a team totally dedicated to single, multi-iteration project doing greenfield development without any maintenance responsibilities, you can't do Scrum". Mostly, because it's not true.

I don't think "Scrum" is suitable for all contexts, especially if you are not willing to live up to some basic rules. I think that you might miss out on some benifits that you can get if you would, but that doesn't mean that you can't do effective software development. You should do Scrum if you think the benifits outweigh the costs, if not find something that better suits you.

Maurice.

-- http://www.scrummaster.nl / http://twitter.com/scrumnl

#48220

From: Jussi Mononen <jussi.mononen@...>
Date: Wed Sep 1, 2010 7:34 pm
Subject: Re: Pointers to ATDD applied in a Legacy environment

jussi_kiloif

Hi George,

On 08/31/2010 02:33 AM, George Dinwiddie wrote:
>
> My experience is that it depends greatly on the particular legacy code,
> but my usual strategy is to
>    * Do ATDD for new work

We do have automated tests in our DoD for everything we do. But 99% of
them are done in parallel or afterwards and thus do not count as ATDD.

Our (huge) system contains quite much legacy, in M.Feathers sense, as in
code without tests

>    * Cover existing functionality with characterization tests

I gues we /could/ rely on our regression test suites and put more effort
in them when brand new features need to be developed. Much work ahead,
that is :)

>    * When existing functionality is modified, consider what, and how
> much, additional testing will be helpful and cost-effective.

We will.

Thanks for everyone who replied!

(Hm, I'm thinking I could write an experience report if we manage to
start doing ATDD.)

Br,

--
- Agile Poodle
- http://www.jussimononen.info/
- http://www.twitter.com/agilepoodle

Reply | Messages in this Topic (11)

#48221

From: Jussi Mononen <jussi.mononen@...>
Date: Wed Sep 1, 2010 7:43 pm
Subject: Re: Re:Pointers to ATDD applied in a Legacy environment

jussi_kiloif

On 08/31/2010 03:44 PM, alexis.hui@... wrote:
>
> How legacy is "legacy"? I have successfully done ATDD in three
> environments that can be considered legacy depending on your definition:

Hmm, ~2-300 000 LoC without unit tests, mixed platform and UI written in
C/C++/Java/PHP/Perl ...

> The critical enablers I found to make it successful were:
> - Refactor mercilessly and move towards dependency injection where
> possible, most legacy code self initializes dependencies which make any
> stubbing or mocking impossible (suggest reading Michael Feathers book on
> legacy code)
> - Leverage open source testing frameworks where possible, I used a
> combination of Junit, DBunit, jMock and Spring to get what I needed
> - Be creative and invest, I have custom built my own ATDD framework to
> test complex unix shell scripts for ETL by using a combination of regex,
> sql and light shell scripts, also done the same for MIPS assemble before
>
> One big challenge I find is getting a suitable environment. Often you
> need to think about data and external system integration dependencies.
> Fortunately, I have either had control to own the data environment and
> had easy to stub external dependencies in my situations. Trick here is
> often finding a way to get your own slice of the data environment
> (separate schema dedicated to acceptance tests perhaps or even modifying
> table names with something like _AT), and creatively stubbing/wrapping
> dependencies.

Sounds like the path I/we have envisaged.

At certain parts of our code we are currently bound to so old compilers
(due to large and old customer base) that we for example can't use the
lates test frameworks for C/C++ (we would love to take Boost test into use).

So, I think we are generally on the right path with our thinking. Now
there's only the biggest hurdle left, convicing The Management that the
pain and time it takes to fix things now, will lessen the work in future.

Thanks!

Br,

--
- Agile Poodle
- http://www.jussimononen.info/
- http://www.twitter.com/agilepoodle

Reply | Messages in this Topic (11)

#48222

From: Malcolm Anderson <malcolm.b.anderson@...>
Date: Wed Sep 1, 2010 8:43 pm
Subject: Getting to the question behind the question

malcolm9999

I'm coaching in a Fortune 500 company, and I had someone ask something
to the effect of, "where has Scrum worked?"

I didn't have a good answer.  More importantly, I didn't have a good
question for that.

My gut feeling is that this wasn't the real question.

Here are my questions

1) How should I have answered that?

2) Does anyone know of an accessible list of big visible places where
"Scrum has worked" ?

Thanks

Malcolm

#48223

From: "JackM" <jack@...>
Date: Wed Sep 1, 2010 9:19 pm
Subject: Re: Getting to the question behind the question

jmilunsky

There are ton's of examples. Google, Yahoo, to name just two

Jack
www.agilebuddy.com

--- In scrumdevelopment@yahoogroups.com, Malcolm Anderson
<malcolm.b.anderson@...> wrote:
>
> I'm coaching in a Fortune 500 company, and I had someone ask something
> to the effect of, "where has Scrum worked?"
>
> I didn't have a good answer.  More importantly, I didn't have a good
> question for that.
>
> My gut feeling is that this wasn't the real question.
>
> Here are my questions
>
> 1) How should I have answered that?
>
> 2) Does anyone know of an accessible list of big visible places where
> "Scrum has worked" ?
>
> Thanks
>
> Malcolm
>

#48224

From: Alan Dayley <alandd@...>
Date: Wed Sep 1, 2010 9:43 pm
Subject: Re: Getting to the question behind the question

alandond

I agree that there is more to this question than will be satisfied by a direct answer. �At least, that is my experience with this question.

First, a single, direct answer: http://danube.com/docs/case_studies/Intel_case_study.pdf

My question for this question is usually something like:

"Scrum has been tried and works in many companies. �Do you think it won't work at your company? �Why?"

The person asking usually has personal objections or has thought of how Scrum might fail at their company, so they are looking for reassurance. �Or they are looking for "proof" that they can then shoot holes in to show it won't work.

It is better the address the fear than to cover it with white papers.

Alan

On Wed, Sep 1, 2010 at 1:43 PM, Malcolm Anderson <malcolm.b.anderson@...> wrote:

�

I'm coaching in a Fortune 500 company, and I had someone ask something
to the effect of, "where has Scrum worked?"

I didn't have a good answer. More importantly, I didn't have a good
question for that.

My gut feeling is that this wasn't the real question.

Here are my questions

1) How should I have answered that?

2) Does anyone know of an accessible list of big visible places where
"Scrum has worked" ?

Thanks

Malcolm

#48225

From: Alan Dayley <alandd@...>
Date: Wed Sep 1, 2010 9:47 pm
Subject: Re: Getting to the question behind the question

alandond

http://agilepainrelief.com/notesfromatooluser/2008/11/scrum-case-studies.html

Hey, just found a better list of case studies on Mark Levinson's blog:

Alan

On Wed, Sep 1, 2010 at 2:43 PM, Alan Dayley <alandd@...> wrote:

I agree that there is more to this question than will be satisfied by a direct answer. �At least, that is my experience with this question.

First, a single, direct answer: http://danube.com/docs/case_studies/Intel_case_study.pdf

My question for this question is usually something like:

"Scrum has been tried and works in many companies. �Do you think it won't work at your company? �Why?"

The person asking usually has personal objections or has thought of how Scrum might fail at their company, so they are looking for reassurance. �Or they are looking for "proof" that they can then shoot holes in to show it won't work.

It is better the address the fear than to cover it with white papers.

Alan

On Wed, Sep 1, 2010 at 1:43 PM, Malcolm Anderson <malcolm.b.anderson@...> wrote:

�

I'm coaching in a Fortune 500 company, and I had someone ask something
to the effect of, "where has Scrum worked?"

I didn't have a good answer. More importantly, I didn't have a good
question for that.

My gut feeling is that this wasn't the real question.

Here are my questions

1) How should I have answered that?

2) Does anyone know of an accessible list of big visible places where
"Scrum has worked" ?

Thanks

Malcolm

#48226

From: Malcolm Anderson <malcolm.b.anderson@...>
Date: Wed Sep 1, 2010 10:32 pm
Subject: Re: Getting to the question behind the question

malcolm9999

Alan

Thank you, that is exactly what I needed.

Malcolm

On Wed, Sep 1, 2010 at 5:47 PM, Alan Dayley <alandd@...> wrote:

�

Hey, just found a better list of case studies on Mark Levinson's blog:

http://agilepainrelief.com/notesfromatooluser/2008/11/scrum-case-studies.html

Alan

On Wed, Sep 1, 2010 at 2:43 PM, Alan Dayley <alandd@...> wrote:

I agree that there is more to this question than will be satisfied by a direct answer. �At least, that is my experience with this question.

First, a single, direct answer: http://danube.com/docs/case_studies/Intel_case_study.pdf

My question for this question is usually something like:

"Scrum has been tried and works in many companies. �Do you think it won't work at your company? �Why?"

The person asking usually has personal objections or has thought of how Scrum might fail at their company, so they are looking for reassurance. �Or they are looking for "proof" that they can then shoot holes in to show it won't work.

It is better the address the fear than to cover it with white papers.

Alan

On Wed, Sep 1, 2010 at 1:43 PM, Malcolm Anderson <malcolm.b.anderson@...> wrote:

�

I'm coaching in a Fortune 500 company, and I had someone ask something
to the effect of, "where has Scrum worked?"

I didn't have a good answer. More importantly, I didn't have a good
question for that.

My gut feeling is that this wasn't the real question.

Here are my questions

1) How should I have answered that?

2) Does anyone know of an accessible list of big visible places where
"Scrum has worked" ?

Thanks

Malcolm

#48227

From: "Asad" <safari_asad@...>
Date: Wed Sep 1, 2010 10:58 pm
Subject: Convert XPGame to Scrum

safari_asad

Hi folks

We know that the XP Game is good thing for teaching hard understating things
like Estimate and planning in XP method to developers and customers. I'd like
this technique.

I want to use this game in Scrum method. I find difference between only sprint
and iteration title. I can't find any different for using in scrum.

what do you think about these questions :

Can I use the same game in Scrum world without any change? Do i need some change
in game theory?  if i need do change , what is it can be?
What do you think about using XPGame for Scrum ?


Regards

Asad Safari
Agile Coach

Reply | Messages in this Topic (3)

#48228

From: "Michael" <mikeabugow@...>
Date: Wed Sep 1, 2010 11:10 pm
Subject: Re: What to do when the team is not firing on all cylinders?

mikeabugow

Kevin,

The out of sprint work is being done first because these requests are coming
from both the director and the VP of engineering.

Mike

--- In scrumdevelopment@yahoogroups.com, Kevin Johnston <kevj121@...> wrote:
>
> Hi mike
>
> Why is the out of sprint work being done first if you have a backlog maybe it
should be added to it and prioritised?
>
> Regards
>
> Kevin
>
>
>
> Sent from my iPhone
>
> On 1 Sep 2010, at 15:15, "Michael" <mikeabugow@...> wrote:
>
> > Hi All,
> >
> > My goal is to help this team respond to their sprint backlog effectively,
and to help the P.O. say no to the out of sprint work that continually comes up.
Myself and one of the other ScrumMasters in my division agree that a Kanban
approach would be more appropriate for this type of development team.
Unfortunately, upper-management does not feel that switching to Kanban is a
worthwhile exercise.
> >
> > The team sees itself as getting more work done than ever before, and feels
they are doing a good job when they get the little amount of actual planned work
completed along with all of the planned for out of sprint work.
> >
> > Mike
> >
> > --- In scrumdevelopment@yahoogroups.com, Bachan Anand <bachans@> wrote:
> > >
> > > Michael ,
> > > Great post !!
> > >
> > > On Tue, Aug 31, 2010 at 8:14 AM, Michael <mikeabugow@> wrote:
> > >
> > > >
> > > >
> > > > Alan,
> > > >
> > > > Agreed, this is a case of education and fear. I have discussed this with
> > > > the team in multiple retrospectives, and their group opinion is they are
> > > > doing fine because they are getting so much work accomplished. Even
though,
> > > > most of the work is out of sprint,
> > > >
> > >
> > > Is your objective to stop out of Sprint work or to have a more effective
way
> > > of handling the new stories that comes up. How long are your sprints,
> > > intention of the question is to explore whether the Sprint duration has
> > > anything to do with out of Sprint .
> > >
> > > > which they set aside story points for every sprint. (My only victory
thus
> > > > far as their SM.)
> > > >
> > > > We started tracking out of sprint work so not only the team, but also so
> > > > management could see how little actual planned for work is being
> > > > accomplished during the sprint. This tracking, unfortunately become the
> > > > accepted norm.
> > > >
> > > > Mike
> > > >
> > > >
> > > > --- In
scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
> > > > Alan Dayley <alandd@> wrote:
> > > > >
> > > > > This appears to be a case of the team not knowing what they are
missing.
> > > > In
> > > > > other words, they don't see a problem to solve so they refuse the
> > > > solution
> > > > > as not needed. Education is the answer and may take a while.
> > > > >
> > > > > Another likely issue is that they fear application of more control
around
> > > > > the interruptive work. If they choose to track the flow of the
> > > > > interruptions that means they sometimes will have to stop accepting
> > > > another
> > > > > task. Maybe they fear having to work with and regulate incoming
requests.
> > > > > Again, education of the team and the people making requests is
necessary.
> > > > >
> > > > > I find two major sources of objections to pair-programming.
> > > > >
> > > > > First, many individuals like to be specialists and see value in being
The
> > > > > One with the answers for specific needs. They see specialization as
job
> > > > > security. This fear has some basis in fact and has to be addressed by
> > > > > providing confidence that their individual value is secure as
possible,
> > > > even
> > > > > if someone else also has similar skills and knowledge.
> > > > >
> > > > > Second pair-programming is seen as inefficient. Two people working on
one
> > > > > task is percieved as wasteful since a second task by the second person
is
> > > > > not being worked on. Education about pair programming benefits in code
> > > > > quality, cross-training, culture and team building is needed there.
> > > > >
> > > > > A quick approach to get past the education need is to couch the new
idea
> > > > as
> > > > > an experiment. For example, if they still object to pair-programming,
> > > > > suggest that the team try it for just one sprint. One experiment is
worth
> > > > a
> > > > > thousand or more white papers and a million presentation slides!
> > > > >
> > > > > Alan
> > > > >
> > > > > On Mon, Aug 30, 2010 at 10:53 AM, Michael <mikeabugow@> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Hi All. I have relatively small Scrum team that is responsible for
> > > > database
> > > > > > design, and maintenance. Unfortunately, this team is treated as an
> > > > > > operations type team, but is still expected to run as an Agile Scrum
> > > > team.
> > > > > > Greater than 60% of their work is out of sprint tasks. I have
suggested
> > > > that
> > > > > > they try incorporating Kanban as part of their development cycles.
> > > > > > Unfortunately, neither the team, nor their P.O. sees this as a
viable
> > > > > > alternative to having constant out of sprint work given to them.
> > > > > >
> > > > > > Also, each member of the team is considered a specialist in their
> > > > > > day-to-day work by the other team members. I have suggested the team
> > > > try
> > > > > > pair-programming so that they each can pick up any task at any time.
> > > > Again,
> > > > > > the team has not seen the value in this.
> > > > > >
> > > > > > Any suggestions on how I can help this highly specialized, and
> > > > constantly
> > > > > > distracted team?
> > > > > >
> > > > > > Thanks,
> > > > > > Mike
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>

#48229

From: "Michael" <mikeabugow@...>
Date: Wed Sep 1, 2010 11:13 pm
Subject: Re: What to do when the team is not firing on all cylinders?

mikeabugow

Alan,

Thank you for your input.  I'm trying to help the PO with backlog grooming, and
trying to help the team not work outside of business hours to get the work
completed that they agreed to do for the sprint.  I think at this point, if the
team is fine with what is happening then I should continue to help them
accomplish their work.

Mike

--- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
>
> The question remains: Why do you want the PO to say no to the out of sprint
> work?
>
> I agree that the team doing the majority of their work outside of Scrum is a
> problem for the Scrum process.  But, is it a problem for the company?  What
> pain is being felt by the team or PO or customers or someone that "saying
> no" will help solve?  What value does refusing out of sprint work bring that
> is more valuable than the current status?
>
> The point is that people who don't feel the pain or see a significant
> possible benefit, won't want to change.  Answering the above questions may
> help you find the way to implement the change.  Or may help you see a
> different path.
>
> Alan
>
> On Wed, Sep 1, 2010 at 7:15 AM, Michael <mikeabugow@...> wrote:
>
> >
> >
> > Hi All,
> >
> > My goal is to help this team respond to their sprint backlog effectively,
> > and to help the P.O. say no to the out of sprint work that continually comes
> > up. Myself and one of the other ScrumMasters in my division agree that a
> > Kanban approach would be more appropriate for this type of development team.
> > Unfortunately, upper-management does not feel that switching to Kanban is a
> > worthwhile exercise.
> >
> > The team sees itself as getting more work done than ever before, and feels
> > they are doing a good job when they get the little amount of actual planned
> > work completed along with all of the planned for out of sprint work.
> >
> > Mike
> >
> >
> > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
> > Bachan Anand <bachans@> wrote:
> > >
> > > Michael ,
> > > Great post !!
> > >
> > > On Tue, Aug 31, 2010 at 8:14 AM, Michael <mikeabugow@> wrote:
> > >
> > > >
> > > >
> > > > Alan,
> > > >
> > > > Agreed, this is a case of education and fear. I have discussed this
> > with
> > > > the team in multiple retrospectives, and their group opinion is they
> > are
> > > > doing fine because they are getting so much work accomplished. Even
> > though,
> > > > most of the work is out of sprint,
> > > >
> > >
> > > Is your objective to stop out of Sprint work or to have a more effective
> > way
> > > of handling the new stories that comes up. How long are your sprints,
> > > intention of the question is to explore whether the Sprint duration has
> > > anything to do with out of Sprint .
> > >
> > > > which they set aside story points for every sprint. (My only victory
> > thus
> > > > far as their SM.)
> > > >
> > > > We started tracking out of sprint work so not only the team, but also
> > so
> > > > management could see how little actual planned for work is being
> > > > accomplished during the sprint. This tracking, unfortunately become the
> > > > accepted norm.
> > > >
> > > > Mike
> > > >
> > > >
> > > > --- In
scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>
> > <scrumdevelopment%40yahoogroups.com>,
> >
> > > > Alan Dayley <alandd@> wrote:
> > > > >
> > > > > This appears to be a case of the team not knowing what they are
> > missing.
> > > > In
> > > > > other words, they don't see a problem to solve so they refuse the
> > > > solution
> > > > > as not needed. Education is the answer and may take a while.
> > > > >
> > > > > Another likely issue is that they fear application of more control
> > around
> > > > > the interruptive work. If they choose to track the flow of the
> > > > > interruptions that means they sometimes will have to stop accepting
> > > > another
> > > > > task. Maybe they fear having to work with and regulate incoming
> > requests.
> > > > > Again, education of the team and the people making requests is
> > necessary.
> > > > >
> > > > > I find two major sources of objections to pair-programming.
> > > > >
> > > > > First, many individuals like to be specialists and see value in being
> > The
> > > > > One with the answers for specific needs. They see specialization as
> > job
> > > > > security. This fear has some basis in fact and has to be addressed by
> > > > > providing confidence that their individual value is secure as
> > possible,
> > > > even
> > > > > if someone else also has similar skills and knowledge.
> > > > >
> > > > > Second pair-programming is seen as inefficient. Two people working on
> > one
> > > > > task is percieved as wasteful since a second task by the second
> > person is
> > > > > not being worked on. Education about pair programming benefits in
> > code
> > > > > quality, cross-training, culture and team building is needed there.
> > > > >
> > > > > A quick approach to get past the education need is to couch the new
> > idea
> > > > as
> > > > > an experiment. For example, if they still object to pair-programming,
> > > > > suggest that the team try it for just one sprint. One experiment is
> > worth
> > > > a
> > > > > thousand or more white papers and a million presentation slides!
> > > > >
> > > > > Alan
> > > > >
> > > > > On Mon, Aug 30, 2010 at 10:53 AM, Michael <mikeabugow@> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Hi All. I have relatively small Scrum team that is responsible for
> > > > database
> > > > > > design, and maintenance. Unfortunately, this team is treated as an
> > > > > > operations type team, but is still expected to run as an Agile
> > Scrum
> > > > team.
> > > > > > Greater than 60% of their work is out of sprint tasks. I have
> > suggested
> > > > that
> > > > > > they try incorporating Kanban as part of their development cycles.
> > > > > > Unfortunately, neither the team, nor their P.O. sees this as a
> > viable
> > > > > > alternative to having constant out of sprint work given to them.
> > > > > >
> > > > > > Also, each member of the team is considered a specialist in their
> > > > > > day-to-day work by the other team members. I have suggested the
> > team
> > > > try
> > > > > > pair-programming so that they each can pick up any task at any
> > time.
> > > > Again,
> > > > > > the team has not seen the value in this.
> > > > > >
> > > > > > Any suggestions on how I can help this highly specialized, and
> > > > constantly
> > > > > > distracted team?
> > > > > >
> > > > > > Thanks,
> > > > > > Mike
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

#48230

From: "Michael" <mikeabugow@...>
Date: Wed Sep 1, 2010 11:16 pm
Subject: Re: What to do when the team is not firing on all cylinders?

mikeabugow

Malcolm,

I upper-management sees the accomplishments the team have done.  They are
measuring this teams progress based on how well the teams (read other sprint
teams that are reliant upon) they also support are able to complete their own
sprints.  The company sees growth as fine, and not a problem.

Mike

--- In scrumdevelopment@yahoogroups.com, Malcolm Anderson
<malcolm.b.anderson@...> wrote:
>
> Michael
>
> 4 questions.
>
> What is "upper-managements" feelings about what you have already
> accomplished?
>
> What measurements of progress have you been able to give "upper-management"?
>
> What is / are "upper-management's" biggest concerns about the company's
> growth?
>
> How many people is "upper-management" comprised of?
>
> Malcolm
>
>
>
>
> On Wed, Sep 1, 2010 at 10:15 AM, Michael <mikeabugow@...> wrote:
>
> >
> >
> > Hi All,
> >
> > My goal is to help this team respond to their sprint backlog effectively,
> > and to help the P.O. say no to the out of sprint work that continually comes
> > up. Myself and one of the other ScrumMasters in my division agree that a
> > Kanban approach would be more appropriate for this type of development team.
> > Unfortunately, upper-management does not feel that switching to Kanban is a
> > worthwhile exercise.
> >
> > The team sees itself as getting more work done than ever before, and feels
> > they are doing a good job when they get the little amount of actual planned
> > work completed along with all of the planned for out of sprint work.
> >
> > Mike
> >
> >
> > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
> > Bachan Anand <bachans@> wrote:
> > >
> > > Michael ,
> > > Great post !!
> > >
> > > On Tue, Aug 31, 2010 at 8:14 AM, Michael <mikeabugow@> wrote:
> > >
> > > >
> > > >
> > > > Alan,
> > > >
> > > > Agreed, this is a case of education and fear. I have discussed this
> > with
> > > > the team in multiple retrospectives, and their group opinion is they
> > are
> > > > doing fine because they are getting so much work accomplished. Even
> > though,
> > > > most of the work is out of sprint,
> > > >
> > >
> > > Is your objective to stop out of Sprint work or to have a more effective
> > way
> > > of handling the new stories that comes up. How long are your sprints,
> > > intention of the question is to explore whether the Sprint duration has
> > > anything to do with out of Sprint .
> > >
> > > > which they set aside story points for every sprint. (My only victory
> > thus
> > > > far as their SM.)
> > > >
> > > > We started tracking out of sprint work so not only the team, but also
> > so
> > > > management could see how little actual planned for work is being
> > > > accomplished during the sprint. This tracking, unfortunately become the
> > > > accepted norm.
> > > >
> > > > Mike
> > > >
> > > >
> > > > --- In
scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>
> > <scrumdevelopment%40yahoogroups.com>,
> >
> > > > Alan Dayley <alandd@> wrote:
> > > > >
> > > > > This appears to be a case of the team not knowing what they are
> > missing.
> > > > In
> > > > > other words, they don't see a problem to solve so they refuse the
> > > > solution
> > > > > as not needed. Education is the answer and may take a while.
> > > > >
> > > > > Another likely issue is that they fear application of more control
> > around
> > > > > the interruptive work. If they choose to track the flow of the
> > > > > interruptions that means they sometimes will have to stop accepting
> > > > another
> > > > > task. Maybe they fear having to work with and regulate incoming
> > requests.
> > > > > Again, education of the team and the people making requests is
> > necessary.
> > > > >
> > > > > I find two major sources of objections to pair-programming.
> > > > >
> > > > > First, many individuals like to be specialists and see value in being
> > The
> > > > > One with the answers for specific needs. They see specialization as
> > job
> > > > > security. This fear has some basis in fact and has to be addressed by
> > > > > providing confidence that their individual value is secure as
> > possible,
> > > > even
> > > > > if someone else also has similar skills and knowledge.
> > > > >
> > > > > Second pair-programming is seen as inefficient. Two people working on
> > one
> > > > > task is percieved as wasteful since a second task by the second
> > person is
> > > > > not being worked on. Education about pair programming benefits in
> > code
> > > > > quality, cross-training, culture and team building is needed there.
> > > > >
> > > > > A quick approach to get past the education need is to couch the new
> > idea
> > > > as
> > > > > an experiment. For example, if they still object to pair-programming,
> > > > > suggest that the team try it for just one sprint. One experiment is
> > worth
> > > > a
> > > > > thousand or more white papers and a million presentation slides!
> > > > >
> > > > > Alan
> > > > >
> > > > > On Mon, Aug 30, 2010 at 10:53 AM, Michael <mikeabugow@> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Hi All. I have relatively small Scrum team that is responsible for
> > > > database
> > > > > > design, and maintenance. Unfortunately, this team is treated as an
> > > > > > operations type team, but is still expected to run as an Agile
> > Scrum
> > > > team.
> > > > > > Greater than 60% of their work is out of sprint tasks. I have
> > suggested
> > > > that
> > > > > > they try incorporating Kanban as part of their development cycles.
> > > > > > Unfortunately, neither the team, nor their P.O. sees this as a
> > viable
> > > > > > alternative to having constant out of sprint work given to them.
> > > > > >
> > > > > > Also, each member of the team is considered a specialist in their
> > > > > > day-to-day work by the other team members. I have suggested the
> > team
> > > > try
> > > > > > pair-programming so that they each can pick up any task at any
> > time.
> > > > Again,
> > > > > > the team has not seen the value in this.
> > > > > >
> > > > > > Any suggestions on how I can help this highly specialized, and
> > > > constantly
> > > > > > distracted team?
> > > > > >
> > > > > > Thanks,
> > > > > > Mike
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

#48231

From: "Michael" <mikeabugow@...>
Date: Wed Sep 1, 2010 11:20 pm
Subject: Re: What to do when the team is not firing on all cylinders?

mikeabugow

Maurice,

I'm the ScrumMaster, and unfortunately, all the out of sprint work comes from
upper management, who find this acceptable to interrupt this team.

#48232

From: Ron Jeffries <ronjeffries@...>
Date: Wed Sep 1, 2010 11:39 pm
Subject: Re: Convert XPGame to Scrum

ronaldejeffries

Hello, Asad.  On Wednesday, September 1, 2010, at 6:58:21 PM, you
wrote:

> We know that the XP Game is good thing for teaching hard
> understating things like Estimate and planning in XP method to
> developers and customers. I'd like this technique.

When you say "XP Game", what do you mean?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
This is how I develop software.
Take the parts that make sense to you.
Ignore the rest.

Reply | Messages in this Topic (3)

#48233

From: George Dinwiddie <lists@...>
Date: Thu Sep 2, 2010 12:08 am
Subject: Re: Template of task breakdown for a user story

gdinwiddie

Ilja, et al,

On 9/2/10 12:43 AM, Ilja Preu� wrote:
>
>
> In my experience, it just happens naturally that a team comes up with a
> set of standard tasks that they think of for every story, and that is a
> good thing.

In my experience, when teams come up with a set of standard tasks,
they're reinforcing the phases and silos of their prior software
development methods.  They'll have tasks like
	 gui
	 database
	 middle tier
	 testing
Having this set of standard tasks (whether provided to them, or chosen
by themselves), inhibits their thinking (as Dan mentions).  It's an
impediment to learning how to divide the work into functional slices
instead of architectural and phase tasks.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------