The term ‘agile’ is a bit of a buzzword these days, something for companies to claim to be, but the majority of those ‘Agile’ companies have adopted practices from elsewhere and hoped that this transforms their company into delivering work faster.
Being agile isn’t about adhering to some form of framework but about understanding how the team delivers value and empowering the team to make improvements.
The ‘Manifesto for Agile Software Development’ covers this intent in it’s four points:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In working practice this usually takes the form of:
- Setting up a system to get feedback on the value the team is delivering
- Using the feedback to reflect on the way the team works and having the team own the improvement process
- As the team makes improvements to the process the value the team is delivering goes up
- Constantly gathering feedback, reflecting, collaborating, improving and delivering value (also called continuous improvement)
This is in stark contrast to the waterfall model where feedback is received at the end of a lengthy development cycle and because of how long it takes there’s no way the team can make meaningful changes quick enough to increase the value they deliver.
The first step — here’s one I built earlier
To start your journey towards agility it’s easiest to look at existing frameworks but it’s important to not lose sight of the end-goal of increasing the value of the work the team delivers.
The two most common choices of framework when starting out are:
- Scrum — This approach timeboxes the iterations of work and uses a set of ceremonies to build the feedback, reflection and improvement process into the iteration
- Kanban — This approach tracks work items from the backlog until it’s released in order to help visualise bottlenecks in your processes. While there’s no defined cadence for ceremonies, teams will often create one in order to reflect on feedback and improve the process to remove the bottlenecks
It’s very easy with a framework like Scrum to make assumptions that, as a team, they have a high velocity and that they are also delivering a lot of value but it’s very possible for a team to deliver low-value work, very quickly.
When introducing an agile approach it’s better to focus on the amount of learning the team is doing, as this metric allows you to see how the team is responding to the change in way of working and also aids collaboration between team members.
As the team better understands the agile approach and the work they are doing, the learning normally becomes more focused on tackling problems to do with the processes and the agile framework itself.
The second step — Creating your own
As the team gets more familiar with working in an agile manner and learns more about the domain and the way they work then it’s likely the initial framework will be a subject of improvement.
This is expected and the agile manifesto’s point — ‘Individuals and interactions over processes and tools’ — reflects this.
In larger companies it can be quite hard to empower the team to make radical changes to the framework they’re working within as it can be prescribed by someone many times up the management chain.
In these cases it’s important to look at the value the prescribed framework is providing that person to see if you can meet that while also meeting the team’s needs.
If the value is consistently reporting across teams then as long as the new framework gives them these reports there shouldn’t be a problem with making changes to the way the team works.
If the value is enabling mobility between teams then this is a little trickier but it might be worth exploring and defining a common core set of principles that teams need to adhere to, but giving the teams remit to make changes elsewhere.
When the team is creating their own framework to work within it’s important to ensure that they don’t completely drop the continuous improvement cycle as this means they will no longer have a means of adapting to changes that come up, reflected in the Agile Manifesto as — Responding to change over following a plan.
The third step — Spreading the word
With the team working in their new framework it’s common that they’ll want to share their experiences and suggest other teams adopt their ways of working.
This is great as it means that other teams will start the process of continuous improvement but it’s important to remember that each team has their own challenges so prescribing a solution that worked for one team doesn’t mean another team can take that and immediately become agile.
When selling agile to other teams it’s better to start with explaining the guiding principles and the patterns that allow the team to unlock the most value (continuous improvement is one of these patterns) and then suggesting the team follow the three steps your team did.
This allows those teams to understand what makes agility desirable, gives them a place to start but also explains that the first step isn’t the only step in their transformation to becoming agile.
The fourth step — Further learning
As you continue your journey towards understanding how to deliver more value you’ll learn about other related topics such as Lean, the no-estimates movement, the five Ss and value-stream mapping.
Much like the approach that the team took with adopting agile there will be a number of steps you’ll take before you’ve unlocked the value these tools and approaches can provide but it’s important to remember the journey you took and not assume that things will change immediately.
Summary
Moving towards agility is a multi-stage process and not something that happens overnight. It requires time for a team to understand the value working in an agile way brings and how best to work towards improving their ways of working to deliver more value.
While most Agile frameworks will sell themselves on almost immediate results you should view these frameworks as tools for making the transition to agility easier and not be afraid to mould them to meet the needs of the team.
Once the team has matured it’s use of the agile approach you should look to share your experiences with others as this in-itself is a form of reflecting on your own experiences and you may learn of new approaches and tools from your peers.
@AvermentDigital on Twitter, Facebook and Instagram