Discussion:
What to do when the team is not firing on all cylinders?
Michael
2010-08-30 17:53:14 UTC
Permalink
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



------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Malcolm Anderson
2010-08-30 18:54:35 UTC
Permalink
Mike

What problem is the team having that you are trying to fix?

Malcolm
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
Michael
2010-08-31 15:09:33 UTC
Permalink
Malcolm,

The team is constantly working on out of sprint tasks. I'd guess that the percent of out of sprint work is in the high 60 percentile range. The biggest problem is, this team is functioning more efficiently in this psuedo-agile experience than ever before. But, again they are by no means working in the truest sense of Scrum.

Mike
Post by Malcolm Anderson
Mike
What problem is the team having that you are trying to fix?
Malcolm
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
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Malcolm Anderson
2010-09-01 00:37:05 UTC
Permalink
Mike

I'm assuming that you mean that the team is functioning more "effectively"
than ever before rather than more "efficiently" (two similar sounding words,
that lead to vastly different worlds when steered by)

While you may not have implemented scrum, it sounds like you have the
makings for a successful agile case study.

Can you measure how much more productive the team is and / or how much more
productive the team feels?
If you have raised moral, and raised productivity then you have already done
a great job.

Changing a culture is rarely done overnight. Sometimes you will feel like
Sisyphus, forever rolling a rock uphill. But unlike Sisyphus you can start
to see successful changes happening around you. It's slow, but it
happens.

Lastly, human beings seem to be designed to (eventually) take where we are,
for granted. This means that, sooner or later, you will start hearing
someone complaining about not being able to get enough done fast enough. At
that point, you can experiment with more change and possibly ratchet it up
another notch.

Malcolm
Post by Michael
Malcolm,
The team is constantly working on out of sprint tasks. I'd guess that the
percent of out of sprint work is in the high 60 percentile range. The
biggest problem is, this team is functioning more efficiently in this
psuedo-agile experience than ever before. But, again they are by no means
working in the truest sense of Scrum.
Mike
Post by Malcolm Anderson
Mike
What problem is the team having that you are trying to fix?
Malcolm
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Malcolm Anderson
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile Scrum
team.
Post by Malcolm Anderson
Greater than 60% of their work is out of sprint tasks. I have suggested
that
Post by Malcolm Anderson
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
Post by Malcolm Anderson
pair-programming so that they each can pick up any task at any time.
Again,
Post by Malcolm Anderson
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Malcolm Anderson
distracted team?
Thanks,
Mike
Alan Dayley
2010-08-30 19:14:45 UTC
Permalink
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
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
Jeff Anderson
2010-08-31 13:59:09 UTC
Permalink
It sounds like you are coming up with great solutions on your own,
your problem is buy in.

Tie your solution to specific issues you are trying to address, and
spend a little time articulating what the outcome could look like if
your solutions (kanban or pair programming) are adopted.

Try providing some evidence. Lots of great number on pairing and
kanban, of course caveat that all numbers lie to some extent :)
Post by Alan Dayley
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
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
--
Sent from my mobile device

Jeff Anderson

http://agileconsulting.blogspot.com/


------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Michael
2010-08-31 15:16:03 UTC
Permalink
Jeff,

Thank you for the reinforcement and advice. Now to get buy-in from the P.O., who is also the manager for this team.

Mike
Post by Jeff Anderson
It sounds like you are coming up with great solutions on your own,
your problem is buy in.
Tie your solution to specific issues you are trying to address, and
spend a little time articulating what the outcome could look like if
your solutions (kanban or pair programming) are adopted.
Try providing some evidence. Lots of great number on pairing and
kanban, of course caveat that all numbers lie to some extent :)
Post by Alan Dayley
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
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
--
Sent from my mobile device
Jeff Anderson
http://agileconsulting.blogspot.com/
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Michael
2010-08-31 15:14:37 UTC
Permalink
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, 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
Post by Alan Dayley
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
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
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Bachan Anand
2010-08-31 16:40:55 UTC
Permalink
Michael ,
Great post !!
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
Post by Alan Dayley
This appears to be a case of the team not knowing what they are missing.
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile Scrum
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have suggested
that
Post by Alan Dayley
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
Post by Alan Dayley
pair-programming so that they each can pick up any task at any time.
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
Roy Morien
2010-09-01 04:14:00 UTC
Permalink
Going back to basics; if a substantial majority of the team's work is 'out of sprint' work, then is Scrum an appropriate development framework to be following?



Regards,

Roy Morien



To: ***@yahoogroups.com
From: ***@gmail.com
Date: Tue, 31 Aug 2010 09:40:55 -0700
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?






Michael ,
Great post !!


On Tue, Aug 31, 2010 at 8:14 AM, Michael <***@yahoo.com> 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
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
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
Alan Dayley
2010-09-01 04:17:41 UTC
Permalink
Good question. Scrum might be appropriate, depending on the reasons why
most of the work is "out of sprint." And if that "out-of-sprint-ness" is
something that hurts business purposes.

