Agility is Only for the Small

When we think of agility, we envision speed, easy manoeuvrability, and a relatively small size. Applying these properties to organisational structures translates to organisations making timely decisions, effortlessly adapting to changing circumstances, and having fewer people. If your organisation exceeds 200, I believe it is nearly impossible to achieve agility.

Agility is a property of being small.

Agile has become a buzzword in business, touted as a panacea for all organisational challenges. However, this ignores the essence of agility, which lies in adapting and delighting customers.

Agility can only be a property of smaller, leaner structures where decision-making is close to the action. Bigger organisations, with their layers of hierarchy and the bureaucracy that causes, have slowed down their decision-making ability by becoming too big to talk with each other easily.

Creating Delight

From the manifesto's perspective, agility is largely about delighting the customer. To do so, we must consider how the declared values and principles should impact our businesses.

As with most things in life, when I think of businesses I experience as a customer, I think about coffee. I habitually frequent two coffee shops, and I do so for entirely different reasons: the small coffee shop Crazy Beans, at the end of my street, which responds to my desires, and Costa, which is ubiquitous and of a known standard.

When I speak to my local barista about the kind of coffee I’ve enjoyed elsewhere, she makes recommendations from their menu and modifies the drink I choose to suit my taste.

Costa has a fixed menu, and the baristas are unlikely to know much more about coffee than they’ve been taught through the business.

Costa may satisfy me when passing through a train station and needing some caffeine fast, but they won’t create a memorable experience I want to share with friends on a leisurely Saturday.

Too Large to Interact

We’ve all seen the lines of communication diagrams that vaguely resemble spirograph drawings for children in the 1980s. The lines of communication grow more than the amount of people you add. What does that feel like to experience in real life, though?

Let’s go to a party.

There are ten of us around a dining table at the host’s home, and when it comes time to toast them, we can all cheer each other’s glasses. It’s awkward, and there are some giggles as we reach over one another, but we are quickly successful. This is the self-organising team that is the dream of agilists everywhere.

Now let’s go to a bigger party.

We’ve hired a hall and invited 200 people. When it comes to toasting this time, we know we cannot clink every other glass, so we don’t even try. We may interact with the few around us, but the rest of the room is kept at a distance. These are the teams working in isolation towards a common goal without being able to support each other to reach it.

Eventually, a group becomes too large to enable individuals and interactions over processes and tools. When this happens, an organisation is usually ~200 people, and whatever its endeavour, it has become so big that it prevents it from achieving agility.

Delivering Faster

“Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them” – Fred Brooks, Mythical Man Month.

Software production isn’t like car production. If you add more people to a car production line, the car will likely be built more quickly. Each copy of any given model needs to be built, and it’s only by creating each copy that value for the business is generated and their customers can be delighted.

Software can be copied an infinite number of times with minimal human labour. The design of the product is what adds value to the business and delights its customers because in software development, designing and building software is the same thing.

If you add more people to a software project, you won’t complete it any quicker. You’re more likely to slow it down, perhaps to the point where it can never be finished.

The pervasive idea in project management is that solving problems more quickly can be achieved by adding more people. This is old-fashioned, untrue in knowledge work, and harmful to those who are subjected to it.

Instead, a more effective way of creating valuable software is to have as few teams as possible to develop all the features consecutively. This allows for minimal communication points, maximises the depth of understanding by those designing and building the product, and allows many opportunities for your customers and users to give you feedback about how well you’re fulfilling their needs.

Organisations also gain economic efficiencies. You only need to hire a few people, as once one feature has been delivered, the same team can work on the next one. You can sell your MVP and further delight your customers by increasing the available features over time, potentially at no extra cost to early adopters.

And yet, organisations continue to think that the more teams the better.

Customer Collaboration

My argument here is not that organisations cannot improve. Certainly, many large organisations could become much more adaptable to the changing forces that affect us all. However, becoming a more agile organisation is not the same as being an agile organisation.

