Interested in becoming a Certified ScrumMaster? Come to my next workshop!
Welcome back to a new week and new cartoon at www.implementingscrum.com.
For new subscriber via email, facebook, and twitter — Welcome and thanks for the interest in the site.
Please feel free to pass this site on to your friends and talk about it on twitter and other social networking sites.
The problem depicted in this cartoon is something I see a LOT when working with teams around the world.
Even when Scrum is being implemented on teams within an organization.
Hmmm.
So what do we do about this situation?
When asked for a status from a Chicken within a Sprint, Scrum talks about the team members not saying, “No” and punting it to the Product Owner.
The same goes for a new feature request.
In the past… before Scrum… this type of request was a major cause of never getting to “Done.”
This is the main reason to have a strong demarcation point between the Product Backlog and the Sprint Backlog. The main reason is to help shield the team from the outside “Noise”.
Care to share some real life stories about this via comments below?
How do you do this without committing career suicide?
Who really is responsible for telling outside Chickens to speak with the Product Owner?
What does the Product Owner need to do with this next?
Is this really an important concept or what do you think about it?
Please share with us…
Thank you,
- mike vizdos
6 Comments! to “Updated Cover Sheet for the TPS Report….”
Leave a Reply
Comment moderation in full effect!
All comments at Implementing Scrum are moderated to help cut back on spam.
This only happens once (more if you are using multiple computers). Once you are in the system, everything is good to go after that.
December 9th, 2008 at 11:40 am
How to do that without commiting career suicide?. Well, as any other important thing, Scrum adoption has to have the support and comitment of the *real* bosses, those in the high high high positions.
On the other hand, a good product owner helps on those situations: a PO willing to put himself in the middle on those situations and give accurate information to the chickens.
The product owner should say: “come and talk to me, what do you want to know? what do yo want us to do?”.
December 12th, 2008 at 7:56 pm
I’m with improbable on this one… you need a ’strong’ and ‘empowered’ product owner who has offered up their ownership of all scope before this can happen. At our organization our ‘product owner’ checks out when it comes to technical things and so our boss/bosses come and ‘tell us’ what to do. Frankly, we don’t have the option of saying “Go to the product owner” without damning ourselves. That’s not ‘being a team player’.
December 12th, 2008 at 9:42 pm
Hi,
Sounds like the first two people responding (thank you!) have very similar situations. It is [sadly] something I see often too. Ug.
One of the things I suggest is having conversations with the “highest” people within the organization to help garner support from them.
See http://www.implementingscrum.com/2007/10/30/combo-packing/
This is hard.
Again.
Doing it without committing career suicide is a fine line.
Helpful hints welcome.
Thank you!
- mike
January 12th, 2009 at 11:38 pm
[...] last cartoon of 2008 covered the topic of how to handle questions from outside stakeholders during a Scrum (or [...]
February 9th, 2009 at 9:19 am
I’m sorry but I would argue that an inability to manage the process is career suicide. As a consultant you are paid to make the process work and allowing activities to circumvent that process will undermine your efforts and dilute the value of your end product.
We all know that inflexibility causes cracks and ultimately product failure, so the challenge is managing compromise.
I have handled this situation in exactly one of three ways.
First is that you push it back to the product owner. Most of the time that works without issue. Nine times out of ten, they respect the process and will back down, or find someone else ( non team ) to handle the task.
Next, in the case where they are adamant, then a next option would be to evaluate doing it yourself. If it is a small task, and have the bandwidth, do it yourself, to avoid the team distraction.
Lastly, if doing yourself was not an options, then keep a “side track” section to your backlog where you can park items like this for people that either complete their tasks early, or are willing to work a little overtime to get it done. This should be the last resort, because you do not want to start a trend where you reward “heroes” and allow exceptions to the sprint. But allowing this as a rare exception provides the Product with the comfort that the process will support minor fire alarms, which none of us can avoid.
May 19th, 2009 at 12:13 am
Mike, what if you’re truly in a bottom up scrum and there just isn’t support for it. “be as agile/scrum as you can be” but “We aren’t fixing impediments”.
Bringing up impediments has been a slow introduction. Everyone is afraid to look “weak” or show “failure” in front of their peers. People mark things done before QA or Product owner signs off on the story/backlog item. Not everyone required to make “Done” is a pig.
So to ignore this chicken that comes up and says “Do this for me” would be hugely detrimental since “You scratch my back, i’ll scratch yours” is in play. Or worse, “Don’t do this and i’ll just go get your boss to make you do it”.
Frankly the product owner and “Boss” are two different things in functional organizations.