There is no shortage of opportunity. There is only a shortage of those who will apply themselves to the basics that success requires. ~ Jim Rohn
The basics of agility.
It’s been a long and hard journey to write this book. I know every author says the same thing. I have had the additional challenge that the body of knowledge that we have about organisational change is growing so quickly it has been difficult to keep up and not have to rewrite the book every couple of months.
This rapid pace of change in our organisations is mirrored both in the macro; in societal change, and in the micro; in my own self-development.
The ways in which people release books has also changed during this time. From primarily publishers, to self-published, to incremental chapter releases as blog posts or short articles. Even the tools for writing have evolved, with downloadable grammar and mood checkers, dictation services, advanced spelling checks, etc.
Writing this book has been a bit like product development in a complex environment.
Luckily, we have a solution for that…
Agility
My definition of agility is this:
It is a belief system that allows teams of people to collaborate effectively to innovate and deliver stakeholder-focused solutions in complex environments at lower risk using short increments, whilst maintaining consistent quality in a sustainable and exciting way.
You will notice there is nothing in that definition about how this is done. The definition does NOT state a set of tools and practices…. Although there are tools and practices associated with enabling agility to work.
The best way to demonstrate is with the Agile Onion model.
Diagram: Adventures with Agile
The Agile Onion
If you were thinking Agile is a set of different methodologies for getting software built, then you are only very partially correct. That viewpoint fits well into a subset of the ‘practices’ part of the onion. But Agile is a whole lot more than that.
The larger the onion circle, the more powerful but less obvious it is.
We always start improving businesses from the outside in. The mindset first.
The Onion is a Venn diagram and must not altered to have tools etc on the outside! This has been a common misconception of the onion with agilists who first think it is the wrong way around. Start with the mindset and work inwards!
TIP: Never start with Tools and Processes because you will soon hit a brick wall and become frustrated.
Tools
For example, ‘Tools’ in the middle are really easy to see. You can see big boards with post-its or Jira instances easily. But on their own, they are pretty useless.
Practices
The ‘practices’ include:
- Scrum
- Kanban
- XP
- Story writing and mapping
- Prioritising
- Roadmap creation
- Beyond budgeting
- agile HR practices
- and a whole host of other things.
These practices are really easy to understand, are really hard to make stick and get any real value out them. Ever see a Scrum team doing all the meetings, using Jira, and trying really hard and not getting any value out? Chances are the team, or the organisation is missing the more important circles of the onion.
Principles
‘Principles’ are things like, ‘we complete all the work we start in a sprint’, or ‘our highest priority is to produce working and useful software every 2 weeks’. Having these allow the team and organisation to optimise around their principles, cutting away crazy decisions like having a silo database team.
Without principles, the team will optimise around other things, such as:
- Keeping people busy
- Bowing to pressure from other sources than the PO
- Not shaping work correctly
Values
‘Values’ are even more important and even more intangible. We know from ‘5 Dysfunctions of a Team’ by Patrick Lencioni that the first starting block for any high performing team is trust. If trust isn’t encouraged through respect, courage to speak out, openness and honesty, which are all values, then high performance is going to be a distant concept, perhaps bringing up images of Formula One teams rather than teams at work.
Different frameworks provide the values that they were created from. As the team creates its own way, having a clearly defined set of values is vital in making decision making. This is often coded into a team’s ‘Way of working’ or Alliance document. We recommend every team creates an alliance. You can use the Team Genesis workshop to kickstart high performing teams.
Mindset
“Reality is that which, when you stop believing in it, doesn’t go away.”
― Philip K. Dick,
Before I defined the Agile Mindset, the Agile industry mostly used pictures of Yoda or other spiritual representations of what it meant to embody the agile ways of working. It seemed to be a mythical abstract quality that was hard to define and was often glossed over in agile discussions.
Working with senior leadership; pictures of Yoda don’t go down well.
The onion model tells us the mindset is the most powerful layer that makes up agile. It is where ‘being agile’ comes from, rather than ‘doing agile’, which is the domain of the inner rings of the onion. But what does this really mean?
The mindset is defined by just three beliefs:
- The complexity belief
- The people belief
- The proactive belief
There are no more, just these three things. Many people have tried to add a fourth, but really it is just these three.
The complexity belief
Many of the challenges we face are complex adaptive problems, meaning that by trying to solve these problems we change the nature of the problem itself.
An attribute of complex adaptive problems is that the end solution is not predictable at the outset.
The people belief
Individuals are both independent from and dependent on their teams and organisations. Human beings are interdependent.
Given the right environment (safety, respect, diversity and inclusion) and a motivating purpose, it is possible for trust and self-organisation to arise.
For this to happen, it is necessary to treat everyone with unconditional positive regard.
The proactive belief
Proactivity in the relentless pursuit of improvement.
Explanation of complexity
Cynefin, created by Dave Snowden, is a useful sensemaking model to determine what solutions we should use depending on the type of problem we are facing. There is a lot to this model, I am only going to cover the basics to set the context for agility.
We will only look at two different domains of problem: Complicated and Complex.
Complicated problems
Complicated problems have predictable solutions. This means that is we do the same thing twice we will get the same result. The most efficient way of solving complicated problems is to hire specialists (domain experts) to derive a solution.
Complicated solutions can be known in advance through planning and analysis, and the result can be predicted with reasonable accuracy at the outset. Solving large problems of this nature is achieved efficiently by grouping specialists together to optimise for expert knowledge and consistency.
An example of a problem in the Complicated domain is building a house. The house can be planned up front, the environment analysed, materials purchased, built, and tested, with the end result hardly deviating from the original plans.
Complex problems
Simplicities are enormously complex. Consider the sentence “I love you”.― Richard O. Moore
If a problem sits in the Complex domain, the solution cannot be predicted in advance because the act of solving the problem changes the problem itself. Other factors such as volatility, uncertainty, ambiguity, and an increasing rate of change, play a critical part in defining the challenge of solving problems in the Complex domain.
An example of a problem in the Complex domain is innovative product design, where feedback and market reaction from initial model releases drive the features of later product models.
Another example is product development such as the automotive, pharmaceutical, and chemical industries where complexity is increasing and the time to deliver to customer and lifetime of the product is getting shorter. This makes it very hard to stay profitable.
Building software products is another example that nearly always falls into the Complex domain.
If aspects of the problem you are trying to solve are ambiguous, the situation changes rapidly, or there is a degree of uncertainty that makes risk management very hard or impossible, your organisation is trying to solve problems in the Complex domain.
Trying to solve problems in the complex domain with techniques such as analyse, plan, execute and test don’t work. Often organisations that do try to solve problems using this approach reach burn out through stress and become only focused on a never-ending cycle of output and efficiency metrics rather than outcome and strategy.
Agile is for solving problems in the Complex domain. This book gives you practical steps to reorganise your mind, your teams, and your organisation to solve problems in the Complex domain.
Explanation of the people belief
Michael Sahota gives us one view that the agile manifesto can be simplified to people over process. The people belief enables us to make decisions that optimise our behaviour to succeed in solving complex adaptive problems with lots of people.
The premise of the Agile Manifesto and of this book is that if you get the right mindset and create the right environment, then staff can organise themselves to create the right process.
Achieving the right mindset takes deep inner work and often one has to face that one’s current patterns of behaviour are no longer achieving the results we once enjoyed, and then look to see what works in the new world we find ourselves in.
Understanding and putting people first is absolutely vital when solving complex problems. It is not a ‘nice to have’.
I worked with one executive who wasn’t sure why we were spending so much time on ‘the fluffy stuff’. This is an example of an ‘expert mindset’ or complicated problem solver mindset that still sees us as individuals filling a function in a great machine and if we just turn up professionally and get out jobs done then it will all work out ok.
It shows how easy it is to get off from ourselves and think that professionalism is stoic and cold. Being half a person doesn’t cut it anymore in today’s workplace. We need to see ourselves and our relationships differently.
The identity shift that must take place in order for agility to work is from Independence to Interdependence. We have to stop seeing the parts of the organisation in isolation and see it instead as a complex living organism or system.
At the heart of any successful relationship is the belief that we are equal. Being equal is often seen as a surface or external attribute, however, I mean truly equal. Equal in the sense that we feel a deep connection, respect, empathy, and yes, even a type of love, for our team, the people we spend most of our waking lives with.
Notice being equal doesn’t mean being the same.
Diversity is required, welcomed, and actually needed when figuring out what to do next. For complexity is the domain of multiple right answers. Getting as many versions of the truth as possible and cocreating a shared view, is the best way to have a more complete and better view in which to ‘sense make’ and move forwards.
The proactive belief
Proactivity in the relentless pursuit of improvement.
Complex problems change as we interact with them. It is necessary to learn as much as we can and as often as we can, so that we are able to determine how the problem has changed and what we need to do next.
This process is built into the various Agile frameworks and is encapsulated in the empirical process; however, it is surprising how many product teams do not collect feedback to determine if their output created the right outcome.
To deliver success there needs to be a pro-active effort to collect feedback on what works and what does not, both with the deliverable and the process which delivers it.
The key point here, is that you must improve the process you are using as well as the product. This means agile and lean processes are dynamic in their nature. The Cynefin framework defines these processes as emergent. That is that the process emerges as you learn more. You can’t emerge a process without solid understanding of process design and the underlying understanding of people and how they change.
You need people who have the agile mindset at all levels of the continuous process creation especially at the leadership level otherwise the decisions made to change the process will revert back to the status quo.
Processes and structure follow the mindsets that created them.
Putting it all together
These three beliefs define the agile mindset. If you understand the true nature of the problems you are trying to solve, engage people in the right way, and proactively and iteratively work towards the outcome you need; you have the agile mindset and a fighting chance of success!
From this mindset you can derive all the agile values, principles, practices, and tools in the agile onion.
Notes on this chapter
Much of this chapter has been published as individual blog posts although the text here has been significantly updated. This chapter is the fundamentals of agility.