Agile organization, the roots and the future of Agile

Designed for the purpose of chilling . Credits Pierre Neis

Twenty-one years since the Agile Manifesto, and what happened? From my perspective, the agile world unleashed a considerable amount of creativity. Every month, I feel that a new methodology or tool emerges, even if most of them are purely rebranding old ideas.

1994, in their book “Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer,” authors Goldman, Nagel, and Preiss explain “companies and individuals to become “agile” — how they can thrive in a competitive environment of constant, unpredictable change.” In 2021, twenty-seven years later, we still explained that Agile helps to thrive and survive in a VUCA world. Exact words over time, and I asked myself did we initiate change or create a huge distraction?

It is not a provocation, and it is a statement that change is happening at a meager pace, but I perceive a slight acceleration since 2020.

Yes, I can say that the early developers adopting agile are now in a leadership position. But I believe that the COVID situation forced us to move forward.

The Agile Manifesto wasn’t the source of Agile, and it was its accelerator in a context no one cared about, the IT.

Why do I believe that organizational design is the root of agile?

I have my biases, and I see everything from a systemic angle. Maybe I’m wrong, but I saw the effects on my clients over the past twenty years.

I suppose my vision of Agile was always from an organizational perspective due to my Kaizen background. I embraced Beyond Budgeting twelve years ago, discovering Semco simultaneously, and being annoyed by Freedom Inc. and Reinventing Organizations sharing the same stories that I heard thirty-five years ago at university.

While interacting with Mike Beedle on Enterprise Scrum, I felt confident enough to express my ideas on org design. I asked why nobody seems to consider the individuals and interactions seriously, even the business and IT working daily together. I came with annoying coaching questions asking to highlight the part of the manifesto mentioning software development and engineering and what are the other 99% doing? Is software development only an engineering topic? What is software development in an agile context? Considering value for the customer, what is the value for the customer? Isn’t software a tool for a mean? When business is thinking about business processes or SAP modules, isn’t software too? Can configuration management be considered software development?

Twenty years ago was the beginning of offshore development. Now, offshore is mainstream, and working with globally distributed integrators is the condition to ensure the completion of work. From an organizational perspective, I wonder if none of the agile at scale approaches correctly address this point.

In my agile coaching masterclasses, we analyzed Scrum. What makes Scrum so popular? If you use it purely as a methodology, you miss all the team dynamics, motivation, sense of belonging, and self-organizing parts. When you put it under the microscope, you understand the simple org design and the early research on complex system theory. Complex systems are how humans interact together, and it is behavioral, not technological.

2010 was the next step for me, I attended the Cynefin workshop with Dave Snowden in Frankfurt, and it was the first Lean Agile Conference in Antwerp. At the conference, John Seddon gave a keynote on Systems thinking. Seddon is controversial, but nobody noticed that he pointed out our love of methods and tools over systems.

What is agile organization?

In my research, I came to design how a pure agile organization might look alike. All the documents over the last decade have been gathered, all the experiments documented, and I wrote my first book in 2020, “The new normal, AO concepts and patterns of 21-st century agile organizations”. The intention was to give guidance and a couple of coaching tips to help you to design your agile organization.

Even if all agile organizations are different, they are always commonalities: playing agile, doing agile, or being agile. I improved the NextGen model from the digital transformation world, leading to a model considering the organization like a platform.

In conversation with customers and other agile coaches, I notice that there is still a massive misunderstanding between structure and organization. The first is designed for compliance, and the second is for value creation and influence. The word “structure” should be prohibited in the agile world and replaced by organization. Organization relates to systems, and agile is an evolution of systems thinking.

The agile organization wants an organization full of designers where everyone can create the best environment supporting their actions for their ambitions.

Managing in complexity or leading in complexity are often misunderstood. Managing in complexity relates to organizing, measuring, or controlling actions in a complex geographical environment. Leading in complexity links to our guiding efforts in and for self-organized teams (complex systems).