Alan
Post by Roy Morien
Going back to basics; if a substantial majority of the team's work is 'out
of sprint' work, then is Scrum an appropriate development framework to be
following?
Regards,
Roy Morien
------------------------------
Date: Tue, 31 Aug 2010 09:40:55 -0700
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing
on all cylinders?
Michael ,
Great post !!
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
Post by Alan Dayley
This appears to be a case of the team not knowing what they are missing.
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile Scrum
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have suggested
that
Post by Alan Dayley
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
Post by Alan Dayley
pair-programming so that they each can pick up any task at any time.
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
Roy Morien
2010-09-01 04:25:43 UTC
Permalink
An interesting point, though. Scrum, and sprint planning, surely must depend on having a reasonably stable, albeit short-term, Product Backlog, that can be held at arms length away from the developers during a sprint. It seems to me that if there is a reasonably continuous stream of new requests, the 'out of sprint' stuff', then a development approach that is much more pull driven is more appropriate; take it as it comes, join the queue, we're working steadily and will do your job when it arrives at the head of the queue (excepting the situation where it does have a higher priority than existing queue items).



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.



Maybe these are questions that can be addressed to the Kanban-ers :) ... they are serious questions.



Regards,

Roy Morien



To: ***@yahoogroups.com
From: ***@dayleyagile.com
Date: Tue, 31 Aug 2010 21:17:41 -0700
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?






Good question. Scrum might be appropriate, depending on the reasons why most of the work is "out of sprint." And if that "out-of-sprint-ness" is something that hurts business purposes.


Alan


On Tue, Aug 31, 2010 at 9:14 PM, Roy Morien <***@hotmail.com> wrote:






Going back to basics; if a substantial majority of the team's work is 'out of sprint' work, then is Scrum an appropriate development framework to be following?

Regards,
Roy Morien




To: ***@yahoogroups.com
From: ***@gmail.com
Date: Tue, 31 Aug 2010 09:40:55 -0700
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?







Michael ,
Great post !!


On Tue, Aug 31, 2010 at 8:14 AM, Michael <***@yahoo.com> 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
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
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
Alan Dayley
2010-09-01 05:03:19 UTC
Permalink
The other side is also in question. Why is "the company" making so many
unplanned requests? Bugs? Management neglecting strategic plans?
Hyper-command and control? Too many bosses? All needs are "top" priority?

Some teams do better with kanban and need flow of incoming work. Even
kanban enforces some control of the flow.

But, some need to use Scrum (iteration rhythm) to help the company stop
thrashing.

Alan
Post by Roy Morien
An interesting point, though. Scrum, and sprint planning, surely must
depend on having a reasonably stable, albeit short-term, Product Backlog,
that can be held at arms length away from the developers during a sprint. It
seems to me that if there is a reasonably continuous stream of new requests,
the 'out of sprint' stuff', then a development approach that is much more
pull driven is more appropriate; take it as it comes, join the queue, we're
working steadily and will do your job when it arrives at the head of the
queue (excepting the situation where it does have a higher priority than
existing queue items).
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.
Maybe these are questions that can be addressed to the Kanban-ers :) ...
they are serious questions.
Regards,
Roy Morien
------------------------------
Date: Tue, 31 Aug 2010 21:17:41 -0700
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing
on all cylinders?
Good question. Scrum might be appropriate, depending on the reasons why
most of the work is "out of sprint." And if that "out-of-sprint-ness" is
something that hurts business purposes.
Alan
Going back to basics; if a substantial majority of the team's work is 'out
of sprint' work, then is Scrum an appropriate development framework to be
following?
Regards,
Roy Morien
------------------------------
Date: Tue, 31 Aug 2010 09:40:55 -0700
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing
on all cylinders?
Michael ,
Great post !!
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
Post by Alan Dayley
This appears to be a case of the team not knowing what they are missing.
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile Scrum
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have suggested
that
Post by Alan Dayley
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
Post by Alan Dayley
pair-programming so that they each can pick up any task at any time.
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
Roy Morien
2010-09-01 06:40:41 UTC
Permalink
Indeed, I agree with you entirely. But, on the other hand (as the economists would always say), if the many unplanned requests are naturally and normally arising from daily usage, that does not necessarilly imply management neglect, command and control, too many bosses etc.



But what it may call forth is the question of Why are there so many unplanned requests? (yes, your same question, but viewed from a different angle). Is it because the software in use has many bugs, or does not really meet user requirements, and is being enhanced 'on the fly' to overcome this gross deficiency. It is perfectly reasonable for change requests to arise from the learning experience of using the software, but if that constitutes 60% of development work, then that can indicate a problem right from the start of the development process; ie: buggy software is being delivered, and software that has not been developed in close accord with user requirements initially is being delivered.



At this point, maybe a big swing back to Scrum style development is indicated to address the problems at their source.



But overall there is the notion of 'horses for courses' ... Scrum cannot be seen as appropriate for ALL situations ... although I have always held that the iterative style of development is pretty well appropriate for all situations, and the statement that 'Oh, there are some projects that can't be done that way, and need a more structured approach' is just being mealy-mouthed.



Regards,

Roy Morien



To: ***@yahoogroups.com
From: ***@dayleyagile.com
Date: Tue, 31 Aug 2010 22:03:19 -0700
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?






The other side is also in question. Why is "the company" making so many unplanned requests? Bugs? Management neglecting strategic plans? Hyper-command and control? Too many bosses? All needs are "top" priority?


Some teams do better with kanban and need flow of incoming work. Even kanban enforces some control of the flow.


But, some need to use Scrum (iteration rhythm) to help the company stop thrashing.


Alan


On Tue, Aug 31, 2010 at 9:25 PM, Roy Morien <***@hotmail.com> wrote:






An interesting point, though. Scrum, and sprint planning, surely must depend on having a reasonably stable, albeit short-term, Product Backlog, that can be held at arms length away from the developers during a sprint. It seems to me that if there is a reasonably continuous stream of new requests, the 'out of sprint' stuff', then a development approach that is much more pull driven is more appropriate; take it as it comes, join the queue, we're working steadily and will do your job when it arrives at the head of the queue (excepting the situation where it does have a higher priority than existing queue items).

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.

