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.

  • 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
    Commented Jul 12, 2013 at 15:36
  • 5
    Too many managers with too little to do is a great way to alienate talent. Commented Jul 12, 2013 at 15:47

5 Answers 5


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.

  • "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. Commented Jul 11, 2013 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. Commented Jul 11, 2013 at 10:08
  • 1
    @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
    Commented Jul 11, 2013 at 11:10
  • 1
    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. Commented Jul 12, 2013 at 7:42
  • 1
    @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. Commented Jul 12, 2013 at 18:16

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.

  • 2
    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. Commented Jul 12, 2013 at 15:41

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.

  • 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
    Commented Jul 11, 2013 at 20:36
  • 3
    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. Commented Jul 12, 2013 at 8:43

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.


Inconsistency in practice between Scrum teams may actually be a problem, for example if team members move between teams.

It would be better to try and go about solving these kinds of inter-team knowledge sharing issues in a more agile manner - perhaps something like running Lean Coffee or Scrum-of-Scrum sessions involving your scrum masters. This would hopefully get your management to realize that your are taking ownership of this area and stop trying to manage the problems in a top-down fashion.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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