The 5 foundations needed to master Agile
It’s almost 20 years since the agile manifesto was written, drawing on software engineering methodologies that had been evolving for several decades.
Today, agile is the dominant approach to building software and many engineers have only ever worked in agile approaches. But agile is a practice that is simple to understand and hard to master, which is why we sometimes lose the things that really make it work – the foundations that agile is built on.
As with any building, strong foundations are essential. In this article I will outline what agile is and the five foundations needed to ensure agile delivers what you need.
What is Agile?
Agile can be described in several ways but to me it is about three things:
- Practices – the things you do on a day-to-day basis, including various ceremonies, engineering practices and approaches.
- Frameworks – these tie the practices into a coherent process for software delivery and provide the governance and direction for the agile practices.
- Foundations – these are basics that need to be in place to deliver your plans and strategy.
The agile foundations are made up of:
- Empowered Individuals
- Small, Autonomous Teams
- Incremental Delivery
- Attention to Quality and Reliability
- Continuous Improvement
The first foundation of agile is to empower individuals – giving individuals the authority and autonomy they need to make and implement decisions. Empowering individuals means more people are involved in creating solutions and those who are involved are more engaged.
Part of empowering individuals is ensuring they are supported in their decisions even when they might fail – “psychological safety”. In simple terms, if you are not providing psychological safety then you are not really empowering your people. High levels of empowerment and psychological safety improves employee engagement, increases innovation, makes individuals and teams more resilient, and enhances learning and improvement.
The small team is the primary productive unit in agile and lean operations. By working together, small teams are more creative, better at problem solving, and more resilient.
Research from the Wharton School of Management showed that for complex tasks, the optimal team size was 5-6 people. This size means that every team member has direct communication with every other member, something that doesn’t happen in larger groups. This direct communication encourages trust, transparency, and shared responsibility – the essential elements for collective and collaborative working. To preserve the power of small teams, agile operations are scaled not by making teams larger, but by adding more teams.
The third building block of agile is incremental delivery. Instead of trying to fully design the solution at the start, you need to think of every possible option and contingency to complete the design – or you may end up running over budget and over time. Agile assumes this is impossible for many reasons, including:
- Complexity – completely analysing and designing solutions to complex problems takes as much work as actually building the solution
- Uncertainty – you can never know everything you need to know to design a solution; you must make assumptions, which can be wrong
- Unpredictability – you are designing solutions for the future, and this will change
Instead of designing the solution up front, agile assumes the right approach is to deliver in increments, testing and validating each step as you go, allowing for flexibility and responsiveness. This incremental approach is guided by a bigger picture – a product vision and business objectives.
Attention to Quality and Reliability
W Edwards Demming is widely acknowledged as the father of Total Quality Management and the leading management thinker in the field of quality.
Building on turn of the century production engineers, Demming focused on quality, showing the high costs of poor quality and emphasising that achieving high quality was about creating processes to catch and correct defects early.
In agile, quality is essential to delivering fast. But there’s a twist: the attention to quality doesn’t mean stopping all errors and defects from happening – that’s impossible. Instead, it means to accept that these things will happen and to catch and correct them as early as possible.
One way to sum this up is “zero tolerance, zero blame”. Zero tolerance means any error should be fixed as soon as possible; zero blame means that we accept errors happen and there should be no motivation to hide any problems.
The final foundation is continuous improvement. This is a near-cousin of Emergent Solutions and starts from the same place – much as we don’t know what the right solution will look like, we also don’t necessarily know the best way to make the team and organisation work.
In an agile team, we start with adopting a set of agile practices then we adapt and fine tune them as we learn how to get the best from the team. The key driver to the process of continuous improvement is to create a feedback cycle – such as a retrospective – for the team to review how they work and plan to implement improvements. One essential lesson is that the people best placed to decide how to improve the team is the team itself.
Lessons for Agile
In agile circles, you often hear the phrase, “don’t do agile, be agile”. To be Agile, you need to build your practices on solid foundations – if you get these foundations right, the practices will naturally follow. Trying to make agile work by perfecting stand-ups, refinement, or retrospectives won’t work unless you are building on the right base. Conversely, if you’re struggling with agile, the first place to look is not how closely your teams are following the scrum guide or XP best practices, but are the foundations of agile solid?
A genuinely agile organisation will empower their people – and provide “psychological safety”; they will create small teams and encourage them to collaborate on solving problems. We should pay close attention to quality and reliability: zero tolerance, zero blame. Finally, we need to accept that we don’t have all the answers at the start – solutions will emerge from the process, they will be tested and validated as we go, and our ways of working will improve over time.