Maybe these are questions that can be addressed to the Kanban-ers :) ... they are serious questions.



Regards,
Roy Morien



To: ***@yahoogroups.com
From: ***@dayleyagile.com
Date: Tue, 31 Aug 2010 21:17:41 -0700



Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?




Good question. Scrum might be appropriate, depending on the reasons why most of the work is "out of sprint." And if that "out-of-sprint-ness" is something that hurts business purposes.


Alan


On Tue, Aug 31, 2010 at 9:14 PM, Roy Morien <***@hotmail.com> wrote:






Going back to basics; if a substantial majority of the team's work is 'out of sprint' work, then is Scrum an appropriate development framework to be following?

Regards,
Roy Morien





To: ***@yahoogroups.com
From: ***@gmail.com
Date: Tue, 31 Aug 2010 09:40:55 -0700
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?







Michael ,
Great post !!


On Tue, Aug 31, 2010 at 8:14 AM, Michael <***@yahoo.com> 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
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
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
Ron Jeffries
2010-09-01 10:38:48 UTC
Permalink
Hello, Roy. On Wednesday, September 1, 2010, at 12:25:43 AM, you
Post by Roy Morien
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



------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Roy Morien
2010-09-02 07:23:39 UTC
Permalink
My statement did not really imply that there /was/ such a measure for 'in-sprint' work, but, having obviously begged the question, I would say that velocity is at least a measure of work achieved, and that is a measure of 'per sprint' work achieved, which can be seen to improve, ceterus paribus.



ANyway, I did follow my statement with suggesting that it was a question that the Kanban folks might be able to answer, and enlighten me on.



Regards,

Roy Morien
Date: Wed, 1 Sep 2010 06:38:48 -0400
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?
Hello, Roy. On Wednesday, September 1, 2010, at 12:25:43 AM, you
Post by Roy Morien
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
------------------------------------
Ron Jeffries
2010-09-02 10:05:04 UTC
Permalink
Hello, Roy. On Thursday, September 2, 2010, at 3:23:39 AM, you
Post by Roy Morien
My statement did not really imply that there /was/ such a measure
for 'in-sprint' work, but, having obviously begged the question, I
would say that velocity is at least a measure of work achieved,
and that is a measure of 'per sprint' work achieved, which can be
seen to improve, ceterus paribus.
Can it? Is that velocity = points / time? features / time? Is
increasing good? Can you think of a way to game it? I can ...
Post by Roy Morien
ANyway, I did follow my statement with suggesting that it was a
question that the Kanban folks might be able to answer, and enlighten me on.
I wish they could, but I bet they can't.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
If it is more than you need, it is waste. -- Andy Seidl



------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Roy Morien
2010-09-03 03:54:33 UTC
Permalink
Ron, I did say ceterus paribus, (which might show my academic leanings). But, 'all other things being equal', velocity can be a measure of work achieved. That is its very purpose, therefore being able to be used for estimating, and for selecting user stories into the Sprint backlog.



Yes, of course it can be gamed. I have posted some rather obvious sarcastic / facetious / ironic postings here that are clearly indicating how to game it, so I am not unaware of this possibility. But, if we can assume for a moment that teams and SM's and PO's use the measure in good faith, and without gaming it for other 'management ' purposes, then Why couldn't it be a useful measure of work achieved? Relatively, of course, comparing one sprint with another, it can show improvement or drop-off in work achieved.



Can't it? Or am I missing the game here completely? (I must admit, in my days as a baseball umpire, I was sometimes told by players that I was missing a good game .. And I was actually a pretty good plate umpire, even if I do say so myself )



Regards,

Roy Morien



To: ***@yahoogroups.com
From: ***@acm.org
Date: Thu, 2 Sep 2010 06:05:04 -0400
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?






Hello, Roy. On Thursday, September 2, 2010, at 3:23:39 AM, you
Post by Roy Morien
My statement did not really imply that there /was/ such a measure
for 'in-sprint' work, but, having obviously begged the question, I
would say that velocity is at least a measure of work achieved,
and that is a measure of 'per sprint' work achieved, which can be
seen to improve, ceterus paribus.
Can it? Is that velocity = points / time? features / time? Is
increasing good? Can you think of a way to game it? I can ...
Post by Roy Morien
ANyway, I did follow my statement with suggesting that it was a
question that the Kanban folks might be able to answer, and enlighten me on.
I wish they could, but I bet they can't.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
If it is more than you need, it is waste. -- Andy Seidl
Roy Morien
2010-09-02 08:13:51 UTC
Permalink
My statement did not really imply that there /was/ such a measure for 'in-sprint' work, but, having obviously begged the question, I would say that velocity is at least a measure of work achieved, and that is a measure of 'per sprint' work achieved, which can be seen to improve, ceterus paribus.

ANyway, I did follow my statement with suggesting that it was a question that the Kanban folks might be able to answer, and enlighten me on.

