Re: When managers estimate on behalf of the team in sprint planning
- I was being somewhat facetious, but...
This one is so fundamental, so basic, it's not something you finesse.
There's three points that come to mind right away. The first is that the manager, if he's not the PO or on the Development Team, is a chicken. Chickens don't come to Sprint Planning meetings, and if they do, the sit quietly in a corner and keep their mouths shut.
Secondly, but just as important. One of the keystones of Scrum is that the developers estimate and get to pick how much they are going to commit to for each Sprint. Nobody. Nobody gets to tell the Development Team how much they will commit to.
Thirdly. This is what the Scrum Master is for. He has two jobs: clear impediments and make sure that the Scrum process is followed properly. This is a clear breach of the Scrum process and the SM here needs to step in and stop the manager from getting involved in the planning process. End of story. Otherwise this is going to be another one of those companies that say, "Oh, we tried Agile/Scrum but it didn't work for us".
I'd put this in the same class as Ken's story about not being able to get whiteboard for the Team room. So he started writing on the walls. Whiteboards showed up the next day.
--- In email@example.com, Joshua Partogi <joshua.java@...> wrote:
> On Mon, Oct 31, 2011 at 10:30 PM, David A Barrett <dave.barrett@...>wrote:
> > **
> > Well, you could start by not inviting him to the Sprint planning meetings.
> > Did it work when you didn't invite a manager to a Sprint Planning meeting?
> Or did it make him more defensive?
> Thanks for sharing.
- 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.