Scaling agile the right way

Equipped with a tool that works seemingly well at small scale in very specific settings, how does one scale the success story of agile beyond one team, or even a few small teams, working on a greenfields project with limited dependencies. How does one solve the problem of scaling agile in a large complex organization? How does one cater for the increasing complexity in coordination, collaboration and prioritization that comes with scaling agile across many teams working on complex, intricately integrated systems dependent on delivery and reliability of third party vendors and their platforms?

Asking the Question

“Which governance processes do I need to introduce to improve my delivery agility? Specifically focusing on coordination, collaboration and prioritization”?

This was the question that I posed to the community, and the community gave a resounding response, “You are asking the wrong question.”?

“How is that?”, I asked. “What should the question then be?”

“How can you increase autonomy and reduce dependencies by introducing the appropriate team domain structures, supported by enabling architectures and engineering practices?” came the whisper. “The point isn't to increase governance, its to reduce it”

Wait. What? That's silly! That will lead to absolute chaos! Madness, I tell you!

I forged ahead with my dissertation, aimed at unraveling the dark arts of scaling the secret sauce of agile to large complex problems. But something wasn't right. Something didn’t add up. The quantitative studies produced a resounding “Yes” of approval to the proposed framework, but as we all know, such questionnaires lack the ability to highlight anything other than what the researcher has deemed to be significant features to measure, as it has limited to no open ended inputs. So, I was happy. It seemed that I was on track to show that more governance is better! I thought it good to do a qualitative study on the perceived benefits of applying this newly proposed framework to an existing case study, and this is where the penny dropped.??

“You are asking the wrong question.”?

The outcomes showed that even though the proposed framework would increase agility in terms of implementation because things were well planned and communication structures were well defined, it did not do so in terms of delivery, nor did it increase autonomy, instill ownership and accountability, and much less so increase productivity and employee happiness. It merely proposed a planning and communication structure at scale. More red tape for the bureaucrats.

“You are asking the wrong question.”?

The thinking

In the summary section of my dissertation, I alluded to the qualitative study findings, highlighting the need for further research, to identify the things that needed to change, to shape an organization to improve its agile posture. I specifically touched on team structure and value alignment, enabling architectural design, and engineering practices and processes to support this.

Reflecting on this now, many of these items have been discussion topics in the community for years, yet I somehow missed pulling the disparate sources together into a coherent argument. Following on from articles published by McKinsey (The journey to an agile organization and Agility: It rhymes with stability), Thoughtworks (Innovation in practice), UX Collective (Combining Agile, Lean Startup and Design thinking) and others, alongside books on Domain Driven Design (Eric Evans,2003 and Vaughn Vernon, 2013), Evolutionary Architectures (Neal Ford, Patrick Kua, and Rebecca Parsons, 2017) and Team Topologies (Manuel Pais and Matthew Skelton, 2019), the writing was literally on the wall. I just had to pull the strings together. And in my search for the answer, I came across a publishing that revolutionized my thinking, that gave me the strings to pull it all together. It was a publication that predated my dissertation by mere months. A publication from The Open Group called Open Agile Architecture. The publication brought together all the pieces, all the things that eluded me during my studies.

As in the days of playing Age of Empires, the black fog was lifted, the map revealed. And as my coach once told me, “Once seen, it can never be unseen”.?

O-AA Building Blocks - Open Agile Architecture

Asking the right question

So given my then new found insights, I set out to understand how one can scale agile in a large organization, by reducing governance to just what was needed to ensure that we can move at speed, without breaking our necks falling down the stairs. It turns out the question has more dimensions than just collaboration, coordination and prioritization. Dimensions such as

How can we structure our teams best to align with our value streams?

How can we fracture our value delivery channels to reduce complexity and cognitive load, increase customer centricity and improve autonomy and ownership?

How can we enable our cross functional value delivery teams by supporting them with core complex competencies and reusable building blocks?

How can we structure our architecture to best support these goals while improving the team's ability to make large scale changes without reliance or dependency on other areas?

How can we make sure that we can reliably deliver value into the hands of our customers on a regular cadence?

How can we ensure that our platforms are reliable and easily maintainable?

Now these seem to be the right questions to ask. These questions are addressing the problem at its core. It asks how we can shape our teams in such a way that they can do their work without complex coordinating structures, how we can structure our architecture to support this outcome, and which practices we need to focus on to enable reliable delivery. And as you can guess from the few (of many) samples of text included, each question has a complex answer. One that I will not try to answer here, but would love to delve into deeper in future discussions.