What is agile? I’ve been giving this much thought. A company in the early stages of an “Agile transition” often encounters this question one way or another. Often it comes up in the form of resistance.
This partly occurs because companies that “move towards Agile” are coming from a situation where something has to happen because the current way of working is no longer suitable. In other words, the people in the organization are struggling, one way or another. This mostly means that the organization has grown or is shrinking and the processes are no longer suitable, there are more or less business opportunities and the company needs to adapt or product development is either chaotic or grinding to a halt. The additional pressure on people causes chaos and stress. When a company then announces an upcoming change in their way of working, this understandably gives people more stress. What do people do when stress comes up? You try to make the thing that stresses you out, go away. So understandably, people will resist the change. But there is another thing there, and that is uncertainty. You are coming from a known way of working and you have to go into something you don’t know yet. Some are confused because they’ve never ‘done’ Agile yet and the rules aren’t clear. Some people stand up and insist what the rules should be. Chaos ensues, because people disagree vehemently about what Agile should and shouldn’t be. Sooner or later, someone opposes “all that Agile crap”.
Now, as you may have noticed, at the start of this post I wrote “What is agile?”. I didn’t write “What is Agile?”. This is because I think the distinction between agile and Agile will make the difference between resisting the Agile mindset and embracing it.
A structure that moves with purpose
What is agile? This will be horrible to read but I think it’s necessary: agile is an adjective.
Yes, I’m serious. Bear with me. It’s an adjective before it was a name for a methodology. The original word in natural language, before it got hijacked, denotes something that (or someone who) is able to move quickly and easily. It’s a property of something or someone.
1. able to move quickly and easily.
2. relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.
Now, when would you call something agile? I think you can only call something agile when it has the following properties.
- it has structure
- it can move or do something with purpose, thanks to its structure
- it has the ability respond to change to keep pursuing its purpose
You would never call water ‘agile’. Nor would you call a desert or a handful of sand ‘agile’. It moves and flows, yes, but the adjective ‘agile’ is not suitable. A tree, agile? Nope. A piece of metal? A piece of wood… no, bendable or flexible maybe, but agile, no. An acrobat? Certainly. A snake? Certainly. A car? I think so. When discussing this with Joep, he offered another insight: Can a thought be agile? Well.. I gave it some thought and I think a thought is not agile. The thinker is agile. The thoughts that flow from the thinker are a testimony to his/her agility. The thought itself is like water, it flows, but it is the thinker that is agile. The brain, the structure from which the thoughts come forth, is necessary. Do we say that the brain is agile? I don’t think so. The brain is the structure from which the thoughts come forth. The agility is in the thinker, the consciousness from which the thoughts originate.
This brings me to the idea of agility as a property that comes forth from a structure that can move with purpose.
Therefore, I find that Agile, the methodology, has a name that is well chosen for its intent and marketing, but also confuses people. The Agile methodology is not equal to ‘agile’. Its marketing pitch is clever but unclear. It stays vague. But in essence what Agile is, is a promise that if you follow its rules, you will achieve agility. The Agile mindset, manifesto and the specific implementations of Agile, being Scrum, Kanban, SAFe, XP and whatnot, are structures that promise you that you will be able to get a move on.
You can liken it to the adjective ‘fast’. Suppose there was “Fast Methodology”. What would it entail? Well, your goal is to be fast. What do you do to become fast? Or maybe you want to become ‘cheerful’. Suppose there was a ‘Cheerful Methodology’. What would th-at look like? Would it be a booklet telling people to smile more? I doubt it. Don’t buy that book.
I think a methodology to become fast or cheerful would look something like this:
- How fast / cheerful am I now?
- Is anything preventing me from being faster / more cheerful?
- What can I do today to have a chance at being faster / more cheerful tomorrow?
- Additionally, there is a bigger picture goal. You decide if you want to run a marathon or whether you want to join a running group and so you have to pick up the pace enough to be able to join comfortably.
You seek out advice, a YouTube channel, a trainer. You ask for advice. You try out things. You train for it and measure your speed. You keep a diary or log your mood. In short, you don’t become fast / cheerful by expecting yourself to be it. You don’t become agile by proclaiming that that is what you shall be. You figure out how agile you are now, what is preventing you from being more agile, what you need to do today to have a chance at being more agile tomorrow and you get a sense of what it is you want to be able to achieve.
An important thing to realize is what Agile methodology advocates is not a structure you should adhere to or a set of rules you must follow (that’s what Scrum does, not Agile), but the concept that agility comes forth if you have a basic structure but value moving more than staying in formation. Those who wrote the agile manifesto show by the words they chose, whether they realized it consciously or or not, that moving is important, but that structure is still needed. This is why the Agile Manifesto states “That is, while there is value in the items on the right, we value the items on the left more.”. The Agile Manifesto does not throw away the structure. They don’t say “Be agile!”. They know the structure is important in order to be agile. You need processes and tools, comprehensive documentation, contract negotiation and following a plan. And if these processes and tools are adequate, then you can get a serious move on. Because you value people, working code, customer collaboration and responding to change. You value the agility that is brought forth by the structure more than the structure itself.
This is what gets turned on its head by most companies: They want to be agile, and then focus solely on the structure.
Of course you focus on the structure, what else could you do? The structure is the thing you can create, right? The agility is what emerges from it. Yes, that’s true and it’s exactly the difficulty: Emergent properties are very difficult to engineer. (I was a student assistant once for a project in industrial design where the coaches naively instructed their students to design something with an emergent property. Funny stuff.)
You have to have the patience of mother nature: You try something, see if it works and if not, try again. And the truth is: You may never reach that global optimum of perfect agility. It’s not something we get told when we take that agile training or when we scour the web for information about Agile, Scrum and whatnot. It’s often presented as if the prescribed structure is what you must adhere to in order to be capital-A-Agile. This is how you do it. When in truth, the best trainers say: Here are some tools to help you figure out what works in your environment.
A metaphor from nature
The metaphor I’d like to investigate is that of a flock of birds. A flock of birds is, without a doubt, agile. See the way it moves, in unison and yet responding to change. The flock disperses when a hawk dives in the middle. Panic ensues. But eventually, when the hawk has been shaken off (or when it has caught one of the birds and lands to devour it), the structure reforms and the birds continue. The structure is there to ensure a safety in numbers. The birds fly together so that each individual bird’s chance of being picked off by a hawk is as small as it can be. Flying alone is a 1:1 chance dangerous. Flying with hundreds lowers that to 1:100. And so the flock sticks together. Birds have figured out how to make this structure work. They have three basic rules:
- Keep your velocity more or less the average of the velocity at which your neighbors are flying
- Keep your direction more or less the average of the direction your neighbors are flying in
- Try to keep more or less a certain distance from each of your neighbors: Not too far away, not too close together
What you get is ’emergent behavior’. The flock moves as one entity. Agility is one of its emergent properties. But agility was never the purpose. Migrating in safety was the purpose. So what you have is
- the structure as a set of rules (the flock and its rules of velocity, direction and distance)
- a purpose (migration in safety)
- the ability to move with purpose (migrate in safety)
The flock exhibits agile behavior because the rules were optimized to make them as safe as possible. It just so happens that the optimal way to do this is an agile one. You could just as well have looked at a tortoise and its purpose: Be safe. It has a thick shell. Is it agile? Well, it can move, but it isn’t quickly and it isn’t easily. So not every structure and purpose will result in agility. If you impose the wrong structure for your purpose, it won’t be agile. And if your purpose does not require agility, there’s little chance that you will achieve agility: No living thing will expend energy on something it doesn’t need.
Now you could argue that the purpose of the flock of birds was to be agile. After all, they want to move quickly and easily don’t they? I’d respond that certainly, moving quickly and easily is something to be desired if you want to migrate over thousands of kilometres before winter sets in. But the goal wasn’t to move quickly and easily. The goal was to migrate to warmer places before winter sets in. I think you have to keep that separate. Because if your goal is to move quickly and easily, you could also end up flying in circles over the north pole. Agility itself cannot ever be the number one goal. Your number one goal is something that ensures your (or your company’s) survival. Agility may be what you need. Or it may not.
The rules of the flock in companies
Now, the three rules of the flock have constraints. Members have to keep their velocity more or less the average of the velocity of their neighbors. If they suddenly speed up too much or slow down too much, they will find themselves alone pretty quickly. The same holds for direction. Make a 90 degree turn and you’ll be one lonely duck. And lastly distance. You don’t stray and you don’t smash into your fellow ducks. It’ll be a heap of feathers, quacking and trouble if you do that.
It’s no different for companies. The ducks at the front have a big say in the speed and direction of the whole flock. Arguably they have the most power to decide. But there are important differences. In a flock of birds, each bird can check where the other is going with its own eyes. Not so in a company. You have to speak about your intent. You have to share it. Other people can’t see what ideas are floating in your head. You have to tell them. So, like the ducks in front can’t just speed up and change direction at a whim, the leaders in a company can’t just change their mind and fly off. The rule of the flock says you have to do everything gradually. You change direction gradually and you speed up or slow down gradually.
Of course, humans have an extra superpower. We can talk. The ones in front can look over their shoulders and yell “sharp left!!“. It’s possible. But this superpower has its limits and is not without its downsides. First of all, you have to synchronize. It’ll have to be “sharp left coming up, roger?” and then the guys in the back shout “Roger!” or “What? What? I didn’t hear!” and a lot of quacking ensues so that everyone knows a sharp left is coming up. One or two ducks that weren’t paying attention start their nosedive left, falter when they see they’re too early, squawk and join ranks again. Then you can do a countdown “3 – 2 – 1 turn!!!” and on three you can all make something resembling a left turn. It won’t be as pretty and smooth as the usual gradual change, it will break the formation and it’ll take a lot of flapping and muttering and expending of additional energy to get back into the flow again. But it’s possible. Sometimes. The downside is that we have the misconception that because we can talk, we can do this all the time. No. You can’t do this all the time, because you’ll break formation and expend valuable energy every time you do it. Not to mention that most ducks aren’t going to fly very quickly if they know a random turn can come up at any time. The flock will, necessarily, slow down significantly. This is why you can’t change priorities on a whim, not even if you update all the Powerpoint slides in your company and send everyone an e-mail.
Freedom to deviate from the structure
You need structure or you cannot move at all. A structure inherently has constraints. In case of the flock of birds, it’s the three rules of speed, direction and distance. In companies, there’s not much difference: There is a certain speed at which you can execute, a general plan and there are relationships between people that govern their distance and closeness.
Did you notice how in the three rules of the birds, every one had the bit “more or less”? There is some leeway there. You don’t have to move at exactly the average speed, direction and keep exactly a fixed distance. If you’ve ever programmed a simulated flock of birds (I have), you’ll see that taking the exact averages and keeping an exact distance makes your flock not agile at all. They’ll look dead and in no time they’re all moving like bullets, very boring and not alive at all. No, the magic is in that “more or less”. The error margin. It’s what makes the flock swoop and move, it is what makes it so beautiful. The flock can change direction because of this error margin, this freedom. If the ducks up front couldn’t change direction a teeny bit, the flock would never change direction at all. And so some freedom to change direction is built in. As mentioned before, the ducks in front cannot exceed that maximum freedom of movement.
That freedom of movement or error margin is exactly right for those types of birds. Similarly, a swarm of bees changes directions more freely than birds but it’s also more lumpy and moves slower. It’s agile in its own way, but it favors changing direction over high speed. Is it more agile than the birds? Maybe. But then the bees don’t have to fly thousands of kilometres.
This tells us that, depending on the type of animal, these three rules have a different error margin or degree of freedom. Like the three basic rules themselves, the degree of freedom cannot be assigned to the flock from the outside. The degree of freedom is what it is because they’re duck-shaped. The same holds for companies: Your company has a certain degree of freedom because of the nature of the work it does. This is why Agile for Software is different than Agile for Hardware. There are different constraints and so the freedom to change direction is different for software than for hardware. Ignore this at your peril.
Lastly, it also means that if you want an agile company, the individual must have some freedom to deviate from the structure. Individuals must be able to make corrections. In fact, the bulk of the flock can at times be more powerful than the few up front. If they all go left, the ducks in front are no longer leading the way. There can be no other way. If you take away all freedom and impose a rigid structure, you get the example I mentioned earlier, of the computer simulation of bullet-like motion without any of the swooping and beauty. You lose the agility.
I think the three rules of the bird flock are a guide for us humans. And like all threes, you get to tweak only two. If your organization is struggling right now and is trying to become agile in the midst of somewhat of a crisis, I think you need to tweak two rules and leave the third alone:
- Direction: You make sure that the direction is clear and you figure out how much change of direction your company can handle. Lower the amount and intensity of your changes until you find the optimal intensity your organization can handle right now. (Unless a hawk appears.)
- Distance: You make sure everyone knows their place in the organization with respect to everyone else. They need to know how they relate to everyone else. Who is important to me?
Speed is the one you don’t enforce, it is the one you measure. If you have the top two in order, you will at some point find that the speed stabilizes. You will have found the current ideal speed at which your company can produce.
Once the structure is stable enough, you can try to introduce all sorts of ways to improve the direction. Because in the end, that’s all you do in that enormous amount of meetings you have: Someone indicates the direction the flock has to go and it’s discussed at length, so that when the left turn comes, it’s a turn that is made smoothly, without breaking formation.
I’m not saying hawks don’t exist. There’s emergencies and escalations and problems at customers. You can instate all sorts of protocols. But if there is no formation to return to, you may find that you’re flying as if a ghost hawk is constantly in your midst. First get the formation right. Then when chaos ensues, people know what order to return to.