To many in the Agile space, consistency sounds too much like “Taylorism” and so it is shunned. This is too bad because there is value to consistency in certain things. For example, if teams are to work together well, there must a consistent way of making agreements with each other. Or if estimates are being used to help teams coordinate, a single system should be used. Consistency helps teams avoid reinventing the wheel when effective practices are discovered.

But dogmatic consistency for its own sake is not a positive thing. It stops innovation. It inhibits looking for better ways to do things in different situations. This is made more complex because developers are very independent and like to do things the way they like to do them. The phrase “herding cats” comes to mind! The question is what needs to be consistent and what needs to be able to be varied to fit the situation of a team?

When it comes to consistency, Agile, and Scrum in particular, have unintentionally set up a perfect storm. Agile has unintentionally reinforced a free-wheeling attitude; it is as if we have interpreted “people over process” to mean “lack of discipline is OK.” It is reinforced by the claim that Scrum works because of self-organizing teams- unintentionally implying people can do what they want. “Consistency is the hobgoblin of little minds” seems to be the attitude which sometimes causes an over-reaction for consistency.

Why frameworks often fail to achieve consistency and the cost when they do

Organizations sometimes attempt to achieve consistency through the adoption of frameworks.

At the team level, Scrum is a natural choice for a framework. The Scrum Guide (2017) says that roles, events, artifacts, and rules are immutable and then, as a lightweight framework, it leaves it up to the team to fill in their practices. So while the framework is consistent, what is put into it often is not. This immutability often works against Scrum when it is used in situations where it is not ideal. Some variation is needed but few guidelines are provided. So what could be minor breaks with Scrum to make it work in a particular context often result in dropping out entire practices.

SAFe® goes the other way by being both a framework and a complete set of practices for people to follow. But SAFe implemented for the sake of consistency tends to have people focus on SAFe instead of their real challenges. In addition, it is much heavier than what most organizations with 600 or fewer technologists need.

The reality is that some methods and actions need to be consistent but not all of them. How do we know which is which?

Why and how to achieve consistency

Consistency should be viewed as a means to an end. That is, always keep in mind what you are trying to achieve with it. Not everything has to be consistent. If teams are stable, then the methods used inside teams can vary as long as teams interact with each other and with product management in a consistent manner. If teams are not stable (and this presents its own set of challenges), then consistency across all of the teams may be useful so that people can move between teams more readily. In any event, consistency in how teams work with other teams is important, so they can work together to achieve the goals of the organization.

When looking at where you need consistency, you must ask, “What challenges is inconsistency causing?”

Pillar: Value realization

Now, the word “challenges” implies you are being slowed in reaching your goal. So, what is the goal? Net Objectives believes the goal should be the quick realization of value predictably, sustainably and with high quality. We call this “Business Agility.”

Of course, different companies will define value differently based on their mission. For example, a financial company might focus on retaining assets, improving customer experience, lowering costs, compliance and lowering risk. Whereas a not-for-profit organization providing meals and housing for homeless may focus on number of meals served and beds provided, the amount of monetary donations received and the value of non-monetary donations.

However value is defined, attending to achieving value is something everyone in the organization should align on. Therefore, the definitions must be made clear (for more information, see Aligning Organizations at Scale). The first step towards consistency is making agreements with each other about how people will work together.

Pillar: Agreements on working together

To help with this, Net Objectives has defined The Guardrails System, a set of essential agreements that people make to with each other:

• Work on items that will realize the greatest amount of Business value across the enterprise.
• Collaborate with each other to maximize the realization of Business value across the enterprise.
• Ensure that all work will be made
• Take the necessary steps to sustain or increase predictability.
• Keep the work throughout the value stream within capacity.
• Encourage everyone to strive for continuous improvement.

We now have two of the three pillars needed for effective consistency in an organization:

• Alignment around value realization consistent with the mission of the organization
• Agreements in how we are going to work with each other

Pillar: Intention of practices

The third pillar is understanding what the intention of the practices are that you agreed to. By understanding the intention, you can achieve consistency in realizing specific objectives while allowing for teams to implement them within their own context.

Let’s consider two common Scrum practices as examples: Estimation and the Daily Stand-up.

Example: Consistency in estimation

Estimating stories has several purposes. It ensures that people involved have a common understanding of the problem (wide swings in the estimate of a story indicates lack of shared understanding). It can also be used to compute the velocity of the team which is useful for both stakeholders to understand when things will be done as well as to manage dependencies between teams. The use of story points, or Gummi bears or T-shirt sizing is not as important as the velocity that will be achieved by the estimates and how they are tracked. Consistency in how the estimates are achieved (such as planning poker or team estimation) should be left to the team (for more information, see Estimation).

Example: Consistency in Daily Stand-ups

Almost always, teams should be doing Daily Stand-ups. However, there are different ways to do stand-ups: some focus on the individuals and others focus on the work taking place. The point is that teams should do stand-ups but how they do them should be left up to the team (for more information, see Daily Stand-ups).

Consistency in the Agile work itself

Frameworks are so embedded in Agile culture that when we discuss consistency, we invariably talk about the practices mentioned in the frameworks. But Scrum is a framework that is lightweight and intends for people to fill it in. Left to themselves, most teams will do this in a different fashion. Although Scrum is normally taught as a generic framework (that is, as a product development framework that can be used for any type of product) when teams are going to be doing software development, it is important that it be taught specifically for software developers. One aspect of how to adopt Scrum effectively is to focus more on the work that takes place in the framework (such as creating Agile requirements) than the framework itself.

A focus on achieving value in a consistent way across the organization is imperative. This enables agreement on deciding what to work on when capacities are in short supply. Acceptance Test-Driven Development adopted across teams is a great way to improve the teams’ abilities. By having a consistent method of identifying what to work on while having a consistent, effective manner on which to do the work, teams can better work together.

Putting it all together

It is essential to take advantage of a few tenets of Lean Thinking to actually achieve the right degree of consistency. This should not be surprising since Lean inspired Scrum and other parts of Agile.

Here are a few key tenets of Lean to focus on.

• The ecosystem people find themselves in has a significant impact on the quality of their work
• It is important to attend to the flow of work and eliminate delays in workflow and in getting and using feedback
• How people work together must be visible so that it can be used a basis for improvement
• Management’s role is to work with the teams doing the work to improve their ecosystem

Achieving consistency involves creating an ecosystem that supports it. Having a support system that people can use to get questions answered on the intention of practices and their alternatives is critical. See The Net Objectives Scrum / Team Agility Support System for one on Team-Agility.

People in general, and developers, like to know, “What’s in it for them.” Merely demanding consistency will rarely achieve it. Making it clear as to the why and how it works for them makes it considerably easier. By providing training in Agile practices, not merely the framework(s) being used makes their job much easier. This combination of understanding the why greatly facilitates useful consistency.