Re: [scrumdevelopment] Re: When managers estimate on behalf of the team in sprint planning
- +1We, the people doing the development work, are partially at fault for allowing others to estimate for us. We let them.Would you ever see....... You are the mechanic and I'm paying you to fix my car. The repair will be done in 4 hours, not 8.... It's my house and I'm buying the paint so you will paint it in 3 days, not 6. And I'm only providing half the paint you requested because we just don't have the budget for more. Remember, we need a paint job that will look good and last!... Oh, no, my physical therapy after the knee replacement needs to be done in half that time. I have a hiking trip in only a month!... I know we planned on my son's braces taking 18 months but our plans have changed. Get the whole treatment done in 6 months less. But don't cut any corners! He needs a great smile!Nope. We generally don't expect to dictate such things to professional mechanics, painters, therapists and orthodontists. Because they would tell us to go somewhere else. Yet we let people do this to us, software (and other product) developers.Alan
On Nov 1, 2011, at 10:28 AM, "frede_swe" <fredrik.vestin@...> wrote:
I would argue that regardless if you're agile or not, noone is better at estimating than the ones building the stuff. :-)
--- In email@example.com, "woynam" <woyna@...> wrote:
> Unfortunately, a percentage of individuals will not embrace agility. Many of us have seen this throughout the years. After investing in training and coaching, they're not ready to give up their command and control ways. I've seen this happen with developers as much as managers. As much as we like to think that people embrace self-determination, there are those who simple want to show up to work and be told a) what to do, and b) how long to take. Sigh.
> We often joke that developers have "Miranda Rights".
> "You have the right to estimate your tasks. If you do not provide an estimate, one will be provided for you free of charge." :-)
> This poor attempt at humor often helps get newcomers over the hump, typically people who were used to having estimates handed to them.
> In some cases, as others have pointed out, the inability to provide an estimate is a sign of deeper organizational issues. In one case, I spoke with a developer offline who was worried that any number they give could contradict a number that their boss had given someone outside the team. Rather than possibly incur the "wrath" of the boss, it was better to just shut up and let the boss do the estimating, since they always provided estimates in the past. Double sigh.
> --- In firstname.lastname@example.org, "frede_swe" <fredrik.vestin@> wrote:
> > Hi,
> > Have you asked the manager the reason for not letting the team estimate? Is he afraid that they'll under- or overcommit or that the planning will take too long?
> > I would argue that the team that is actually building the stuff are the best at estimating the effort. The team will be much more motivated and commited to delivering since they have been involved in the process.
> > /Fredrik
> > --- In email@example.com, Joshua Partogi <joshua.java@> wrote:
> > >
> > > As a scrum master, what approach you have done to convince the manager to
> > > let the team do the estimation in sprint planning? In one organization, the
> > > manager does not trust the team to do the estimation hence he makes all the
> > > story points instead of the team.
> > >
> > > Anyone care to share?
> > >
> > > --
> > > @jpartogi
> > >
- 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.