Should you use agile principles to organize a firm?

“Agile” was intended as an approach for managing software development teams.

But it has become one of the hottest business trends – and it is no longer restricted to software firms.

Many leaders – more than 90% in some surveys – now say that they want their entire company to work in “agile” ways.

But can you “scale” agile principles, intended for teams, to organize an entire organization?

Traditionally, software people used to create extensive plans for how they work. The dominant approach used to be the “Waterfall” method, where you basically analyze, design and budget everything up front. Then you monitor progress as you write the code against key metrics that were set in this planning process (cost, time and scope).

The “Agile manifesto” was published by a group of software developers in 2001. It was a protest against the Waterfall approach, which was seen as too cumbersome and inflexible. A new set of principles were proposed as an alternative.

There are many different definitions of Agile. But in software development it is typically associated with three key features (illustrated with the icons above):

• Speed – one works in “sprints”, typically 2 week periods, and try to release small things early and often
• Teams – one works in small teams that are empowered to take decisions
• Customer involvement – one receives frequent customer or user feedback on the releases

We can add a fourth element: Face to face communication. The authors of the agile manifesto preferred face to face communication over written communication.

This approach makes a lot of sense, and has been widely adopted.

But unfortunately, it has gone too far.

Agile has become a fad. It’s being sold as a universal prescription to any kind of affliction that a company may suffer from.

Instead of starting with a diagnosis, leaders now start with a conviction that Agile is the right way. Or they try to copy agile companies, like Spotify.

Not surprisingly, the reality on the ground is different from what is being promised.

Trying to copy another firm’s model is a terrible way to do organization design (read, for example, this tale).

It is also worth noting that the people who adopted Agile first – IT leaders – now have doubts about the merits of the approach.

In a recent survey of 150 CIOs (Chief Technology Officers), 34% of all Agile projects were considered partial or complete failures. More than half of the CIOs indicated that Agile is a discredited approach (see these slides from a presentation I gave recently).

What is the explanation?

Agile was developed to support flexibility at the team level, and basically prescribes (local) experimentation and informal ways of working as the solution.

An organization is usually not one team, however. An organization consists of multiple teams that each develop and deliver a piece of a larger system.

The teams depend on each other. Or in academic speak, there are interdependencies between them. This is simply not addressed in the agile approach, which only speaks of “the team”.

The implication is that if we want flexibility at the organizational level, we need to ask ourselves how teams (or other sub-units) can best coordinate and integrate their efforts.

What we need is flexibility (e.g., reconfigurability and scalability) at the organizational level, not only at the team level.

This is simply impossible by using pure Agile methods.

You need a certain degree of planning, coordination, and control to do this. You need an “architeture” that describes the overall system that you are developing, and which specifies how the different pieces fit together.

And somebody needs to be responsible for this overall planning and coordination.

In IT firms, this role is called “IT architect”.

This role lost prestige with the introduction of Agile, but it is now being reintroduced in many firms (There’s an excellent article by Martini & Bosch on the functions that IT architects perform and why they are needed. You can find it here.)

So paradoxically, you need to use “un-agile” methods if you want to scale Agility.

For firms that want to increase flexibility, my recommendation would be to use the modular approach as a guide.

Unlike the agile approach, which only considers one level (the team), there are two levels in the modular approach: The architecture (or overall structure), and the modules (or components).

A key point in the modular approach is that the most cost-effective way to achieve flexibility is by combining planning and formal structure (or architecture) with local experimentation (within modules).

The architecture specifies the overall design (of the process, product, or organization), including the interfaces between the modules (or sub-units or components).

By formalizing and “freezing” interfaces for a certain time period, you actually stimulate innovation at the modular level, because the teams and sub-units can now introduce new innovations without forcing other teams and sub-units to make costly changes (this is avoided if one works within the defined interfaces).

In my book I describe how one can use modular principles to design an organizational model. The key is to establish small, semi-independent sub-teams that can be reconfigured according to the circumstances. 

However, I am not saying that we should forget the Agile approach completely. The intention is good and the principles are sensible in most cases.

But you need to modify it quite a bit to make it scale.

Video

I gave talk about this topic at two HR conferences in 2018. One has been posted on YouTube. 

Related posts

Do you have a scalable organizational model?

Three misconceptions about the matrix organization

Acknowledgements: Icons by Daniel Falk, Annette Spithoven and Sharon Showalter from the Noun Project.