To achieve a customised experience, you must understand the customer well and know who amongst those working with you can deliver it. This means seeking feedback from your customer often and having an organisation networked sufficiently to be efficiently utilised so the whole can understand what is needed and how it can be achieved.

Like the difference between toasting with ten or 200 people, the smaller organisation will be more agile when trying to fill a team's skills or knowledge gaps. This means that smaller organisations will understand their customers better and delight them faster. It may be possible for the larger organisation to do the same, but by the time they do, the customer may have lost their competitive advantage.

If a team gets feedback from their customer that the feature they’re building is based on mistaken assumptions, what is involved in correcting them? The agile answer is collaborating with the customer to understand and fix the error. By fixing errors before developing further features, you can avoid compounding the problem.

In Scrum, the team meets the customers at the end of every Sprint to receive feedback and collaborate on the product's future direction. The updated Product Backlog feeds into Sprint Planning about where the most value can be achieved next. A small organisation of networked Scrum teams can change direction as often as every Sprint to maintain the customer’s competitive advantage as it appears at the time.

However, SAFe (favoured by the larger organisation) doesn’t encourage direct communication between the developers and the customers. It employs lean UX techniques, user personas, and empathy mapping as a customer / user proxy for the developers to imagine interacting with. These are great tools to help any team make decisions in the moment, but they are not real beings who can tell us if our assumptions are right or wrong.

If your organisation never considers the customer in its decisions, then the SAFe abstraction of a customer will considerably improve adaptability. However, this isn’t the same as being agile. True agility cannot be achieved unless the communication lines between developer and customer are direct. So again, we see that the smaller organisation with the ability to have direct communication lines is best placed to delight its customers.

Networked Organisations

A large part of organisational agility is the ability to communicate effectively with everyone within an organisation. When one person can easily talk to anyone else, regardless of role or seniority, information can flow smoothly and transparently, allowing for faster and more accurate decision-making.

SAFe attempts to recreate internal networking opportunities that are more natural inside smaller organisations. It has processes and meetings that drive the communicative behaviours larger organisations need to see in employees to achieve more agility. However we may feel about Big Room Planning, it brings together teams in an attempt to help them understand how they fit together as a whole. Something that can be considered an improvement for many large organisations.

There is something to this. Instead of mandating ‘good’ behaviours enforced by self-discipline, SAFe forces behaviour change by creating an environment where desired behaviours are most likely to be exhibited. This is good advice for large or small organisations and a lesson we could all benefit from learning from SAFe.

However, the need to create a process to achieve these ends shows how unnatural it is to be networked in a large organisation. True agility is not something we mandate but rather something we are. It is as difficult to avoid interacting with each other and the customer in a small organisation as having these interactions is in larger organisations. The larger allows plenty of space for people to hide away in corners; the smaller does not.

Its Just Not That Easy

Achieving true agility is as complex as the products we create and the systems we live within. It's easier for smaller organisations, by virtue of their size, to make quick decisions, adapt rapidly to changing circumstances, and maintain closer, more personal interactions with their customers. The heart of agility lies in the ability to delight customers through responsiveness and tailored experiences, which is more likely in a leaner structure where decision-making is close to the action.

Large organisations face significant challenges in achieving agility. The layers of hierarchy and the bureaucratic processes that come with scale are akin to the difficulty of clinking glasses at a large party, where meaningful interactions are limited to those nearby, leaving the broader group and potentially the customer disconnected. As organisations grow, they risk becoming too cumbersome to sustain the intimate, customer-focused interactions that drive true agility.

However, this does not mean large organisations cannot strive for greater adaptability. They can adopt frameworks and methods to improve their responsiveness and adaptiveness. While these methods try to recreate the networking and communication opportunities inherent in smaller organisations, they often fail to achieve the same level of intimacy and direct customer feedback. Nonetheless, they provide structured approaches to help larger organisations move towards a more adaptable structure.

Ultimately, an organisation must consider its growth and scaling strategies to achieve agility and remain agile. The most agile organisations remain self-managing, cited by many as being at most fifteen people. Your organisation may consider growing for many reasons, but be aware that it will likely be at the cost of your agility.