I often come across the call for consistency… it sounds sensible, but can often be more damaging than people expect. Here I am talking about enforcing consistency across teams, projects, departments, etc. It might be about using the same user-story tracking tool, having different teams’ iterations in sync, reporting project progress using a standard template, and so on.

There are advantages and disadvantages to enforcing consistency, but I find the call is driven by someone seeing only the advantages, possibly driven primarily by an underlying desire for neatness. When there is consideration of the disadvantages it’s usually—initially—just the pain of the upheaval.

Of course, there are usually more tangible advantages to consistency. Advantages of using a single user-tracking tool, for example, include people only having to learn one tool, being able to transfer user stories easily from one team to another, and only having to manage one set of logins and licences. Advantages of a consistent reporting template include ease of combining several reports to produce one summary report, assurance that particular matters are always reported on, and ease of quickly scanning several reports.

But those advantages are greatest for people whose work regularly spans several of those teams, projects or departments. Learning only one tool is not much of advantage if you rarely move team. Being able to transfer user stories easily from one team to another is not much of an advantage if teams tend to work on quite distinct activities (and hence there is little movement of stories between the teams). Ease of combining several reports is no advantage to the person who has to compile only one team’s report. Ease of scanning several reports is not important to those who don’t need to scan several reports.

Conversely there are disadvantages to enforcing consistency, which may be significant. Consistency forces a way of working which may not be optimal. A consistent approach to an activity can easily be too burdensome in places, or too restricting—or both.

For example, a mandated user story tracking tool might easily include fields that one particular team finds irrelevant, but exclude fields that they need. I once worked at a company where all digital delivery teams were required to select a financial category for each user story; since the selection was both meaningless and useless to them the data was never accurate.

I’ve worked with a project team that needed to spend additional hours creating reports to fit the company’s standard project reporting template, for a higher oversight committee. But the project already produced its own regular report, specifically designed to allow effective steering. The “standard” report did not help delivery. Instead, by shoehorning information into an inappropriate format, the team couldn’t help but give a false view of their project.

With these examples we can see that enforced consistency prevents teams, projects or departments working in ways that are best for them. These examples actually hurt their respective organisations in hidden ways.

There may be a middle ground in any such scenario. Ideally the people who really need (or want) the consistency can create it themselves, rather than pushing the work down into areas that don’t value it. Of course, that may not always be possible.

Enforcing consistent ways of working can lead to real positives overall. But we should be mindful that the advantages are often for the people working across teams, and there are likely disadvantages for people who work mainly within the teams. And those disadvantages can have knock-on effects to the organisation as a whole.

Photo by Victoria Pickering