Regards,
Roy Morien
Date: Wed, 1 Sep 2010 06:38:48 -0400
Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?
Hello, Roy. On Wednesday, September 1, 2010, at 12:25:43 AM, you
Post by Roy Morien
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
------------------------------------
Michael
2010-09-01 14:15:42 UTC
Permalink
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
Post by Bachan Anand
Michael ,
Great post !!
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
Post by Alan Dayley
This appears to be a case of the team not knowing what they are missing.
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile Scrum
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have suggested
that
Post by Alan Dayley
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
Post by Alan Dayley
pair-programming so that they each can pick up any task at any time.
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kevin Johnston
2010-09-01 15:45:52 UTC
Permalink
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
Post by Michael
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
Post by Bachan Anand
Michael ,
Great post !!
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
Post by Alan Dayley
This appears to be a case of the team not knowing what they are missing.
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile Scrum
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have suggested
that
Post by Alan Dayley
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
Post by Alan Dayley
pair-programming so that they each can pick up any task at any time.
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
Michael
2010-09-01 23:10:58 UTC
Permalink
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
Post by Kevin Johnston
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
Post by Michael
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
Post by Bachan Anand
Michael ,
Great post !!
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
Post by Alan Dayley
This appears to be a case of the team not knowing what they are missing.
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile Scrum
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have suggested
that
Post by Alan Dayley
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
Post by Alan Dayley
pair-programming so that they each can pick up any task at any time.
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Alan Dayley
2010-09-01 15:52:20 UTC
Permalink
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
Post by Michael
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
Post by Bachan Anand
Michael ,
Great post !!
Alan,
Agreed, this is a case of education and fear. I have discussed this
with
Post by Bachan Anand
the team in multiple retrospectives, and their group opinion is they
are
Post by Bachan Anand
doing fine because they are getting so much work accomplished. Even
though,
Post by Bachan Anand
most of the work is out of sprint,
Is your objective to stop out of Sprint work or to have a more effective
way
Post by Bachan Anand
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
Post by Bachan Anand
far as their SM.)
We started tracking out of sprint work so not only the team, but also
so
Post by Bachan Anand
management could see how little actual planned for work is being
accomplished during the sprint. This tracking, unfortunately become the
accepted norm.
Mike
<scrumdevelopment%40yahoogroups.com>,
Post by Bachan Anand
Post by Alan Dayley
This appears to be a case of the team not knowing what they are
missing.
Post by Bachan Anand
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
as not needed. Education is the answer and may take a while.
Another likely issue is that they fear application of more control
around
Post by Bachan Anand
Post by Alan Dayley
the interruptive work. If they choose to track the flow of the
interruptions that means they sometimes will have to stop accepting
another
Post by Alan Dayley
task. Maybe they fear having to work with and regulate incoming
requests.
Post by Bachan Anand
Post by Alan Dayley
Again, education of the team and the people making requests is
necessary.
Post by Bachan Anand
Post by Alan Dayley
I find two major sources of objections to pair-programming.
First, many individuals like to be specialists and see value in being
The
Post by Bachan Anand
Post by Alan Dayley
One with the answers for specific needs. They see specialization as
job
Post by Bachan Anand
Post by Alan Dayley
security. This fear has some basis in fact and has to be addressed by
providing confidence that their individual value is secure as
possible,
Post by Bachan Anand
even
Post by Alan Dayley
if someone else also has similar skills and knowledge.
Second pair-programming is seen as inefficient. Two people working on
one
Post by Bachan Anand
Post by Alan Dayley
task is percieved as wasteful since a second task by the second
person is
Post by Bachan Anand
Post by Alan Dayley
not being worked on. Education about pair programming benefits in
code
Post by Bachan Anand
Post by Alan Dayley
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
Post by Bachan Anand
as
Post by Alan Dayley
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
Post by Bachan Anand
a
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile
Scrum
Post by Bachan Anand
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have
suggested
Post by Bachan Anand
that
Post by Alan Dayley
they try incorporating Kanban as part of their development cycles.
Unfortunately, neither the team, nor their P.O. sees this as a
viable
Post by Bachan Anand
Post by Alan Dayley
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
Post by Bachan Anand
try
Post by Alan Dayley
pair-programming so that they each can pick up any task at any
time.
Post by Bachan Anand
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
Michael
2010-09-01 23:13:58 UTC
Permalink
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
Post by Alan Dayley
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
Post by Michael
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
Post by Bachan Anand
Michael ,
Great post !!
Alan,
Agreed, this is a case of education and fear. I have discussed this
with
Post by Bachan Anand
the team in multiple retrospectives, and their group opinion is they
are
Post by Bachan Anand
doing fine because they are getting so much work accomplished. Even
though,
Post by Bachan Anand
most of the work is out of sprint,
Is your objective to stop out of Sprint work or to have a more effective
way
Post by Bachan Anand
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
Post by Bachan Anand
far as their SM.)
We started tracking out of sprint work so not only the team, but also
so
Post by Bachan Anand
management could see how little actual planned for work is being
accomplished during the sprint. This tracking, unfortunately become the
accepted norm.
Mike
<scrumdevelopment%40yahoogroups.com>,
Post by Bachan Anand
Post by Alan Dayley
This appears to be a case of the team not knowing what they are
missing.
Post by Bachan Anand
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
as not needed. Education is the answer and may take a while.
Another likely issue is that they fear application of more control
around
Post by Bachan Anand
Post by Alan Dayley
the interruptive work. If they choose to track the flow of the
interruptions that means they sometimes will have to stop accepting
another
Post by Alan Dayley
task. Maybe they fear having to work with and regulate incoming
requests.
Post by Bachan Anand
Post by Alan Dayley
Again, education of the team and the people making requests is
necessary.
Post by Bachan Anand
Post by Alan Dayley
I find two major sources of objections to pair-programming.
First, many individuals like to be specialists and see value in being
The
Post by Bachan Anand
Post by Alan Dayley
One with the answers for specific needs. They see specialization as
job
Post by Bachan Anand
Post by Alan Dayley
security. This fear has some basis in fact and has to be addressed by
providing confidence that their individual value is secure as
possible,
Post by Bachan Anand
even
Post by Alan Dayley
if someone else also has similar skills and knowledge.
Second pair-programming is seen as inefficient. Two people working on
one
Post by Bachan Anand
Post by Alan Dayley
task is percieved as wasteful since a second task by the second
person is
Post by Bachan Anand
Post by Alan Dayley
not being worked on. Education about pair programming benefits in
code
Post by Bachan Anand
Post by Alan Dayley
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
Post by Bachan Anand
as
Post by Alan Dayley
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
Post by Bachan Anand
a
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile
Scrum
Post by Bachan Anand
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have
suggested
Post by Bachan Anand
that
Post by Alan Dayley
they try incorporating Kanban as part of their development cycles.
Unfortunately, neither the team, nor their P.O. sees this as a
viable
Post by Bachan Anand
Post by Alan Dayley
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
Post by Bachan Anand
try
Post by Alan Dayley
pair-programming so that they each can pick up any task at any
time.
Post by Bachan Anand
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kevin Johnston
2010-09-01 16:01:32 UTC
Permalink
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
Post by Michael
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
Post by Bachan Anand
Michael ,
Great post !!
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
Post by Alan Dayley
This appears to be a case of the team not knowing what they are missing.
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
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
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile Scrum
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have suggested
that
Post by Alan Dayley
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
Post by Alan Dayley
pair-programming so that they each can pick up any task at any time.
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
Malcolm Anderson
2010-09-01 16:31:46 UTC
Permalink
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
Post by Michael
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
Post by Bachan Anand
Michael ,
Great post !!
Alan,
Agreed, this is a case of education and fear. I have discussed this
with
Post by Bachan Anand
the team in multiple retrospectives, and their group opinion is they
are
Post by Bachan Anand
doing fine because they are getting so much work accomplished. Even
though,
Post by Bachan Anand
most of the work is out of sprint,
Is your objective to stop out of Sprint work or to have a more effective
way
Post by Bachan Anand
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
Post by Bachan Anand
far as their SM.)
We started tracking out of sprint work so not only the team, but also
so
Post by Bachan Anand
management could see how little actual planned for work is being
accomplished during the sprint. This tracking, unfortunately become the
accepted norm.
Mike
<scrumdevelopment%40yahoogroups.com>,
Post by Bachan Anand
Post by Alan Dayley
This appears to be a case of the team not knowing what they are
missing.
Post by Bachan Anand
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
as not needed. Education is the answer and may take a while.
Another likely issue is that they fear application of more control
around
Post by Bachan Anand
Post by Alan Dayley
the interruptive work. If they choose to track the flow of the
interruptions that means they sometimes will have to stop accepting
another
Post by Alan Dayley
task. Maybe they fear having to work with and regulate incoming
requests.
Post by Bachan Anand
Post by Alan Dayley
Again, education of the team and the people making requests is
necessary.
Post by Bachan Anand
Post by Alan Dayley
I find two major sources of objections to pair-programming.
First, many individuals like to be specialists and see value in being
The
Post by Bachan Anand
Post by Alan Dayley
One with the answers for specific needs. They see specialization as
job
Post by Bachan Anand
Post by Alan Dayley
security. This fear has some basis in fact and has to be addressed by
providing confidence that their individual value is secure as
possible,
Post by Bachan Anand
even
Post by Alan Dayley
if someone else also has similar skills and knowledge.
Second pair-programming is seen as inefficient. Two people working on
one
Post by Bachan Anand
Post by Alan Dayley
task is percieved as wasteful since a second task by the second
person is
Post by Bachan Anand
Post by Alan Dayley
not being worked on. Education about pair programming benefits in
code
Post by Bachan Anand
Post by Alan Dayley
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
Post by Bachan Anand
as
Post by Alan Dayley
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
Post by Bachan Anand
a
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile
Scrum
Post by Bachan Anand
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have
suggested
Post by Bachan Anand
that
Post by Alan Dayley
they try incorporating Kanban as part of their development cycles.
Unfortunately, neither the team, nor their P.O. sees this as a
viable
Post by Bachan Anand
Post by Alan Dayley
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
Post by Bachan Anand
try
Post by Alan Dayley
pair-programming so that they each can pick up any task at any
time.
Post by Bachan Anand
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
Michael
2010-09-01 23:16:42 UTC
Permalink
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
Post by Bachan Anand
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
Post by Michael
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
Post by Bachan Anand
Michael ,
Great post !!
Alan,
Agreed, this is a case of education and fear. I have discussed this
with
Post by Bachan Anand
the team in multiple retrospectives, and their group opinion is they
are
Post by Bachan Anand
doing fine because they are getting so much work accomplished. Even
though,
Post by Bachan Anand
most of the work is out of sprint,
Is your objective to stop out of Sprint work or to have a more effective
way
Post by Bachan Anand
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
Post by Bachan Anand
far as their SM.)
We started tracking out of sprint work so not only the team, but also
so
Post by Bachan Anand
management could see how little actual planned for work is being
accomplished during the sprint. This tracking, unfortunately become the
accepted norm.
Mike
<scrumdevelopment%40yahoogroups.com>,
Post by Bachan Anand
Post by Alan Dayley
This appears to be a case of the team not knowing what they are
missing.
Post by Bachan Anand
In
Post by Alan Dayley
other words, they don't see a problem to solve so they refuse the
solution
Post by Alan Dayley
as not needed. Education is the answer and may take a while.
Another likely issue is that they fear application of more control
around
Post by Bachan Anand
Post by Alan Dayley
the interruptive work. If they choose to track the flow of the
interruptions that means they sometimes will have to stop accepting
another
Post by Alan Dayley
task. Maybe they fear having to work with and regulate incoming
requests.
Post by Bachan Anand
Post by Alan Dayley
Again, education of the team and the people making requests is
necessary.
Post by Bachan Anand
Post by Alan Dayley
I find two major sources of objections to pair-programming.
First, many individuals like to be specialists and see value in being
The
Post by Bachan Anand
Post by Alan Dayley
One with the answers for specific needs. They see specialization as
job
Post by Bachan Anand
Post by Alan Dayley
security. This fear has some basis in fact and has to be addressed by
providing confidence that their individual value is secure as
possible,
Post by Bachan Anand
even
Post by Alan Dayley
if someone else also has similar skills and knowledge.
Second pair-programming is seen as inefficient. Two people working on
one
Post by Bachan Anand
Post by Alan Dayley
task is percieved as wasteful since a second task by the second
person is
Post by Bachan Anand
Post by Alan Dayley
not being worked on. Education about pair programming benefits in
code
Post by Bachan Anand
Post by Alan Dayley
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
Post by Bachan Anand
as
Post by Alan Dayley
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
Post by Bachan Anand
a
Post by Alan Dayley
thousand or more white papers and a million presentation slides!
Alan
Hi All. I have relatively small Scrum team that is responsible for
database
Post by Alan Dayley
design, and maintenance. Unfortunately, this team is treated as an
operations type team, but is still expected to run as an Agile
Scrum
Post by Bachan Anand
team.
Post by Alan Dayley
Greater than 60% of their work is out of sprint tasks. I have
suggested
Post by Bachan Anand
that
Post by Alan Dayley
they try incorporating Kanban as part of their development cycles.
Unfortunately, neither the team, nor their P.O. sees this as a
viable
Post by Bachan Anand
Post by Alan Dayley
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
Post by Bachan Anand
try
Post by Alan Dayley
pair-programming so that they each can pick up any task at any
time.
Post by Bachan Anand
Again,
Post by Alan Dayley
the team has not seen the value in this.
Any suggestions on how I can help this highly specialized, and
constantly
Post by Alan Dayley
distracted team?
Thanks,
Mike
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kevin Johnston
2010-09-01 16:13:30 UTC
Permalink
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
David A Barrett
2010-09-01 16:39:41 UTC
Permalink
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.
George Dinwiddie
2010-09-01 23:57:59 UTC
Permalink
Post by David A Barrett
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.
...
Post by David A Barrett
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.
Yes, I think that's a fine solution. And if people /can't/ wait, or say
they can't, then consider shortening your sprints. No work is
instantaneous, even if started right away, so the argument "I need it
right now" holds no water.

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



