Agile Coaches often work with teams and organizations deeply entrenched in the frameworks and practices that have become synonymous with Agile. One way Agile Coaches can help improve performance at these organizations is by introducing a different perspective about how those frameworks and practices, while once useful, might now be holding them back.

The Practice Trap

While codified Agile practices are intended to help promote agility, they’re really kind of bad at it. In my experience, they limit and constrain teams because of how they’re implemented or executed, how they affect team design and how teams operate, or because it leads to management exerting control over teams by forcing teams to follow specific practices.

The revelation I often share with Managers and Scrum Masters is that none of the practices they’ve been trained on or told to focus on matter. The proliferation of Agile frameworks has created such a fixation on implementing and managing practices that it’s easy for teams to lose focus on why they’re doing them in the first place.

The presence of practices indicates some level of intent or goals, and that intent can be a good starting point for exploring what they’re really trying to accomplish. That intent is the opportunity to introduce a different perspective on the Agile practices most teams have come to take for granted:

• Retrospective meetings aren’t important – but constant and continuous improvement is.
• Stand-up meetings aren’t important – but teams working together and collaborating is.
• Estimating work isn’t important – but predictability and working in small increments are.
• Sprints aren’t important – but completing potentially releasable work frequently is.
• Sprint reviews aren’t important – but getting feedback from real users and using that information to guide development is.
• Scrum Masters aren’t important – but coaching that helps teams increase their ability to self-manage is.
• Product Owners aren’t important – but developers having contact with real users or customers is.
• Kanban boards aren’t important – but improving the end-to-end delivery of the value stream is.

Behaviours are what’s important when it comes to improving agility, not practices. Agile frameworks are all about roles, meetings, artifacts and processes. When you take away the frameworks, what you have left are ways of working based on principles.

It doesn’t just stop at behaviours. We can go even deeper. Looking more closely at the last point: “Kanban boards aren’t important – but improving the end-to-end delivery of the value stream is.” Why is improving the end-to-end delivery of the value stream important? Can we validate that statement? It may sound like a good idea, but does that make it important?

The Danger of Ritualized Practices

When organizations implement meetings and practices to deal with problems, they sometimes fail to stick. Other times, however, they remain in place so long that the team forgets their original purpose as people in the organization move to different roles and jobs.

Teams can end up investing significant time trying to improve their practices when they’ve forgotten why they’re doing them in the first place.

The danger is when organizations codify behaviours and ways of working into new meetings or roles. Creating new meetings, roles, and artifacts to solve problems creates organizational debt. If there’s some particular task people need to complete as part of a workflow, teams should figure out a way to accomplish those goals aside from creating a new role or meeting.

A typical pattern I see is that many practices get implemented as a way to “over-correct” for a past incident. An undesirable incident occurs, and then a new meeting is put into place for all teams to follow to ensure it doesn’t happen again. The problem is that these meetings only help organizations cope with a problem. The new meeting lets them live with the symptoms of a problem while ignoring the root cause.

Organizations shouldn’t offload the responsibility of a behaviour to a meeting or role, but as we saw earlier, that’s all that Agile frameworks do.

Peeling Back the Layers

You can think of Agile practices as having different layers. On the surface, there are the meetings, roles, and artifacts we’re accustomed to. You have to go below the surface and understand what those practices are trying to accomplish. For every meeting, role, and artifact you see, ask yourself:

• “Why is this being done?”
• “What is this practice trying to accomplish?”
• “If we stopped doing this practice, what would happen?”

Once the reasons are understood, the practices become less important, and you can focus on the original objectives and improving the core behaviours needed to achieve them.

Questions to Ask

When examining Agile practices, consider asking these questions:

• Sustainability: Does the work stop if a key person takes a vacation? Does the practice create bottlenecks?
• Self-organization and Trust: Does this practice support self-organization, or is it a case of Agile mixed with command and control? Did the team decide on the solution, or was it pushed onto them?
• Value vs. Waste: Is this truly adding value, or is it waste dressed up as a value-adding activity? What would happen if we stopped this practice? What would happen if we did more of it?
• Real Problem Solving: Ask “What problem does this solve?” Are actual problems being solved, or are practices being implemented “just in case” some edge case occurs?
• Talk to people: Ask some different people what they think about the practice. Ask the team and ask their managers. What do they think the purpose is? Do they find it valuable?

Conclusion

The focus on heavily codified practices cuts off all the fruit from the branches. When teams only focus on practices, they lose the richness and options afforded to them through thinking about behaviours, goals, and principles. When teams understand their goals and principles, when they know what behaviours are important, they have more freedom to find their own ways of working.