What is Agile, actually? Have you ever asked yourself the question, ”what is Agile”? Ever been asked the question and found yourself looking for the easy answer? The true answer is of course that Agile is the Agile manifesto but do you know anybody who can recite the manifesto just out of his or her head? When asking what is Agle, it’s more likely you will get the answer that Agile is about being flexible or about high efficiency. Some will say Agile is about having a Scrum Master, daily stand-up meetings and notes on a white board. I think Agile is much more than that and in this post I will tell you the answer, the short answer, I have found after many years looking.
Is it important to know what Agile actually is? Yes, of course. If you don’t know, how can you know in which direction to change your way of working when you decide to go Agile. By the way, Agile is a direction how to improve your way of working, not a place or a fixed description of how to work.
To make Agile easy to understand I will borrow a symbol from Lean, the house
Core values – the foundation Let’s go bottom up and start with the foundation. Just as the house of Lean, this is the core values or the culture if you prefer.
Continuous improvement I will continue stealing from Lean so one of the foundation parts will be the continuous improvement or continuous adaptation if you like. It’s the insight that we don’t know everything from the beginning but instead continuously learn new things and that the world is changing. Either we change or we struggle. Agile people prefer to change.
There are usually two things you need to improve; first thing is the product plan. The Agile manifesto phrases it in its 4:th value as ”Responding to change over following a plan”. When all your signals tell you you’re going in the wrong direction, you should change no matter what the plan tells you. The plan is anyway just a guess done when you had less knowledge.
The second thing to improve is the process or way of working. The wish is to always become a little better all the time. The manifesto says: ”At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. ”
Close collaboration, high team autonomy The second foundation part is about autonomous collaboration but to make it easier to understand I prefer to write it as “Close collaboration, high team autonomy”
Not less than three of the four values in the Agile Manifesto talk about collaboration in one or another form. • ”Individuals and interactions over processes and tools” • ”Working software over comprehensive documentation” • ”Customer collaboration over contract negotiation”
Some of you might not think that ”Working software over comprehensive documentation” has anything to do with collaboration but my experience tells me the opposite. The request for more documents is too often a wish to reduce collaboration. Some people have a tendency to hide behind documents and KPIs instead of interacting with people. Showing working software is a great way to make people understand what we are doing. When people understand the goal and the current status it’s easier to collaborate on equal conditions.
To make this foundation part more interesting I will balance the collaboration with autonomy, even though they might be seen as each other’s opposites. In the manifesto this is given as ”The best architectures, requirements, and designs emerge from self-organizing teams”. There is also a hint for autonomous teams in the last principle, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. Without autonomy there is little chance there will be any tuning or adopting at all.
Autonomous collaboration is for me the most interesting part of the Agile house since this is the thing that becomes hard for big corporations.