------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
JackM
2010-09-03 19:15:45 UTC
Permalink
There was very little in the way of actual advice on how to solve this problem. I think the answer to your question is ..

1. identify the source of interruptions and track them on the burndown so everyone can see how the team is being affected.

2. as was mentioned above. bring the interrupts into the sprint, track in it's own backlog for example and budget for the interrupts in the sprint.

3. batch the delivery of solutions for interrupts. When i joined my current company it was natural for anyone in the company to go directly to the developer and ask them to fix something. They were delivering patch after patch after patch. Now we set a patch delivery cycle, everything get's batched and everything is managed within the sprint. It's amazing how when you share a patch schedule with your customers how accepting they are. This helps you to manage your resources more effectively and become more predictable.

4. Find out why so many interrupts - usually this is a code quality issue. So figure out how to pay down this debt. We invested heavily in automation and unit tests. Eventually this will pay dividends.

5. Pair program, share the knowledge then you have more flexibility to pull some folks off to deal with maintenance while the rest of the team works on the core sprint stuff. This role can be rotated assuming you have collective code ownership.

Hope this helps
jack
www.agilebuddy.com
Post by George Dinwiddie
Post by David A Barrett
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.
...
Post by David A Barrett
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.
Yes, I think that's a fine solution. And if people /can't/ wait, or say
they can't, then consider shortening your sprints. No work is
instantaneous, even if started right away, so the argument "I need it
right now" holds no water.
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Matheus Henrique Gorino
2010-09-23 01:24:00 UTC
Permalink
Do your management knows that you are NOT doing Scrum already?
When you say "they do not want to leave Scrum", I'd say "they want to
implement Scrum". And if they want to implement Scrum, they need to really
buy the idea, to play the game, and stop disrupting the process.
What I feel from what I read is that they do not want do Scrum, they just
want do stick to the process you are running today, a Kanban with some Scrum
practices that you can call anything but Scrum.
In this case, my discussion with them would be something like: "We do not do
Scrum today. We can't do Scrum because we can't follow some of it's basic
rules. We can do Kanban and put some Scrum practices in place. And we need
to understand what practices would bring value to our custom process."
The division in Sprints, for example, seens to be waste. Doing
retrospectives every two weeks or so might bring value. Prioritizing tickets
might bring value. Planning the items that were in that 40% of the backlog
might bring value. Daily Meetings might be waste. And so on.
Post by JackM
There was very little in the way of actual advice on how to solve this
problem. I think the answer to your question is ..
1. identify the source of interruptions and track them on the burndown so
everyone can see how the team is being affected.
2. as was mentioned above. bring the interrupts into the sprint, track in
it's own backlog for example and budget for the interrupts in the sprint.
3. batch the delivery of solutions for interrupts. When i joined my current
company it was natural for anyone in the company to go directly to the
developer and ask them to fix something. They were delivering patch after
patch after patch. Now we set a patch delivery cycle, everything get's
batched and everything is managed within the sprint. It's amazing how when
you share a patch schedule with your customers how accepting they are. This
helps you to manage your resources more effectively and become more
predictable.
4. Find out why so many interrupts - usually this is a code quality issue.
So figure out how to pay down this debt. We invested heavily in automation
and unit tests. Eventually this will pay dividends.
5. Pair program, share the knowledge then you have more flexibility to pull
some folks off to deal with maintenance while the rest of the team works on
the core sprint stuff. This role can be rotated assuming you have collective
code ownership.
Hope this helps
jack
www.agilebuddy.com
Post by David A Barrett
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.
...
Post by David A Barrett
I think you'll be surprised at how little people get upset when you
tell
Post by David A Barrett
them that some big job will need to wait until it can be prioritized
into a Sprint.
Yes, I think that's a fine solution. And if people /can't/ wait, or say
they can't, then consider shortening your sprints. No work is
instantaneous, even if started right away, so the argument "I need it
right now" holds no water.
- George
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------
Maurice le Rutte
2010-09-01 17:28:52 UTC
Permalink
<head>

