Congruence Between Agile Process and Ecosystem

In a recent SoundNotes Q&A with Mike Cottmeyer, our Fearless Leader fielded questions on a range of topics related to organizational transformation and agility. One key point he made was that any process or method, such as Scrum, LeSS, SAFe, etc., is designed to operate under certain conditions. Each process or method assumes it will be used in an ecosystem that has certain characteristics. If the ecosystem surrounding the process is not congruent with those assumptions, the process or method will not function as designed.

I think this is a point that bears repeating. There’s a lot of noise along the lines of “we tried X and it didn’t work,” and when we try to dig out more information about exactly what happened (or didn’t happen) in those cases, we don’t usually get much of an answer. People tend to throw magic hammers at problems, and when the problems persist, they simply declare that the magic hammers were flawed.

Have you seen, heard of, or worked on a Scrum team that couldn’t get traction with Scrum because the Product Owner refused to do this or that, as recommended in the definition of Scrum? It’s a very common situation. That Product Owner is part of the organizational ecosystem surrounding the Scrum team. If that ecosystem is not congruent with the underlying assumptions of Scrum, then whenever the team tries to act on a Scrum principle, the organization will not respond in a way consistent with Scrum.

Mike observed that when this happens, ScrumMasters tend to “go inward.” That is, they focus on helping their own team implement the Scrum framework “better.” But unless the rest of the organization is on board, it won’t matter how skilled the team becomes at using Scrum. They will continue to run into organizational friction.

There’s an old value in the Agile community that I haven’t heard much about in recent years, but Mike mentioned it in his talk: Courage. A ScrumMaster in a larger organization must discover the courage to address organizational constraints beyond their own team, even when the individual does not have the formal authority to address those constraints. It’s a tall order. But unless someone steps up, things will never improve.

The bottom line is you can adapt the ecosystem to the process, or the process to the ecosystem. In the short term, it’s often not feasible to adapt the ecosystem to the process. As a practical matter, we have to begin the transformation by adapting the process to the ecosystem.

That’s why we don’t focus too much on implementing the mechanics of Scrum or SAFe or any other method by the book. We want to apply Agile principles to the extent we can, but the goal isn’t to perfect our use of Scrum or SAFe, it’s to improve the organization’s effectiveness at delivering customer value. To that end, we can work with any process that’s in place, and seek practical ways to move the organization forward from there.

If that sounds rather like the Kanban approach, it’s not a coincidence. But the Kanban approach is to observe, visualize, and measure the current state for some time before taking any action to improve organizational performance. There’s wisdom in that, but it’s often applied in a rote way as if we literally have no idea what kinds of problems typically occur in large IT organizations, or what corrective actions are usually effective.

That’s not quite true. We do have a pretty good idea of what problems are common in the industry, and which corrective actions are usually effective in countering those problems. It isn’t necessary to wait before implementing at least some improvements.

While it isn’t necessary to wait forever while visualizing and measuring the current state, it’s also not advisable to “implement” a process or method in a rote way. All too often, organizations adopt a published process or framework by the book, only to end up throwing away money and wasting time sticking things on the walls and stringing yarn all over the place without understanding what the organizational constraints really are.

There’s a balance to strike. We can start moving forward based on what we know of commonalities across organizations, while still acknowledging and dealing with the unique characteristics of each situation. As organizations move through our compass model, they develop the skills and capabilities needed to advance step by step in a way that’s neither arbitrarily disruptive nor too slow off the starting line.

The key to success isn’t a matter of choosing the “right” framework – SAFe, LeSS, or whatever. The key is in creating the right ecosystem. Any framework, nor no framework at all, will work when applied with the right ecosystem. No framework will work otherwise.