Enforcing a uniform Scrum approach to all teams within a department

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.