Strategy Leadership Summit – Accelerating Digital Leadership
It was an exciting day at this year’s MarketsandMarkets™ Strategy Leadership Virtual Summit! Somo went along as a leading partner.Read more
Scaled agile has become a hot topic in recent years. Companies that have adopted agile are witnessing the benefits that it brings, and have started to ask how those benefits can be scaled as the organization grows. But scaling agile processes and practices is hard. Aligning, co-ordinating, and integrating multiple teams is complex. When thinking about what I’d learnt from working on these initiatives with Somo and its clients, I started to draw parallels between building a digital product with a product mindset and implementing agile at scale.
You wouldn’t (or shouldn’t) start building a new product or feature without understanding the landscape in which you’re operating and speaking to your users first. The same applies when you’re looking to implement agile at scale. Conducting research to better understand the organization and speaking to colleagues at all levels of the organization will help identify and frame the problems that you’re looking to solve.
From an organizational perspective, understanding the business objectives allows you to organize your agile teams around strategic goals and value streams, while gaining insight into the business’s agile maturity will help you gauge how receptive it is likely going to be to change. This is crucial for determining the pace of change.
Users, in this case team members across the organization, will provide valuable feedback into what they feel is working within the current set-up and where there are areas for improvement. For example, as the number of teams within the program increases you might find that team members are struggling with communication and transparency, or that there are differences in ways of working which is making it hard for teams to collaborate. Understanding your team members' challenges enables you to focus on solving the right problems.
A product vision describes the core of a product. It articulates the target customer, their needs and opportunities, and the benefits your solution will deliver for them. It also provides team members with the bigger picture of what they are working on and why. When thinking about scaling your agile processes, setting a clear vision is imperative to ensure the organization (at all levels) has awareness and understanding about what you’re trying to achieve and for whom. The vision should be compelling, inspiring, and empowering.
Once the vision for what you want to achieve from implementing scaled agile has been established, it’s time to develop objectives. Your objectives can be broad, from ensuring team members have a greater understanding of the business strategy and are clear on their goals and the value of their work, to improving Sprint throughput and reducing the number of unexpected risks / blockers.
Objectives and Key Results (OKRs) is a goal-setting framework used a lot when developing digital products, and it can be used here to help you articulate what success looks like and how you’re going to measure it. An example of what an OKR might look like in this instance can be seen below:
Objective: Improve the communication and transparency between teams.
Key Result 1: Reduce the number of unexpected blockers between teams by 10%.
Key Result 2: Increase the % of committed vs. completed tickets per Sprint by 15%.
There will undoubtedly be pressure from management to see the progress you are making. Having clear and well defined OKRs is an effective way for you to communicate the impact of your efforts.
Implementing agile at scale takes time and effort, especially if you’re planning to follow one of the more robust frameworks like SAFe. The same is true when building a new product, which is why the concept of a minimum viable product (MVP) has become so popular. An MVP focuses on introducing something of value, as soon as possible, and with the least amount of effort and expense.
We can take the same approach when implementing scaled agile. An MVP in this instance could be introducing a change to address just one of your objectives. For example, if there is a challenge with communication between teams, and an objective has been set accordingly to improve this, your MVP could be introducing a Scrum of Scrums. A Scrum of Scrums is defined by Atlassian as “a scaled agile technique that offers a way to connect multiple teams who need to work together to deliver complex solutions. It helps teams develop and deliver complex products through transparency, inspection, and adaptation, at scale.” While it might seem like a straightforward change, a frequent touchpoint between teams is a great way of being able to provide updates and highlight risks, blockers, and interdependencies.
It’s better to focus on delivering value in one area, rather than attempting too much and delivering no value. If this happens, you’ll immediately alienate the team and lose support for what you’re trying to achieve.
Understanding how users respond to a new product or feature is crucial in determining how to react. The feedback loop with customers helps an organization collect information that informs any necessary changes it needs to make to improve the product offering. Implementing agile at scale is no different. It requires regular check-ins with team members to solicit the feedback required to validate the decisions being made and determine areas for improvement.
You can solicit feedback in a number of ways. One approach that has worked well for us during our work with Audi of America and Audi Canada is distributing a survey to all members across the program on a quarterly basis. The insight we have gained from these surveys has been instrumental in driving changes to the way in which we operate. We’ve also held interviews and conducted retrospectives with a select number of team members to allow us to dive deeper into what worked and what didn’t. These are by no means the only methods for soliciting feedback. Consider what the right approach is for your organization, keeping in mind the goal of being able to validate the changes you’ve introduced.
The best digital products are those that rapidly iterate, continually improving customer experience in doing so. You should adopt the same mindset here. Implementing agile at scale is a journey not a destination, it should always be evolving. Once you have synthesized the feedback from team members, combine that with your own observations to highlight the key areas for improvement. Don’t try and change everything at once, pick an area that you believe is going to drive the most value and ideate potential solutions.
One area that we iterate a lot on when implementing agile at scale is the quarterly planning sessions. The changes we make here vary depending on what the client’s objectives are, but typically involve adapting either the format or outputs. From a format perspective, this could mean spending more time up front hearing the vision and business strategy or providing more time for teams to meet with other teams to discuss interdependencies and risks. In terms of outputs, this could involve adjusting the number of Sprints that we ask teams to plan for (i.e. create objectives for the quarter, but detailed JIRA tickets are only required for the first 3 Sprints).
When deciding what changes you want to implement, using the Value vs. Effort framework that is common in product management is a great way to help you prioritize. Value reflects the business value that you expect to bring to the organization and Effort measures the time, resources, and cost needed. Conducting this exercise will help you understand which improvements will provide a lot of value and can be quickly implemented (Quick Wins), versus those that do not provide much value and require a lot of effort (Time Sinks).
It’s important to remember that not all of the changes that you implement will deliver immediate returns, particularly during the first few cycles. You might need to iterate several times before landing on a solution that provides the outcome you desire. Don’t be (too) alarmed if you see a metric go backwards before it goes forward. Use it as an opportunity to learn and evolve.
Arguably, the most important part of product management is continually measuring the progress that is being made towards the vision and objectives. Are the new features you introduced delivering customer and business value? While the process of implementing agile at scale is different to building a digital product, tracking your progress towards the objectives outlined at the outset is just as important.
Refer back to the OKRs you established to determine your progress towards those goals. Ask yourself if the changes that you’re making are working and if you are on track to meet your key results, and therefore, your overall objectives. Be prepared to challenge yourself on whether the OKRs created initially are still relevant. Change is inevitable, and that might require you to refine your OKRs to reflect the new learnings that you have gained.
Stakeholders across the organization will expect you to be able to demonstrate and communicate the impact of your changes. Combining the quantitative data from this step in the process with the qualitative data collected from team members will strengthen your presentation and enable you to defend your decisions (if needed). The goal from this stage is being able to show demonstrable progress towards your objectives so you continue to be given the time and space to learn and iterate.
Last, but by no means least, don’t forget to share your success. Sharing should involve team members, management, and other departments within the organization. Broadcast the progress that you’re making so that it builds momentum behind your initiative and keeps people engaged and excited. Sharing your success can be done in a variety of ways, including business updates, newsletters, and team meetings. You might also want to consider some form of external communication, be that a blog post, webinar, or speaking at a conference/event. Getting your message into the public domain helps inform people’s perception of your company and attracts new talent to the organization.
With all that done, it’s time to go again. Just as digital products are never finished and require a constant cycle of Build-Measure-Learn to ensure they continue to provide value, the same approach has to be taken when implementing agile at scale. The needs of your organization and teams will evolve over time, so make sure your process is evolving too. Implementing agile at scale is hard; there is no silver bullet that will provide an immediate and permanent solution to your challenges. However, following the stages outlined here will mean that the change is implemented thoughtfully and in a manner that ensures there is an ongoing focus on making improvements towards your established vision and objectives.