<style type="text/css">
<!--

/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}

div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}

div.attach-table div.attach-row {
clear: both;
}

div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}

p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}

div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}

div.attach-table div.attach-row div div span {
font-weight: normal;
}

div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">





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". <br>
<br>
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?<br>
<br>
Maurice.<br>
-- <br>
<pre class="moz-signature" cols="72"><a class="moz-txt-link-freetext" href="http://www.scrummaster.nl">http://www.scrummaster.nl</a> / <a class="moz-txt-link-freetext" href="http://twitter.com/scrumnl">http://twitter.com/scrumnl</a></pre>




<!-- |**|begin egp html banner|**| -->

<br>



<br>

<!-- |**|end egp html banner|**| -->


<div width="1" style="color: white; clear: both;"/>__._,_.___</div>

<!-- Start Recommendations -->
<!-- End Recommendations -->


<!-- |**|begin egp html banner|**| -->

<br><br>
<tt>
To Post a message, send it to:&nbsp;&nbsp; ***@eGroups.com<BR>
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com</tt>
<br><br>

<!-- |**|end egp html banner|**| -->



<!-- |**|begin egp html banner|**| -->

<img src="http://geo.yahoo.com/serv?s=97476590/grpId=1569064/grpspId=1707209021/msgId=48215/stime=1283362144" width="1" height="1"> <br>

