Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Where I work we recently switched the Agile development using Scrum. We went through the typical growing pains but have reached an approach that seems to work for now (whether it'll work in the long term is for another question!).

Obviously, the department management is happy the transition to Scrum is working. But they have starting doing something that, to me, feels wrong.

Management will observe a team, see what works for them, and the prescribe it to the entire department. Things like:

  • The definition of "Done"
  • Which story point values can be used for story pointing (eg, omitting 8 from the fib. sequence because 1, 2, 3, 5, 13, etc were the only ones used during a sprint they observed)
  • Telling teams they must calibrate their story point value of 1 to "updating a UI label," and limiting them to an upper bound of 20
    • (although not all our projects have clients and not all developers have UI experience)
  • Telling teams to use story point estimates of 100 to mean "we'll split this story later"
  • Telling teams to use story point estimates of infinity to mean "this is an epic" or "we need more info"

I understand they're trying to be helpful, but shouldn't all the things above be Scrum-team specific? That is to say, what works for one group of individuals on one project may not make sense to another group on another project.

I'm concerned we're drifting into a very prescriptive and stiff Agile approach. Am I justified in thinking this, or am I overreacting?


Just to clarify... by "Management" and "Manager" I don't mean the Product Owner. I mean any manager outside the Scrum Team, but within the Software Department.

share|improve this question
It sounds to me like Management is changing how AGILE works to best meet THEIR needs and not the team using the process. The only time that it makes sense for multiple teams to share the same story point size is when comparing different projects more easily, which isn't something that team members need to do. I would try and point that out to the Scrum Master to see if they have any pull and could possibly remind management that Agile is a process for the teams, not for the managers managing the teams. –  Ampt Jul 12 '13 at 15:36
Too many managers with too little to do is a great way to alienate talent. –  Erik Reppen Jul 12 '13 at 15:47
add comment

5 Answers

up vote 14 down vote accepted

Ofcourse you're justified in thinking that. The very fact that you're talking about "enforcing Scrum" is a blaring alarm siren.
Scrum is first and foremost about self-organisation of the team; they get to choose how to do their work and how to organize themselves. Management only has a say in what work needs to be done.
The reason why teams should organize themselves is that they are always unique, due to the different natures of the individual team members (and the people they work with) and the due to the differences of the products they work on. A practice that works perfectly well for one team, can have adverse effects on another team. That's why within a certain scope (a sandbox metaphore is often used), they have to experiment, learn and find out what works best for them.
What you need is a very competent Scrum master (one per team), who can guide a team in this discovery, but at the same time can also work with management to obtain the freedom for the team to go on that discovery.

share|improve this answer
"Management" not only has a say in what needs to be done, but also has a say in the non-functional criteria that the "what's" need to meet: quality, testability, robustness. Management has no say in how teams go about meeting those requirements, but they absolutely have the right to set the (acceptance) criteria in those areas. As such management does have influence on the definition of done. –  Marjan Venema Jul 11 '13 at 9:52
I'm not sure if that's completely accurate. It's a developers right and duty to produce qualitative software. If a manager has to stress that software to be delivered needs to be qualitative, testable and robust, then you have another (and probably much deeper lying) problem. If we're talking about SLA type of stuff, that's another story. Practically speaking, if a manager stresses quality, or testability or robustness, how will this be verified? Usually after shipping, by which time it's largely too late. Quality can be built in by developers, not added by testers. –  Stefan Billiet Jul 11 '13 at 10:08
@MarjanVenema The "Definition of Done" that I'm talking about here is a Scrum concept (DoD) and it relates to when a Story or a Sprint are considered "Done." I understand that a Dev manager would have guidelines for quality, testability, and robustness, but these are such basic requirements that they don't need to be explicit in the DoD. Like StefanBilliet said, if these requirements need to be explicit, then it's a sign of a bigger issue. –  MetaFight Jul 11 '13 at 11:10
I know they're not a given; I just prefer working with a talented team that can be trusted to get the job done properly, rather than working with people who couldn't care less. It's never really efficient to try to "enforce" quality standards through management. If the team doesn't care about the quality of their work, frankly, I think you need another team. And I'm not just talking about only developers either; support and business people have to be equally motivated and capable. –  Stefan Billiet Jul 12 '13 at 7:42
@MarjanVenema But you're missing the point. It's not about getting the team to care or being a system to game because it's not about accountability. It's about improving your estimates. Upper management shouldn't care what a team's DoDs are. They should only care whether their estimates are reasonably accurate or, if in need of improvement, whether they're improving. It's the team's business how they get there and the product owner who determines what the important obstacles are. Upper management shouldn't need that uniformity. If they do, you have a chain of command problem. –  Erik Reppen Jul 12 '13 at 18:16
show 7 more comments

Welcome to one of scrum's worst nightmare. You have encountered one of the reasons scrum fails to deliver the great stuff everybody has in mind when adopting it.

Unfortunately scrum is not compatible with upper management that tend to centralize and create management processes across the organisation and the teams. In order to be successful the upper management has to change their mindset and focus on what they need from the teams. They should not focus on how the teams work. The only time they should get involved, is if a team is not performing to figure out the reason.

I believe that you have to sit down with the management and talk about their requirements and what they want the teams to deliver. That can be a global requirement to all teams. It could be estimates that they understand, duration, etc. Those things should not dictate the teams processes. It is important that you separate the management expectations from the way you run scrum. Each team has to find their own pace and their own way of driving the projects, that will make them successful, productive, and deliver what the management needs. If for instance you have an estimate of 15 story points, the team should be able to calculate those points into man days (or hours) based on the average team velocity. But it will be unique to the team.

share|improve this answer
But there are scrum trainers who will take your money and tell you you can do that if they think you want to hear it. This is why statements like "it only works if you do it exactly as prescribed" are no substitute for critical thinking. –  Erik Reppen Jul 12 '13 at 15:41
add comment

As a company, balancing your resources should be a competitive advantage. Otherwise, just create a bunch of individual software companies that lose this type of leverage. An organization with multiple teams and projects has to be concerned with turn-over and team balancing. I don't think it is a good idea for every unique team combination to rewrite the book on how they are going to do scrum.

Anytime you're trying to aggregate things to measure something, consistency is important, i.e. don't compare apples and oranges. Management should focus on these higher-level needs, but make sure they don't get too involved in the details of how teams operate. Try to apply their suggestions, but be prepared to defend why it one team may be the exception. Anyone who just doesn't personally like a particular way of doing things needs put on their adult pants and deal with it.

There has to be some flexibility, so you can get the job done. There should be consistency when needed. If team membership gets changed, everyone shouldn't feel like it's their first day on the job.

Maybe your teams never change, but you should give that choice a chance by having some consistency.

share|improve this answer
I'm not sure I fully agree with you, but I think I understand what you're saying. Oh, and +1 for "put on their adult pants." I need to remember to do that more often (not kidding). –  MetaFight Jul 11 '13 at 20:36
Frankly, I disagree. When you are designating people to the status of "resource", that's the beginning of the end. Developers are people, not cogs in a machine to be switched around when someone feels the need. Your competitive advantage should be a combination of an extended technological maturity, combined with a deep domain knowledge; this is the stuff that great products are made of. All the rest is just shortsighted short-term cost savings leading to a long-term decline in the quality and greatness of you products, in my opinion. –  Stefan Billiet Jul 12 '13 at 8:43
add comment

No your not overreacting and you have good reason to be concerned. Management should be focused on culture change. Management needs to set the right direction and present the context to the teams to go at it using the agile ceremonies that work well for the team to be productive.

I feel lucky that I work in an organisation that has been going through agile transformation from waterfall for over a year and started in the portfolio that I work in. They originally started with one project where an agile team was formed. The success of the delivery through agile ceremonies like retros, relative estimate, historical forecasting using velocity led to the whole portfolio forming additional teams with their own backlog.

From experience, Agile is not prescriptive and you can't roll out a cookie cutter approach. Just because it worked in one team doesn't mean it will work in another. I know this from experience because we originally thought we could jumpstart new teams by applying a the same things like DoD, what 1 point means, what 8 point means. But it doesn't work as contextually they have little meaning when applied to a different team. Incidentally, for one team story above 8 points meant it was too big and needed to be split.

What worked was setting guidelines for the teams, like they have to do stand-ups, retros, showcases at the same time and at each retro actions where teased out and implemented to improve the new teams. Other things like definition of done and sizing of story points was introduced after a couple of sprints as the team became more familiar with the concept of story narration and completing cards and not having it creep into the next sprint.

I know this is a hard sell to management as they want to know when projects will be delivered and when forming new agile teams it is difficult to give that picture upfront. But now the portfolio has a reputation of having strong agile delivery capability. We would still be stumbling if the cookie cutter approach continued to be pushed to the other teams.

share|improve this answer
add comment

Well, why not be the manager for a moment. Your management may be more SCRUMmy right now than you think. Climb up the hierarchy one step and you will find that it's the same thing you expect from a SCRUM team member:

As a manager, I would like to have definition of done with all my teams. Whenever a team says it's "done" I want to know what I can expect. The manager doesn't want to have 3 different meaning of "done" from 3 teams the same way you don't want to have 3 different meanings of "done" from 3 developers. The very same problem with the same solution. Write down a definition of done.

As a SCRUM-Team, I would think that the first point of "done" is to fulfill the managements definition of done. Then each team can have more policies on top of that. If many teams have the same additional definitions, you can discuss them and maybe they will climb up the tree and end up in the managements definition of done.

Calibrating story points probably stems from the fact that the manager needs estimations before coding. How long will that project take and how much do I have to charge the client or how do I have to price the product. If your teams can deliver real time estimates, then I don't think a manager cares about story points. But if all he gets is story points, he needs a measurement. And as I manager, I would not want to have one per team. A single one is just fine, thanks.

The "100" means X and "Infinity" means Y is just normal. He manages multiple teams. He does not want to switch between definitions multiple times a day. Just imagine you had 5 people in your team and everyone invents his own word for Epic: One calls it "Epic" by the book, the next "Legend", "big stuff", "Huuge", "TLTE" (too large to estimate). I'm pretty sure you would sooner or late tell them to use the same word when communicating. That's the position your manager is in. He wants to come to a meeting and not have to remember what the word was that your team uses. He wants to have the word that is used.

Basically, your manager is doing for his team-members (his single team member is what you think of as a full team of developers) the same you did for a SCRUM-developer-team: definition of done, using the same vocabulary, talking about the same amount of time when saying "1 storypoint".

share|improve this answer
I can see why, as a Manager, you'd like to have a unified definition of DONE and a unified calibration of SPs. But the problem is these aren't Manager tools, they're Development Team tools. So I disagree that's OK for a Manager to prescribe a unified approach for all teams. The whole point of these tools is that they're customised to the team using them. –  MetaFight Jul 11 '13 at 11:03
No, enforcing stuff like that stifles team collaboration (ie the team owning their own process). Using the same words does not help: "HUGE" for one team might not be "HUGE" for another. In general, you cannot compare velocity (points per iteration) between teams. The same applies for DoD. This is just another case of managers not trusting their team. –  Martin Wickman Jul 11 '13 at 11:26
Well frankly, I would think that the first point of done would be to fullfill the customer's definition of done. We're not in this business to build software for managers, we want to delight our users... If you want estimations, work with your team, don't just take a sheet with some numbers and run some extrapolations. Story points are meant as a calibration tool; if you want a decent estimation, you'll have to watch the teams delivery cadence and ask their opinion. –  Stefan Billiet Jul 11 '13 at 13:07
Just to clarify: I assume the "manager" is also the product owner, because there is no "manager" role in SCRUM. –  nvoigt Jul 11 '13 at 13:20
If we're talking about a product owner that is overseeing several products and their corresponding teams, then that would be one of the root problems right there. –  Stefan Billiet Jul 11 '13 at 13:30
show 1 more comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.