Business Agility at BGL
The Why
Adoption of agile ways of working and various agile methods and practices is often seen as a universal good, often without even asking the important question: Why?
Several years ago we started with these question: Why is agility important to us as a business? What do we expect to achieve thanks to agile ways of working? And how exactly do we want it to help us achieve the business goals we are pursuing?
Whilst all that sounds self-evident, more often than not answers to these questions are not as clear as they initially appear or, worse, questions like these are never asked. Our approach is chiefly driven by the aim to maximise the amount of business value we can deliver at any given time, continuously improving the quality of what we do and increasing pace of delivery and empowering teams. We have a clear view about where we want to be and how agility will help us to get there. This aim of this post is to give a high level overview of how we are thinking about agility in BGL and what our approach looks like.
The How
At the highest level, BGL’s approach to agility can be described as value-driven, context-sensitive, flow-focused 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.
Value-driven
For us, being value-driven starts with understanding what value actually is. Naturally, there are many ways how value can be expressed. Some examples may include:
- Commercial benefits e.g. turnover, profit, sales etc.
- Technology benefits — e.g. increasing performance, robustness, resilience, increasing pace of delivery, addressing technical debt etc.
- Control benefits — e.g. reducing/avoiding risk, improving transparency etc.
- Regulatory benefits — e.g. remaining compliant with the relevant regulation, protecting customers etc.
- Reputation benefits — e.g. generating positive customer/market response and engagement
Some of these can (and should) be quantified and expressed quite accurately. Other types of value are much harder to translate into reliable numbers and for those we need a different mechanism. We will talk about how to do some of it in a different post.
For everything we do, we always ask at least two questions: “Why are we doing this?” and “What will happen if we don’t do this?” (alternatively “What is the Cost Of Delay”?) Having the right conversations about this before and throughout delivery is absolutely essential. It focuses the mind on what really matters, avoids waste and challenges any assumptions we may be taking. In the end, it is quite simple — unless we can answer these questions, we cannot responsibly proceed with delivery.
With all this in mind, our approach starts with Product Owners (commercial or technical) who need to able to articulate answers to the “Why” questions and bring in as much detail/precision as possible. This enables a robust data-enabled prioritisation (more on this in a separate post later) and gives us confidence that we always work on the most valuable things possible. This in turn means teams are much more engaged and bought into what they are doing.
It does not end with prioritisation though. As delivery progresses and we understand more, we continue to refine our understanding of the potential value of what we are working on (based on new information as it becomes available) and, if needed, change scope or even abandon the idea if it turns out that is no longer 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 come back and give teams visibility of how the given feature or service is performing in the market, whether it meets our expectations and what new knowledge or insight do we need to take into account in the future. That way, we have established a proper commercial feedback loop back to teams and into the prioritisation process itself.
Context-sensitive
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 what context each team operates in, if/how what they do differs from other teams and how they are structured. With that in mind, we are giving teams freedom to choose how they want to work and what specific approach or model works best for them. It means they are free to experiment and evolve their practices as they see fit provided that they understand how what they do fits with the rest of the organisation and delivery process.
Giving teams autonomy and flexibility is very empowering and liberating, but it does not mean that 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 (more on this in the next section). Finding the balance between what should be “standardised” and what is purely at the discretion of each team is indeed one of the key focus areas for us. We are finding that focusing on principles rather than low-level rules is a much more effective way of achieving alignment.
To bring this to life a bit, 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 additional criteria as they see fit)
- Macro-level indicative estimation approach — to enable a consistent portfolio-level prioritisation
- Required outputs of inception activities — to enable work to flow from one team to another when needed
- Quality Assurance and Design Assurance standards — to secure consistency and a minimum required standard across all teams
In a nutshell, we believe that recognising different contexts in which teams operate and giving people freedom to shape how they work results 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.
Flow-focused
In SW 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. For us, flow is one of the key focus areas for all teams and management alike. 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 (within teams or between teams), 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. And whilst measuring true business agility meaningfully is not easy (will talk about how we do it at BGL in another post), flow is a the great indicator that not only provides a real insight in the maturity and efficiency of the delivery process but also reflects our organisation’s ability to respond to change quickly.
Continuously improving
I left this aspect to the end, but not because it is less important, but because it underpins all the other things I talked about in this post. Continuously improving and evolving our working practices is absolutely critical component of our overall ethos. We believe that regardless of how things are today or what we may have done in the past, we always have to be open to question and challenge what we do and how we do it. 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 mindset 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, the quality of our collaboration 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 also created other opportunities to further assist with continuous improvement. For example, our annual ‘Refreshers week’ in February is a fantastic opportunity for teams to down tools and spend the whole week learning new things, experimenting with new tech, sharing knowledge and learn from the best in the business. Similarly, our Innovation day is real celebration of creativity and ideas and give people freedom to spend time to create new things, experiment, learn and pitch ideas.
So what’s next?
Agility is a journey and ours continues. Every day we learn something new and we are doing our best to use any new knowledge to evolve our approach. And given that our business is also changing (VUCA is real) what was fit for purpose yesterday, may not be fit for purpose tomorrow. With that in mind, we are trying to stay flexible and optimise what we do in line with these changing needs. From agility perspective, our major focus areas at the moment are the pace of delivery (increasing frequency of production deployments), increasing CI/CD pipeline automation and robustness, deepening adoption of TDD, pair programming and mobbing and also addressing key areas of tech debt in line with our overall Technology strategy. We are convinced that “moving the needle” in these areas will make a real difference to the way how we deliver software and thus help us further accelerate the growth our business.