<!-- |**|end egp html banner|**| -->


<!-- |**|begin egp html banner|**| -->

<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px solid #666; padding: 5px 0;" >
Your email settings: Individual Email|Traditional <br>
<a href="http://groups.yahoo.com/group/scrumdevelopment/join;_ylc=X3oDMTJmbzV0b2IyBF9TAzk3NDc2NTkwBGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA3MjA5MDIxBHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyODMzNjIxNDQ-">Change settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:scrumdevelopment-***@yahoogroups.com?subject=Email Delivery: Digest">Switch delivery to Daily Digest</a> | <a href = "mailto:scrumdevelopment-***@yahoogroups.com?subject=Change Delivery Format: Fully Featured">Switch to Fully Featured</a> <br>
<a href="http://groups.yahoo.com/group/scrumdevelopment;_ylc=X3oDMTJkOGhwNmtyBF9TAzk3NDc2NTkwBGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA3MjA5MDIxBHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjgzMzYyMTQ0">
Visit Your Group
</a> |
<a href="http://docs.yahoo.com/info/terms/">
Yahoo! Groups Terms of Use
</a> |
<a href="mailto:scrumdevelopment-***@yahoogroups.com?subject=Unsubscribe">
Unsubscribe
</a>
<br>
</div>
<br>

<!-- |**|end egp html banner|**| -->


<div style="color: white; clear: both;"/>__,_._,___</div>
</body>
</html>
barrettdab
2010-09-01 18:13:06 UTC
Permalink
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.




------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
scrumnl
2010-09-01 20:22:56 UTC
Permalink
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, appraisals, 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 benefits 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 benefits outweigh the costs, if not find something that better suits you.

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



------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Maurice le Rutte
2010-09-01 19:14:42 UTC
Permalink
<head>

<style type="text/css">
<!--

/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}

div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}

div.attach-table div.attach-row {
clear: both;
}

div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}

p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}

div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}

div.attach-table div.attach-row div div span {
font-weight: normal;
}

div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">





Op 1-9-2010 20:13, barrettdab schreef:
<blockquote cite="mid:i5m53i+***@eGroups.com" type="cite">
<span style="display: none;">&nbsp;</span>

<div id="ygrp-text">
<p>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.<br>
</p>
</div>
</div>
</div>
</blockquote>
True. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Now there will be some defects of the type 'urgent &amp; 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.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:i5m53i+***@eGroups.com" type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p>
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.<br>
</p>
</div>
<div style="color: rgb(255, 255, 255); height: 0pt;"><br>
</div>
</div>
</div>
</blockquote>
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. <br>
<br>
Maurice.<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.scrummaster.nl">http://www.scrummaster.nl</a> / <a class="moz-txt-link-freetext" href="http://twitter.com/scrumnl">http://twitter.com/scrumnl</a></pre>




