Scrum Management – Enforcing a Uniform Scrum Approach Across Teams

agilemanagementscrum

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?

Edit

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.

Best Answer

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.

Related Topic