Adventures in Leading a Large-Scale Agile Transformation: Learnings and Reflections

In Part I, we described our journey in Leading an Agile transformation for a complex hardware product development program in a highly regulated industry within a large multinational company.

We didn't consciously set out to implement "˜Agile' or lead a scaled Agile transformation. We didn't have a masterplan describing how we were going to deploy Agile. However, we believed there had to be a better way of developing programs in order to be able to meet our challenging project brief. We were lucky to have a core team that was motivated and energized to try something new and we had an organization that was willing to let us experiment.

So, we just started.

We found a space for the initial team where we could all sit together, we bought a coffee machine, we got hold of some whiteboards and flip charts. We also started to plot our course and most importantly - learn.

We recognised early on that mindset and behaviors would play a key role but we also knew we would need to change some of the structural elements that were holding us back.

Our learning in this blog is therefore grouped into 3 highly connected dimensions: Technical Operating System, Management Infrastructure and Mindset, Capabilities & Behaviours. Striving to get the right balance between these dimensions was an important part of our journey.

Technical Operating System

The way assets and resources are configured and optimized to create value and minimize losses.

Standard diary

A standard diary was an important trigger to break old habits and re-re-enforce new ones. This wasn't about putting additional meetings on top of existing ones, we aspired for Minimum Viable Bureaucracy. To progress towards this goal, we reviewed "˜day in the life' analysis of our team leaders and were shocked by how little of their time was spent on value adding activities.

They spent their days bouncing between meetings with different stakeholders or firefighting the latest crisis. We knew we needed to provide the space for them to plan and lead. This meant we needed to challenge the purpose of the 2-day program reviews, the weekly 3-hour Product Technical Meetings, etc. How much value were these meetings actually creating?

We moved to a standard diary across the project to include sprint launch, planning, and retrospectives as well as a cadence of daily stand-ups across the team. Everything else was challenged for its purpose. This was contentious at times but freeing up capacity was the valuable prize.

Sprint Planning and Delivery

We undertook 6-week duration sprints and used planning poker and WIP limits in Kanban boards to highlight any constraints or conflicts requiring action during planning. Once the planning was complete, team's workload was more visible and they were better able to manage their WIP using Kanban.

This structured approach encouraged the removal of unnecessary work having thoughtfully considered capacity during planning. One of the challenges faced was a perceived level of micro-management, particularly when we were asking people to plan as they had never planned their work before.

We wanted teams to be able to plan in sufficient detail so they could commit with an increased level of confidence and be able to know whether they had "had a good day", not as a vehicle for oversight. This was an important message to emphasize.

Perhaps controversially in the Agile world, our program master schedule and rolling wave planning was an important part of our system. It contained key customer deadlines, cross-program dependencies, and important synchronization points in the design process.

Through the sprint planning, we were able to provide visibility and transparency of the effect of the team's actions on the overall product and program to both internal and external stakeholders. The important learning here is to maintain your Master Program at the appropriate level.

We chose a 6-week duration for our sprints based on the amount of time it was taking the teams to plan and the logistics of getting the whole team together. On reflection, a maximum of 4 weeks would have been a better duration, providing a better balance between planning and delivery.

Knowing What We Need to Know and When

Speed of learning was crucial so knowing what we need to know and when became an obsession. We used a technique of identifying and sequencing our key technical and program decisions to improve flow and minimize the risk of decisions being made based on flawed assumptions.

Visualizing this with the teams improved collaboration and increased teams' appreciation of how their work linked to others. This eventually became a key feed into prioritizing our backlog ahead of sprint planning.

Synchronization and Enabling Collaboration

Managing interfaces across teams is a key challenge for complex products where you are unable to eliminate dependencies. So, it was vital that we found a way to synchronize at key points in the design process to ensure we had a usable product.

Planning, sprint reviews, and Agile retrospectives became the scaffolding and structure to remain aligned. As part of the planning activity, we introduced "speed dating" where we allocated specific time for the teams to discuss any cross-team dependencies and synchronize around an aligned set of priorities at the program level.

Bringing the broader team together in this way, built empathy and trust. It also encouraged a process of reflection and learning from each other that provided improvements to future experiments.

Management Infrastructure

The formal structures, processes, and systems through which resources are managed in support of the operating system.

Align around a Compelling Vision

We had a demanding customer with a particularly challenging set of requirements to deliver, so we started trying to visualize this seemingly "˜crazy goal'. We worked on engendering a sense of belief that we could do this, flushing out some of our self-limiting beliefs that were holding us back. We had been told the organization would support us, we just needed to ask.

We had an explorer come and give an inspirational talk about how he had used a kite to accelerate his expedition across Greenland and break records. We also invested time in sharing stories where people had achieved amazing things by believing in their crazy goals. This generated amazing energy across the team and a real determination to try and deliver something exceptional.

After some early positive steps toward the achievement of our "Crazy Goal", it felt like we were not quite making the progress we had hoped for. A conversation with one of the team members highlighted a behavior that we had missed amongst all the buzz.