<!-- |**|begin egp html banner|**| -->

<br>



<br>

<!-- |**|end egp html banner|**| -->


<div width="1" style="color: white; clear: both;"/>__._,_.___</div>

<!-- Start Recommendations -->
<!-- End Recommendations -->


<!-- |**|begin egp html banner|**| -->

<br><br>
<tt>
To Post a message, send it to:&nbsp;&nbsp; ***@eGroups.com<BR>
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com</tt>
<br><br>

<!-- |**|end egp html banner|**| -->



<!-- |**|begin egp html banner|**| -->

<img src="http://geo.yahoo.com/serv?s=97476590/grpId=1569064/grpspId=1707209021/msgId=48219/stime=1283372701" width="1" height="1"> <br>

<!-- |**|end egp html banner|**| -->


<!-- |**|begin egp html banner|**| -->

<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px solid #666; padding: 5px 0;" >
Your email settings: Individual Email|Traditional <br>
<a href="http://groups.yahoo.com/group/scrumdevelopment/join;_ylc=X3oDMTJmdm1jMG9kBF9TAzk3NDc2NTkwBGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA3MjA5MDIxBHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyODMzNzI3MDE-">Change settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:scrumdevelopment-***@yahoogroups.com?subject=Email Delivery: Digest">Switch delivery to Daily Digest</a> | <a href = "mailto:scrumdevelopment-***@yahoogroups.com?subject=Change Delivery Format: Fully Featured">Switch to Fully Featured</a> <br>
<a href="http://groups.yahoo.com/group/scrumdevelopment;_ylc=X3oDMTJkMjA0ZWIxBF9TAzk3NDc2NTkwBGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA3MjA5MDIxBHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjgzMzcyNzAx">
Visit Your Group
</a> |
<a href="http://docs.yahoo.com/info/terms/">
Yahoo! Groups Terms of Use
</a> |
<a href="mailto:scrumdevelopment-***@yahoogroups.com?subject=Unsubscribe">
Unsubscribe
</a>
<br>
</div>
<br>

<!-- |**|end egp html banner|**| -->


<div style="color: white; clear: both;"/>__,_._,___</div>
</body>
</html>
Michael
2010-09-01 23:20:50 UTC
Permalink
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.




------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kevin Johnston
2010-09-01 18:23:52 UTC
Permalink
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

------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
David A Barrett
2010-09-02 13:44:39 UTC
Permalink
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.
Aha! There's a smell you can latch onto.

Is is possible you can forbid, or refuse to pay for, or in some other way
stop, overtime?

Basically, what your team is doing, is building the overtime into their
Sprint planning. Stop that. Plan for whatever velocity your team can get
working 40 hour weeks with 60% of their time lost to "out of Sprint" stuff
that the VP of Engineering comes up with. If that velocity is fine with
the company then you're done. Otherwise it will force the company to
address the actual priority of these "out of Sprint" items.

At the minimum, that will bring transparency to the situation. You need
to make the argument that overtime is not sustainable, and results in poor
quality of work which undermines any gains in volume of work achieved over
the long haul.

There's always the possibility that you'll lose that argument, and the
company wants to encourage overtime to achieve unrealistic goals foisted
on your team. In that case, I'd recommend that you just stop calling what
you're doing Scrum and muddle on as best as possible. Personally, I can't
see how you'd be able to do Kanban either. An organization that can't
pull together enough discipline to keep distractions away from a Scrum
team is never going to have enough disciplen to respect WIP queue sizes in
Kanban. You'll have the same problems, but they'll just look a little
different.

None of which is to say that your team can't be effective, happy or
efficient. Just that trying to apply Scrum tactics to your situation
won't be particularly useful, since they all assume that you're able to
apply at least a minimal amount of the Scrum fundamentals.

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.
Michael
2010-09-03 14:16:31 UTC
Permalink
Dave,

I completely agree. Unfortunately, this team is responsible for 24/7 uptime on key systems. Which brings up your point that what they are doing is not Scrum, and I agree with that. Which means that the team and I will have to muddle along as best we can given the constraints put upon us.

Mike
Post by David A Barrett
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.
Aha! There's a smell you can latch onto.
Is is possible you can forbid, or refuse to pay for, or in some other way
stop, overtime?
Basically, what your team is doing, is building the overtime into their
Sprint planning. Stop that. Plan for whatever velocity your team can get
working 40 hour weeks with 60% of their time lost to "out of Sprint" stuff
that the VP of Engineering comes up with. If that velocity is fine with
the company then you're done. Otherwise it will force the company to
address the actual priority of these "out of Sprint" items.
At the minimum, that will bring transparency to the situation. You need
to make the argument that overtime is not sustainable, and results in poor
quality of work which undermines any gains in volume of work achieved over
the long haul.
There's always the possibility that you'll lose that argument, and the
company wants to encourage overtime to achieve unrealistic goals foisted
on your team. In that case, I'd recommend that you just stop calling what
you're doing Scrum and muddle on as best as possible. Personally, I can't
see how you'd be able to do Kanban either. An organization that can't
pull together enough discipline to keep distractions away from a Scrum
team is never going to have enough disciplen to respect WIP queue sizes in
Kanban. You'll have the same problems, but they'll just look a little
different.
None of which is to say that your team can't be effective, happy or
efficient. Just that trying to apply Scrum tactics to your situation
won't be particularly useful, since they all assume that you're able to
apply at least a minimal amount of the Scrum fundamentals.
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.
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-***@yahoogroups.com
scrumdevelopment-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Loading...