Re: When managers estimate on behalf of the team in sprint planning
- For a stakeholder, the review meeting is too late to influence the direction of the Sprint, as it's in the past.
I'm sure we've all seen dysfunctional meetings. The solution is to educate the attendees about the roles and responsibilities, not kick them out of the meeting.
Agility is based on collaboration, and this includes the stakeholders. I'm not suggesting that the stakeholders provide estimates, but they should certainly be able to contribute to the discussion. What if there's a misunderstanding? Are you going to waste an entire Sprint building the wrong thing when having a key stakeholder available to answer a question to avoid it.
I can see keeping the stakeholders out of the daily meetings, as these are intended for the team only. However, the planning and review meetings should involve all interested parties as long as they play by the rules, and contribute to the effort.
From Ken's "Agile Project Management with Scrum" book (page 133):
"The attendees [at the Sprint Planning Meeting] are the ScrumMaster, the Product Owner, and the Team. Additional parties can be invited by any of these people to provide additional business domain or technology domain information and advice, but they are dismissed after this information is provided."
I'm not sure how you know when it's safe to dismiss the other stakeholders, so I see no harm in allowing them to stick around and provide answers as long as they don't interfere with the business at hand.
--- In email@example.com, Michael James <mj4scrum@...> wrote:
> On Nov 1, 2011, at 8:48 AM, "woynam" <woyna@...> wrote:
> > Where is it written that stakeholders do not attend the planning meetings?
> If what's written is important to you, you could read the last two of Ken's books for a pretty good starting point.
> I remember a Sprint Planning Meeting at one of the most bureaucratic places I've seen. The Team and PO were there, along with a dozen observers. Even though the tourists kept quiet, the conversation between team and PO was stilted. The next time we did it without the tourists and got a much more candid negotiation. The place for observers is the Sprint Review Meeting.
- Well said, David and MJ, couldn't agree more.The best situation I've ever seen wrt manager involvement is a manager I coached once. I'm not bragging -- I've only been able to make this work well with one of a handful of (functional) managers I've consulted for. Same record with traditional PM's (only one out of a few really "got it").He:a) Took the time to truly understand and embrace Scrum and truly accept coaching from me, andb) Stepped quickly away from the Scrum events(except the Review) once he understood the essence of Scrum (didn't take long), andc) Strongly encouraged the team members to be Scrum team players and for them to self organize. He was extremely flexible with solutions and gave the team a chance to find their own way in terms of self organization. In short, he made it clear that his view of each team member's performance was how well they performed at being a good "Scrum team player." I've been reading some of the "Freakanomics" types of books lately -- as they would say -- the incentives need to be aligned.I would argue that this person already had very good leadership and delegation(servant leader) skills, as well as a long history in software development, and those traits helped greatly, IMO. Same goes for the traditional PM that "got it", except she didn't have a long history in software dev. In a way, the ones that get it are ones that already have good leadership skills. The rest have to pick those up while implementing Scrum from a guide book, if they want to succeed with Scrum.But it only happened once in a handful of times. I've seen the authority vs. self organization problem reduced, but I've never seen it fully eliminated. MJ was right, we're probably a decade away, but in the meantime, the key is to minimize the problem as much as possible without alienating one's self as a change agent. In summary, get that manager out of the Scrum events(except the Review and maybe Release Planning) if there is any feasible way of doing so.-------
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
From: Michael James <mj4scrum@...>
To: "firstname.lastname@example.org" <email@example.com>
Sent: Wednesday, November 2, 2011 8:53 AM
Subject: Re: [scrumdevelopment] Re: When managers estimate on behalf of the team in sprint planningThe part the "do 'Scrum' but leave our static management roles/titles in place" crowd isn't getting is that the worker's behavior is affected by the power dynamic whether or not the manager abuses it. I've seen the same effect you're describing even on teams with the nicest, most cool bosses. When management seems to be someone else's responsibility, teams don't step up the same way. Even during a Scrum class it's beneficial for the instructor to leave the room sometimes.This is a natural, predictable effect of static hierarchies and defined management roles. One way of knowing for sure this is happening in an organization is everyone claiming it never happens.
On Nov 2, 2011, at 6:43 AM, David A Barrett <dave.barrett@...> wrote:I'd like to remind everyone that this issue was raised as a problem, so the manager's involvement was already proven to be disruptive to the Scrum process. My take on the initial post, though, was that it was presented like a minor glitch. A, "Hey guys, how are you dealing with this common occurrence?" kind of question.
To my mind it's a deal breaker. You fix it ASAP. If it was me, I'd call an immediate end to the current Sprint with the tainted estimates, grab the PO and the Team (and not the manager) and have a Sprint planning meeting this morning.
Even in the best organizations, functional managers can have a chilling effect on an open dialogue within a Team. It seems likely to me that this would be the case here, as the manager hasn't been able to let go and let his subordinates assume authority and responsibility appropriate to their jobs. So should the Team be "denied the experience and expertise of the manager", as someone else put it? You don't even need to get the scales out to weigh the pros and cons of this one: keep the manager away from the estimating process. The accuracy of the estimates is way, way, way, way, way less important than the Team's ownership of the estimates, ownership of the Sprint objectives and commitment to completing the tasks.
Is it a difficult situation? Sure it is, and I can personally relate to it. My own boss was constantly dropping little nuggets of negativism on my Team when we were starting out with Scrum. To say that it had a chilling effect on the Team would be understating it - it was freezing. Any "open" discussion with our boss present was stifled and extremely restrained, and the minute he left the room people would start to open up, speak their minds, suggest ideas, honestly critique ideas and generally contribute the way you wanted them to. Obviously, something needed to be done and it doesn't matter how good your relationship with you boss is, trotting into his office and telling him off is always nerve wracking. I ended up telling him that he demoralising the Team, and that if he wanted to vent his negativity I'm perfectly happy if he does it privately to me but to stow it in the meetings. On the other hand, the damage was done (even years later the Team is still somewhat restrained when he's present), so I stopped inviting him to most of the meetings.
The stakeholders thing is a red herring. Chickens are chickens and as such don't have the right to expect to be included in the planning meeting. End of story. If the Team wants their input, they can ask for it.
Am I suggesting that the Team take an "Us and Them" attitude and build walls to keep the muggles away? No. I'm simply saying that estimating is one of those things that Team gets to have all for itself - actually *must* have all for itself - and in many organizations that's a shocking about-face from past practices and corporate culture. So it probably wouldn't hurt to go a little overboard to make the point.
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.