Due to high levels of personal commitment and accountability, teams were committing to deliverables they didn't know how they could deliver. People were concerned to ask for help as this could be perceived as a lack of accountability. We wanted to reassure the teams that we wanted them to raise issues whenever they needed help.

Daily Stand-Ups

Initially, we started with a daily stand-up meeting at Program level around some A0 paper sheets. As we grew in number, we ended up running to a standard diary at 3 levels across the team. These were a great opportunity for each team to come together and keep the focus on what we needed to deliver plus ask for help.

There was plenty of experience of "Short Interval Control" elsewhere in the business but typically this would run for a relatively short period before petering out and "˜normal' governance taking over. It was a challenge for some to get their heads round that we would be meeting every day for the entire project.

In Part 1, we described how one engineer didn't see the point but this soon changed! When working effectively, these stand-ups would be 15-30 mins and each team developed some of their own rituals: you are buying cake if you are late more than 3 times, etc.

Most importantly, these stand-ups provided leaders with a platform to lead and a social mechanism for a candid conversation. They also provided team members with an opportunity to request help.

Visual Performance Management

Over the course of the project, we evolved our approach to Visual Performance Management. We started off with paper sheets stuck to a wall for the Program Management Office and progressed to a Tiered Visual Performance Management (TVPM) system where each team had their own performance management board either physically or digitally.

This was one of the areas where teams experimented the most with different approaches. This was influenced largely by the composition of the team but also a growing interest in exploring digital options.

The performance management system was used as part of the standard diary cadence and provided the infrastructure to invert the corporate pyramid. This happened by engaging the majority, measuring the right things right, and providing status at a glance. Our role as leaders was to better enable teams to deliver by rapidly removing impediments or securing support when required.

Mindset, Capabilities and Behaviors

The way people think, feel, and conduct themselves in the workplace, individually and collectively.

Mindset Is Everything

The prevailing mindset across the organization at the time was that all programs overspend, over-run, and fail to deliver against technical attributes. This backdrop, in conjunction with the risk of significant financial remedies, was in danger of creating an extremely negative environment and closed mind-set.

We talked earlier about the importance of alignment and how we worked as a team to instill a sense of belief that there could be a different way. We encouraged each other to try new approaches and shifted the dialogue from focusing on failure to celebrating the learning. Our hypothesis was that if we could challenge some of the deeply rooted beliefs and more established ways of working, we could unlock the potential of the project team.

It would be false to say that everyone was on board, but we had enough momentum to really start to make a difference and a growing number of people willing to experiment and try new ways of working. We started to see the benefits coming through and the energy remained high as we knocked down preconceived barriers and celebrated a series of measurable wins.

Behaviors as an Observable Action

Behaviors were an important part of creating the right conditions. So, we spent time exploring a common set of behaviors and habits that we wanted to live and breathe.

We were then able to support each other in practicing and improving our behavioral skillset and through coaching and process confirmation, we were able to benefit from the giving and receiving of feedback. This was at times uncomfortable but as levels of trust grew amongst the team, these conversations became more normal and extremely beneficial with some team members commenting that they really appreciated the feedback.

Leadership Shadow

One of the hardest changes to make was to challenge a perceived level of control that leaders felt they had from existing practices. This perceived control is an illusion.

Particularly when a team scales, it is impossible to spot and fix every issue, to understand every risk, to know all the answers. When things go wrong, we tend to put in more meetings, more oversight, usually with good intent but this just consumes more capacity.

How much more powerful and robust could it be if you allow your teams to demonstrate their accountability and you shift your role from oversight to enablement? Your job is to set the vision, enable alignment, coach, don't fix, and allow the potential across the team to flourish.

Continue Exploring the Unexplored

There is plenty of literature prescribing specific frameworks and approaches including heated debates on which method is best. In many ways, I think the most important lesson is to just get started.

Take what you are doing today, identify some experiments you could run as a team drawing upon insights you have gained from other people's experiences that align with your context and then keep learning and experimenting.

We had the privilege of working with great people on this fabulous learning experience "˜Exploring the Unexplored' and have pulled together some key principles and reflection points that we feel captures the essence of our journey.

Key Reflections:

• Above all else, it is a thinking way: getting underneath how your thinking impacts your behavior and being open to new perspectives, is crucial.
• Strive for a shared understanding of the goals, key principles, and expected behaviors:provides a compass to improve alignment and improves engagement across the team.
• The shadow of the Leader is incredibly important: It is a choice how any of us choose to show up. Think about how your actions may directly influence the behavior of others.
• Strike a balance between focusing on structure & behaviors: Different focus required at different points in the journey.
• Do not assume you can start at the end of someone else's journey: A crucial element of the journey was the learning environment engendered by the team which became self-sustaining.
• One size does not fit all: Beware slavishly following a paint by numbers approach. Focus on what is right for the context you are facing.

We hope that our reflections may provide some insights as you embark on your own adventure. We would love to hear about your experience.