If Agile has matured and secured such a prevalent spot in the business and IT world, why are there still such extreme cases of success and failure? How can we use Agile to turn failing programmes around and reach new heights in our companies? In the first of our two-part series, we looked at three catalysts to help get your Agile programme back on track: culture, leadership, and planning.
In this second post, we’re exploring three more:
- Agile ways of working
- Product thinking
- Measurement and transparency
Catalyst four: Agile ways of working
There’s a big difference between adopting Agile frameworks and truly embodying Agile in day-to-day actions. Unfortunately, we’ve found that many organisations embrace Agile’s formal structures and roles (e.g., Scrum teams and Product Owners) yet fail to change underlying mindsets. The result looks a lot like the organisational incarnation of that old idiom, “putting lipstick on a pig.” You may assign employees new labels and frameworks, but underneath, little has changed. The cultural shadows and constraints that direct how we behave have stayed the same.
This challenge is far too common in many organisations. One of our clients put an extensive "Agile" programme in place to deliver a complex new software product. However, the underlying organisational mentalities remained the same. Management did not trust or empower employees with autonomy, and as a result, a culture of mistrust prevailed. The result? Software delivery lagged. Product quality was poor because of how teams were working. Teams were merely opaque islands with little sense of community or shared goals, causing concern among leadership. Each team felt that it had to defend itself from attack and recrimination from leadership (see part one of this series for some techniques to shift leadership mindsets). To change the dynamic, we helped teams overcome these hurdles and foster authentic agility. How?
- We instituted a regular “team health check” for the software delivery teams. These assessments identified areas for improvement and were considered essential in each Sprint. This approach helped make continuous improvement a regular practice.
- We realigned the delivery teams' structure, embedding experience and cross-functional skills (build and test) within newer teams. We also eliminated handoffs, ensuring that employees had the necessary support to deliver robust, complete pieces of functionality. As a result, the programme delivered working functionality much more quickly.
- We reduced work-in-progress dramatically, lessening waste and improving productivity.
- We tightened up the client’s definitions of “Done” and “Ready.” This adjustment helped foster buy-in for agreed, transparent standards in every story. As a result, teams and leadership more readily agreed on the best ways to measure success, and leaders empowered teams to make the necessary decisions to progress against programme goals.
These changes had a dramatic impact. Very quickly, we saw team velocity (rate of story completion) increase almost six-fold, enabling us to hit previously impossible release dates and milestones. Work was also higher quality. Our defect ratio plummeted from an initial rate of 1.3 defects per story to a rate of 0.11 defects as we progressed through our releases.
Catalyst five: Product thinking
Product thinking is all about organising around value and outcomes rather than projects and processes. It’s about first taking a holistic, long-term look at the value you want to deliver. Then, you design an environment, teams, and processes that support continuous value delivery. Sounds easy enough, right? In reality, product thinking can be a challenge when you’re up against entrenched, traditional departmental mindsets and single-year or project-based investment models.
You can begin to find the answer by equipping your Product Managers and Owners with the right blend of skills. It’s a delicate balance. They need to be business-aware enough to prioritise value and create roadmaps, but they also need to be savvy enough to understand the implications of their decisions. They must be adept at casting a vision and motivating their teams. All the while, assertiveness to manage and challenge stakeholders is vital. We like to call this blend of skills the "T-Shaped Product Manager": they have strength in their technical or business specialty, but they also bring the breadth of experience and people skills necessary to transform knowledge into lasting change.
We’ve found that effective Product Management is both taught and caught. In other words, people need formal training, but they also need to learn on the job with hands-on instruction from solid role models and coaches. We know one business that had this problem. Its Product Managers were relatively inexperienced and lacked adequate skills in prioritisation and planning. As a result, they seemed more like gatekeepers than value champions. They lost the bigger product vision, missed release goals, and drove teams to increase pace (outputs) instead of value and quality (outcomes).
With a few steps, we helped the business overcome these challenges:
- We helped the company articulate the principles that would guide prioritisation, oriented around the customer, and value creation; these tenets helped ensure a laser focus on delivery.
- We helped instil more effective approaches to planning and restructured teams to align around value rather than function (which we talked about in part one of this series). Now, plans and backlogs are well-defined, and there's clarity around ownership.
- We realigned building and testing to minimise delivery risk, deliver value to users, and accelerate feedback loops. These changes fostered whole-product thinking and accountability rather than functional and coding delivery.
Starting from a place of little-to-no value, we delivered two major and two minor releases in six months. Over time, we helped mature the programme to a point where it permitted weekly releases to Production and into the hands of users. No product within the organisation had achieved this milestone before.
Catalyst six: Measurement and transparency
Agile has spawned countless visualisation and reporting techniques. Information radiators and Kanban boards can be valuable tools to ensure work is visible and easily monitored. However, teams often measure the wrong things. For example, velocity tells you how much work a team is consuming, but on its own, it’s quite meaningless. When cars set land-speed records at Bonneville on the Utah Salt Flats, they may be travelling extremely fast, but they’re not going anywhere useful!
It can be like that with Agile teams, too. Unless the team's velocity contributes to meaningful value delivery, it is merely proof that you have a working engine. Whether you’re going anywhere useful is a different matter entirely. We’ve seen this reality with our clients. One organisation bandied about burndown charts and velocities, but the teams had not delivered a single line of working code into a customer's hands. The programme suffered from one broken promise after the next. As a result, management distrusted everything the teams reported. Confidence sunk to abysmal levels.
A few core actions helped overcome the mistrust:
- With consistent dashboards that showed progress toward end-user value, we created transparency across teams. Using measures such as the number of stories in Production and the number of users migrated and active in the system, we focused everyone’s attention on the main goal: putting functioning software in users' hands. These dashboards became the backbone of Scrum of Scrums sessions. They drove a focus on the proper discussions with Scrum Masters, Delivery Leads, and Programme Leadership.
- We helped instil Agile planning practices that were more rigorous and accurate than traditional long-term forecasting. We grounded our approach in the principle that plans are merely estimates and can change easily. We also allayed leadership fears by demonstrating greater rigour and reliability in short-term planning.
- To foster greater trust between Programme Leadership and Agile teams, we implemented a simplified weekly report that showed progress towards value delivery in a simple, chart-based flow. We were transparent about progress and impediments, making leadership willing to offer support rather than blame as roadblocks arose.
By creating transparency and better articulating value delivery, we reduced the tension between leadership and Agile teams. Before these interventions, leaders often requested ad hoc reports and justifications for decisions daily. Today, senior management no longer feels compelled to review even the weekly report. Why? Because they trust that teams are creating value and will escalate serious issues when necessary.
We believe that Agile ways of working and product-centricity allow organisations to deliver what Jonathan Smart calls Better Value: Sooner, Safer, Happier. By applying the catalysts we’ve outlined in this blog series, you can begin to turn your Agile programme around.
