Our ‘Value in Action’ series shares case studies that demonstrate the real value of our partners’ digital solutions in aviation. Here we find out why Project4 Learning Lab was selected for a large-scale Agile Transformation project for a big multinational, the process and outcome, and the lessons learned along the way.
Leading a large-scale Agile Transformation is quite an undertaking. It requires relentless focus and discipline to create an environment that will empower teams to deliver innovation and change accurately, and at pace.
There are countless theories about how this can be achieved, yet not so many on how those concepts actually work in practice. Moreover, many of those theories relate to Agile Transformation through a single lens, -software development – when we know that there are a number of variables to consider.
Recently our team at Project4 Learning Lab was involved in а complex and large-scale Agile Transformation project for a big multinational, involving a hardware product development program designed for a highly regulated industry. In this post, we want to share with you some of the key challenges we faced, and the steps that we took to deliver precisely what our client needed
‘We need to fix it, and fix it fast’
The problem: After ticking all the boxes and securing the deal, it was obvious to all that the hardware did not exactly match the specific nature and nuances of the customer’s operational environment. But, this was hardly a surprise – no hardware product is truly an ‘off-the-shelf’ solution, there is always the task of adjusting the product to fit the client’s particular systems, processes and protocols.
‘We need to fix it, and fix it fast’ came the voice of the business, not least because the contract was worth billions. The problem was that there was no obvious quick fix, and at that point there was no guarantee that an effective solution would even exist.
Nevertheless, the hardware provider was committed to redesign the product to match the customer’s specific needs precisely. Our job was to ensure that we managed the process to meet the customer’s technical requirements, and deliver against to a rigid timeline with some withering financial penalties if we failed to meet our deadlines.
It was quickly obvious that with such a high-profile project, the hard-fought reputation of the hardware provider was genuinely at stake – so we found ourselves as the ‘top risk’ within the business.
This would effectively be a crisis management situation.
‘Have you got a concept yet?’
Very quickly a small and highly-skilled, cross-functional team was assembled, with representation from across the business. It called itself the ‘Falcon Team’, as it intended to fly at high speed, yet possess the ability to change direction rapidly whenever necessary.
Over the course of the next 10 weeks the Falcons evaluated thousands of potential technical solutions using simulations based on a “Design of Experiments” methodology.
The team eventually grew to over 30 people as they whittled down the viable concepts to a shortlist of six. They then evaluated each on the basis of the implications they would have on the existing supply chain, as well how they might be introduction into incumbent client infrastructures.
The concept selection process was completed in record time, and passed the preliminary Phase Gate review with the ‘Technical Audit Team’ – without the need for any of the customary dress rehearsals.
The conclusions the team had made were, in principle, endorsed by the Technical Audit Team but it was agreed that the necessary implementation schedule would be troublesome – the sheer scale and scope of changes required and the design and development program necessary could mean that the project could take 3-4 years to complete.
‘More people please’
The pressure for progress was building, and more people were joining the team. The good news was that more people meant more capacity – the bad news was that more capacity meant more integration. In turn, this meant more meetings, less progress, and again, the need for more people.
We decided we needed a fresh stimulus, so, we engaged some specialist consultants to help analyse and review our thinking.
In our first workshop we brought the whole project leadership team together with the technical specialists. We quickly developed a broader understanding of requirements through a ‘Quality Function Deployment’, before completing a ‘Vertical Value Stream Mapping’ activity to define the key elements of the Programme Master Schedule.
Shortly afterwards we brought the first 150 people from the team together to a program launch event. Our keynote speaker Tom Avery was an explorer, and one of the few people in history to have completed the polar trilogy. He emphasized the importance of planning, teamwork, risk management, and most importantly – the ability to react quickly to changing conditions.
As a result, we had found our project theme – Exploring the Unexplored.
Meanwhile, our Phase Gate dates were already scheduled according to needs rather than capability – and we soon faced the Technical Audit Team again with the objective of fixing the system design. They were hard taskmasters (as we needed them to be), and two days later we were presented with 9 critical corrective actions to address.
‘What don’t you know?’
Naturally we had the need for speed, and looked for ways to create flow in product development, without sacrificing quality.
We split the program into two Phases – Exploration and Execution. In the former we focussed on the detailed requirements and fleshed out potential solutions. In the latter the entire production system came under scrutiny as the project had to be delivered flawlessly.
We knew that to accelerate the program in the Execution phase, where the scope of work was clear, we needed to identify and eliminate waste to create the desired seamless workflow. We concluded that in the Exploration phase, where the work required was not so clear cut, we would need to create workflow through identifying some key decisions and sequencing them correctly.
This way we could manage and schedule our work more effectively, keeping the growing number of teams aligned to the work that was required ‘right now’. We repeatedly asked two key questions that demonstrably enhanced the process: “What’s stopping you from fixing the design today?” and “What don’t you know?”.
It was clear that speed of learning was going to be critical for us to deliver quality to our customers, and the successful implement of this large-scale Agile Transformation, project would need to make the right decisions the first time around.
Working as a truly integrated team we identified the 25 key decisions that needed to be made in the Exploration phase in order to push the project forward.
We concluded that these 25 decisions needed to be made them with no residual risk – and identified what really was really stopping us from making these decisions – the things that we didn’t know. Eventually, the teams started planning the work that they would need to do to turn these unknowns into knowns, and thereafter have the ability to make robust and well-rounded decisions.
At this stage we knew we had a significant backlog of work that we would need to burn through to meet our deadlines. By then we had grown to a community of around 450 people working in 45 distinct teams – and we were only too aware that we didn’t have an effective way of tracking progress and identifying the real bottlenecks.
‘How do you know you have had a good day?’
We knew we needed transparency within the workload, and therefore decided to create a forum through which the teams could present the issues that they recognised they couldn’t resolve alone.
So we introduced daily stand-ups at three levels in the project – Team level, Sub-System level, and at the Whole Product/Program level.
This concept wasn’t initially a popular one in every quarter, with some teams noting that there was “not enough meaningful progress made every day to make a daily meeting worthwhile”.
“Exactly!” we said. This was the reaction we sought.
We were convinced that we would start winning when most of us had a good day more often than not. So in order to deliver the transparency we all craved, we began to track decisions and associated learning points in each team using physical whiteboards.
Put simply we needed everyone to know whether or not they had a good day.
This was extremely useful for us too, as we quickly understood that there were more bad days than good – and that if we didn’t make some adjustments we’d miss our deadlines. We knew that to fix a problem we first needed to define the problem.
A brief investigation revealed that the teams were still doing the work that they would ordinarily do in addition to the decision-making process. This situation was in turn generating more work for other teams, and the volume of work was snowballing quickly.
So we needed a way of removing unnecessary work, and remotely synchronizing the efforts of all the teams.
‘Don’t make us do this’
We decided that we would split the program up into six-week blocks. These building on the Exploration theme, were to be known as ‘Expeditions’.
Each Expedition started with a review of the progress made on the product design and against the Master schedule. This was followed by intensive team-based planning process, ahead of the Execution phase.
At the end of an Expedition, each team at each level would complete a ‘lessons learned’ review to identify what operational changes might need to be made before the next Expedition. In the first Expedition we cautiously scheduled two days for the planning phase – but after six days the team hadn’t completed that task.
Our first test of faith arrived at an emergency meeting with the leadership team. “We have tried our best,” the team said, “but we can’t get a plan. No other program plans at this level, and we’re losing valuable time. We think that we have done enough. Can we stop now?”.
The leadership team believed that we had moved too far along this process to deviate dramatically, and urged the teams to finish the planning. Two days later they were done.
“Why are you doing this to us?” asked a young engineer in the office one day. “Why do you need to know what we are doing every week?”.
“We don’t but we need you to know what you are doing every week” was our reply.
We didn’t necessarily make the progress that we needed to in this first Expedition, but there were early signs that the teams were actually starting to align with each other, interacting and scheduling their own work in a mutually beneficial fashion.
More good days were ahead of us.
‘When we commit to a deliverable we’re telling you that we want to do it, but we don’t yet know how’
A key learning from that first Expedition was that we needed more structure in the planning phase to coordinate the work of every team effectively.
The situation was complicated by the fact that the teams were globally dispersed (both whole teams and team members), and some team members were working part-time on the program, whilst simultaneously supporting up to 3 or 4 other programs.
We set a schedule that considered all time zones involved, including ‘speed dating’ time slots, where each team could meet another and talk through what they required from each other, when and why.
We also took this opportunity to secure a commitment from the managers of part-time team members to enable them to support the planning activity, and to guarantee a proportion of their availability to us for the next six weeks. This time the planning was completed in six days and the collaboration between teams was growing organically.
There was a new energy in the program – engagement levels were rising as people proposed and developed their own ideas to improve the product. However, there were still concerns about the pace of progress. The teams were so engaged that they were committing to deliverables that they had no idea how to deliver! Despite this, decisions were starting to flow, and through our daily stand-ups we were noticing an ever-increasing growth of the good days over the bad ones.
‘Why isn’t everyone doing this?’
12 weeks after starting we launched our third Expedition, determined to limit the amount of work that people were doing, whilst focusing on the most important elements.
We trialled the idea of having a prioritized list of ‘Golden Threads’ – the key deliverables needed in the next six weeks in order to deliver the program.
This meant that we then had a ranked list, one that would support the teams as they prioritized their work. We also implemented capacity-based planning – each team evaluated the work required to produce the key deliverables, and stopped committing when they didn’t have available capacity.
We expected a clear relationship to develop between the committed deliverables and ‘Golden Threads’. In other words, teams has their own hierarchy of tasks, and the estimated times allotted to the work was open to scrutiny. If those guidelines were observed but the team could not subsequently deliver everything required, we knew we would need to secure more resources from the wider organization.
Up until that point all of the Expedition planning had been done using flip charts, post-it notes, and spreadsheets. Whilst that functioned well enough, it didn’t actually give us the transparency required to align and engage the teams effectively at scale.
So once we had a prioritized backlog at program level we experimented with a digital Kanban system. We initially selected three teams to complete all of their planning and execution using the system. Consequently throughput improved by around 30% in this Expedition, and we were able to close all of our critical audit actions.
“Why isn’t everyone in the organization doing this?” asked the previously dissenting young engineer.
And he was right.
‘What is it that you are doing?’
In the next Expedition, we rolled the digital Kanban system out across all teams for a scaled Agile solution, convinced of the benefits of transparency and alignment. This made the planning significantly easier, and the end results more coherent.
By now team engagement had sky-rocketed, and we decided to recognise this by introducing a ‘Wall of Awesomeness’ – a physical space where we could display and celebrate the amazing things that people and teams were doing. In doing this we were attracting attention from other program teams within the organization, and the curiosity of our external partners.
“What is it that you are doing?”, they asked, closely followed by “Can you show us?”. Word soon spread, and the number of visitors to the daily stand-ups at all levels increased with each passing week.
Whilst the problems and challenges remained, our ability to detect them and react accordingly was enhanced beyond recognition, and we were making more progress with each Expedition we conducted. We had built the structure, systems, and necessary routines required to deliver success whilst simultaneously improving the way that we were working together as a very large team.
‘Can we do it too?’
Next we designed a system of ‘Process Confirmations’, for the leaders at all levels to perform small, frequent tasks to confirm that the framework was being followed, and that the required results were on-track.
This encouraged transparency and productivity even further, and gave leaders informal permission to go to the place where the work was being done to provide feedback to others. Whilst this felt mechanical and artificial the first time this deployed in an Expedition process, it soon developed into the new normal and boosted the sense of us being one big team that worked and learned together.
By then we were already advising other programs on how best they might approach similar tasks, and our hardware partner was proudly telling us that they were running their program in six-week increments to align with us too. The program continued running Expeditions for the next six months, making an increasing number of small but valuable improvements each time.
‘What did you learn from that?’
Whilst we were busy leading this successful Agile Transformation process, the aerospace industry began to encounter a number of unforeseen commercial challenges, which drove our client to re-evaluate and consolidate many of the development programmes they had commissioned. Consequently the hardware provider negotiated a new, mutually beneficial contractual agreement with the end-user, and the program we had been working so diligently to deliver was cancelled.
Whilst this was a crushing disappointment to us all, we were able to console ourselves that the lessons we had learned working on this project would be an extremely valuable asset for us.
We learned so much from the teams that we were privileged to lead through a large-scale Agile Transformation. Watch out for the second part of our Agile Transformation adventure, where we will share the important insights we learned from the whole process that should be valuable to you all.
Interested in finding out more?
Take a look at the Project 4 Learning Labs storefront on Yocova.
Author: Project4 Learning Lab
Published: 6th July 2022
Photo by Angela Compagnone on Unsplash
;
