Milan Juza, Associate Director, talks about the importance of agile working and how we’re evolving our approach at BGL.
Why is agility important? Several years ago, we started with this simple question, along with ‘what do we expect to achieve?’ and ‘how will it contribute to our business goals?
Whilst these questions may sound self-evident, more often than not, the answers are not as clear as they initially appear. What’s worse, sometimes questions like these are never asked.
Our approach to agility aims to maximise the business value we deliver, whilst improving quality and increasing the pace of delivery. We have a clear view about where we want to be and how agility will help us to get there.
At its highest level, BGL's approach to agility can be described as value-driven
and continuously improving
. These terms may mean different things for different people, so let's explore how we are thinking about this in more detail.
For us, being value-driven starts with understanding what value actually is. There are many ways that value can be measured, including:
- Commercial benefits (e.g. turnover, profit, sales)
- Tech advancements (e.g. increasing pace of delivery, performance, addressing tech debt)
- Better control (e.g. reducing/avoiding risk, improving transparency)
- Regulatory compliance and protecting our customers
- Reputational benefits (e.g. positive customer and market response, increasing engagement)
For everything we do, we always start the process with two fundamental questions: “Why are we doing this?
” and “What will happen if we don’t do this?
” (alternatively “What is the Cost Of Delay
”?) Having these conversations before and throughout delivery is absolutely essentially. It allows for a robust prioritisation, engages the team, avoids waste and challenges our assumptions. Quite simply, we can’t proceed with delivery unless we can answer these questions.
It doesn’t end with prioritisation though. As delivery progresses and new information becomes available, we continue to refine our understanding of what we’re working on and, if needed, will change scope or even abandon the idea if it shows to no longer be as valuable as we initially thought. That way, we don't fall into the sunk cost fallacy
trap, at least not too often! Finally, after delivery, we invite Product Owners to provide teams with thorough feedback, including how the feature or service is performing in the market, whether it meets expectations, and identify any key learnings.
In the same way that no two people are exactly the same, no two teams are the same. Pretending otherwise has resulted in some of the most harmful agile adoptions/transformations in history. At BGL, we recognise that in order to work effectively, we need to understand the context each team operates in, if/how they differ from others and how they’re structured. As such, we give our teams the freedom to choose how they want to work and what specific approach or model works best for them. They can experiment and evolve their practices as they see fit, provided they understand how it fits with the rest of the organisation and delivery process.
Giving teams autonomy and flexibility is empowering and liberating, but not every team works completely differently. Most of our teams follow Scrum and we have aligned key ceremonies, core practices and principles across the organisation to optimise flow of value. Finding the balance between what should be standardised and what’s purely at the discretion of each team is a key focus area. We’re finding that focusing on principles rather than low-level rules is a much more effective way of achieving alignment. Here are a few examples of things we tend to standardise (at least to some extent):
- Core elements of Definition of Ready and Definition of Done – however, each team can add criteria as they see fit
- Macro-level indicative estimation approach, to enable a consistent portfolio-level prioritisation
- Required outputs of inception activities, which enables work to flow from one team to another
- Quality Assurance and Design Assurance standards, to secure consistency and a minimum required standard across all teams
In a nutshell, we recognise that teams work differently, and giving them the freedom to shape how they work results in the best outcome for everyone. Do we always get it right? No. Do we have to course-correct every now and then? Absolutely. But that's what agile working is about – an iterative and incremental improvement in everything we do.
In software delivery, flow is unfortunately a very underappreciated concept. By 'flow', I mean the way in which a given organisation is optimised for a fast, sustainable, repeatable, safe and streamlined delivery of value. It’s one of our key focuses, and it all starts with understanding how we work. The questions we repeatedly ask ourselves are:
- What does the value stream look like?
- What are the lead times and cycle times in each phase?
- How long are the queues?
- Why do these queues exist?
- What is the fastest way we can put something very small to production following the due process?
Exploring these questions in detail for different parts of our organisation enables us to understand: what our flow efficiency
actually is, where the key dependencies are, and where we have waste and unnecessary delays. It also helps us understand where we should standardise a specific practice or approach or where, on the other hand, we need to give teams more freedom and flexibility.
Whilst measuring true business agility is not easy, flow is a great indicator that not only provides a real insight into the maturity and efficiency of the delivery process, but also reflects an organisation’s ability to respond to change quickly.
Last but not least; I left this aspect to the end not because it is less important, but because it underpins all the other things I’ve talked about. Continuously improving and evolving our working practices is absolutely critical component of our overall ethos. We believe that regardless of how things are today, we always have to be open to question and challenge what we do next. In practice, this can be anything from small tweaks to our Definition of Done, to the way we deploy code, to optimisations in our CI pipeline and migration to the Cloud.
Having a continuous improvement mind-set and exercising it in everything we do helps us get a bit better every day. Over time, small improvements make a huge difference to our ability to deliver, collaborate and our productivity. On top of the usual practices like team and release retros, team-level and org-level CI backlogs and regular feedback loops, we’ve also created other opportunities to drive continuous improvement. For example, our annual Refreshers Week in February is a fantastic opportunity for teams to down tools and focus on forward thinking, experimenting with new tech, sharing knowledge and learning from the best in the business. Similarly, our Innovation Day is real celebration of creativity, giving people the time and freedom to create new concepts, experiment, learn and pitch new ideas.
So what's next?
Agility is a journey and ours continues. Every day we learn something new and we’re constantly adapting new knowledge to evolve our approach. As our business is constantly changing (VUCA
is real), it’s important to remember that what's fit for purpose yesterday, may not be fit for purpose today. We aim to stay flexible to new approaches and optimise what we do in line with these changing needs. From an agility perspective, our major focus areas at the moment are: increasing the pace of delivery, increasing CI/CD pipeline automation and robustness, deepening the adoption of TDD, pair programming and mobbing, and addressing key areas of tech debt in line with our overall Technology strategy. We are convinced that evolving in these areas will make a real difference to the way we deliver software, accelerate business growth and deliver first-class online customer experiences.”