The very nature of Agile isn’t purely complex (constant evolution), but it evolves empirically based on context and purpose. A minimal organization is a team. If, after a month, one team member wants to stay in the team he loves, but the work he likes is in another team, he should be free to move. Suppose your software development or finance team is working on an end-to-end process, and that process evolves and become more significant. In that case, you should be able to reorganize or propose to reorganize.

Unfortunately, we are too few people working that way. The will of control is still strong. Increasing the number of Trains in SAFe is misleading and highlights ignorance. If you are practicing SAFe, one quarter, you can have five Trains, eight the next, and maybe have three again. Trains are never stopping for a customer, not on the rail or smashing customer’s on the rails but not at the station.

If you are a Lean believer, look in the Lean Thinking area and models like McKinsey’s 8W. It is designed chiefly for linear, production-like work and is quiet, not responsive over a short period.

My intention while writing these lines is not provocative. The purpose is to notice that the scope of agile has become more significant and more prominent than expected in the earlier visions.

Please remove scaling from your organizational vocabulary.

In books, social forums, and other conferences, someone will always explain how they scaled the agile way of working. Most documentation or business cases are sales pitches and never reflect the reality of the work.

They are plenty of methodologies actually on the market that is almost doing the same:

  • SAFe is a waterfall approach giving the smell of agile without changing the work structure.
  • LeSS is a Lean approach with agile components.
  • Scrum at scale for mostly IT projects
  • Nexus, an engineering approach at scale
  • And agile@scale is the newcomer.
  • Disciplined Agile doesn’t have enough coverage and key differentiator to objectively consider as a way of working for large global organizations.

Even though SAFe is the most popular approach on the market, the framework includes everything. Still, it at least applies only to Scrum as designed before 2010, including Roadmapping (PI planning) and Scrum-of-scrums. Before 2010 it was necessary because Scrum had been redesigned to align with the complex adaptive organizational model after that date. Scrum has become more agile in giving the teams the autonomy to work like independent startups.

For a couple of years now, big consulting companies like BCG, Bain, McKinsey, and Gartner have provided their new model called agile@scale. If you know how these companies work, they are primarily linear and try to apply their patterns repeatedly (not agile). agile@scale is a bit weird. It combines the essentials of SAFe (not too bad) with the Spotify model (which isn’t a model) and OKRs. The model is helping to unbundle functional silos into Areas, Chapters, and other Guilds. The model isn’t too bad, but it remains primarily a linear model because neither the customer nor the execution is considered.

Don’t get me wrong. I’m a consultant and sold as an expert to our customers. I make the difference between what the customer wants and what the customer needs with him. And, then we start the organizational model with the end in mind and stages moving from scientific management to systems thinking, and finally to agile like described in the AO model.

Remember.

The scaling essence is grounded in linearity: previously designed patterns and then deployed. People in operation have to execute the patterns.

If that scaling is a top-down approach, your organization works like scientific management. If you allow downstream units to be challenging your patterns, and your deployment only starts through consensus (hoshin kanri), then your model is more on the systems thinking model.

When your teams are independent and customer-centric, and the outcomes are documented when completed, you are in the agile world.

There are some exceptions like SAP projects, but these are configuration management projects that use pre-defined components. SAP projects are interesting in shifting from a systemic approach to an agile approach.

Scaling inherits the idea of building a factory with a simple organizational design applied everywhere for the sake of functional control. It is a colonization principle accepting only small variabilities. On the other hand, Agile is a diversity-based approach in constant evolution, moving from needs delivery -> requirements delivery -> compliance like any progress in a simple cone of uncertainty.

How do you identify misleading approaches?

  • The customer is not in the loop.
  • Nobody knows the user.
  • Emphasis is given on management and control.
  • No transformation budget
  • No ROI calculation
  • Execution is forgotten.
  • Only IT centric, not whole business centric
  • Only business centric, not whole business centric
  • Agile only top-down (should be 90% bottom-up, 10% top-down)
  • Agilizing the wrong people first: those who are not working with the customer and not producing value.
  • Too many agile roles: three are enough

Pierre

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Pierre Neis

Pierre Neis

326 Followers

On my business card, I wrote Agile Coach. My Agile coaching is an evolution of systemic coaching putting myself in the system and not as an outstanding observer