The House of Agile – A visualisation of the core of Agile

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. If you try to scale Agile it’s probably in this part you need to put your effort.

We are now done with the foundation and this is what we have so far.

The strategy – the pillars

With a strong foundation we are ready to put the pillars in place. The pillars represent the strategy, that is, what we try to achieve with our way of working.

Fast feedback

Let’s start with the following principles from the Agile manifesto:
•    ”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”
•    ”Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”
•    ”Simplicity–the art of maximizing the amount of work not done–is essential”
They are all telling us to take small simple steps to quickly have something working which helps getting feedback. It could be something that can be evaluated by a user, a service to be consumed by another system or a “walking skeleton”, the absolute simplest that could be built to verify the architecture.

Be technically and mentally ready to react on new knowledge

Fast feedback gives us new knowledge, which is great but absolutely worthless if we are not able to change according to the new knowledge. Luckily the Agile manifesto has some principles to help us here:
”Continuous attention to technical excellence and good design enhances agility”
That is, we need to have an architecture that supports easy changes.

Just being technically prepared for change is not enough. Changes are hard mentally as well. Actually, most people do not like changes at all. Ever heard complains about scope creep? Things get even worse if a lot of work has been put on setting up a detailed plan. Most people do not like to throw away work they have done.
The manifesto is addressing this with, what I will call, a mental picture; something we continuously need to convince ourselves about.
”Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage”. The mental picture we need to have is that changed requirements are good because it means that the product gets even better than it would have been with the original scope.

The manifesto is also giving us advice when it says: ”Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”. You don’t see the connection? Well, the opposite of “constant pace indefinitely” is time of stress and stressed people are not willing to change very much. To make people become friendlier about changes, making sure they are not stressed is a good start.

There is one more pillar in our house and that’s the pillar “Mobilizing brain power”

Mobilizing brain power
This pillar is the difference between command and control and the Agile culture. Instead of having a few persons thinking we use the brain of everyone in the company or to quote Konosuke Matsushita, the founder of Panasonic. “In an environment increasingly unpredictable, competitive, and fraught with danger, our continued existence depends on the day-to-day mobilization of every ounce of intelligence”.  He said this in the 70’s and I think you agree that the environment today is even more unpredictable and competitive.

Typical things in the manifesto that support mobilization of brain power are:

• “Business people and developers must work together daily throughout the project“
• “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”

When developers get the full picture and understand the business they contribute with their intelligence for the good of the company. Think of it, a whole company with sensors and analysts that quickly will discover what is the right way and react when we are on the wrong way, instead of putting all the risk on a few appointed people.

Now we have a house will a solid foundation and three pillars.

The three pillars “mobilizing brain power”, “fast feedback” and “being technically and mentally able to react on new knowledge” help us get an improvement loop in line with the famous Deming Cycle, also known as PDCA. We plan (P) a short incremental change to our product, we develop (D) it, check (C) the result and act (A) on the new knowledge.

The only thing left is the roof. Just like the House of Lean, our Agile house will have a roof of goals. The problem is that there are no goals given by the manifesto so we have to make them up ourselves. Look at the foundation and the pillars and figure out what the goal will be that are based on the pillars and foundation. In my experience this way of working will give high sustainable value with low risk. The low risk part goes for everyone, I think. The other part, the high sustainable (customer) value comes from my usual goals for software development. If you are striving for something else then your improvements will take you in another direction, a direction towards your goal.

The house of Agile as a tool
I know that most people are uninterested in the content of the Agile manifesto and just want a tool to get some help from.  Don’t worry; the Agile house can be a tool as well. Here come some ways to use it:

The agile house as an improvement tool
Gather your team and draw the three pillars on a white board. Let the team suggest actions to improve their way of working according to each of the pillars. What can we do to get even faster feedback, make changes a little bit easier to do or make even more people understand what we do so they can contribute with the brain power?

The agile house as a control tool
Another way of using the house is when someone comes with the suggestion to do change X. You can then use the house to check if change X is aligned with the Agile way of thinking. Will clearer requirements make us collaborate more with business? Will moving testers into the team increase our feedback loops? Will a central architect help us mobilize more brain power? Will a company-standardized process make continuous improvement easier?

The agile house as an argumentation tool
This can also be a tool for those of you that have not started your Agile journey yet. When top management or someone else claims that Agile can’t be used at your company because of your very special and complex content, you can show the house and ask which parts that do not fit in. So far, I haven’t experienced a company that will not gain by adapting the Agile culture.

The agile house as an educational tool
Agile is a way of thinking, a culture, and cultural changes are the hardest. If you want to change the culture in your company according to Agile, the Agile values and principles need to be understood by the employees. Posting my house or your own house on your walls will help people get a better understanding and eventually change their mind-set.
You can download the house here in English and Swedish. If you like to translate it to your own language you’re welcome to use my original PowerPoint file.

I hope my House of Agile will help you understand the Agile manifesto better and see it as a great guide in your journey to a better way of working. You can also see the house of Agile as a video clip on Crisp academy.

Good luck
/Tomas Björkholm

PS
Many thanks to Yassal Sundman for improving the language in the article.
DS