To improve time to market and focus on innovation, we’ve reorganized the engineering department of the Aerospace division of Elbit Systems around value. The usage of Lean-Agile mindsets and practices and the Scaled Agile Framework has led to more predictability and continuous improvement.
1. Introduction
Yael: At Elbit Systems Ltd. (“Elbit”) we develop and supply a broad portfolio of airborne, land and naval systems and products for defense, homeland security and commercial aviation applications. We at the Aerospace division develop airborne systems for commercial and defense aviation. Our systems and products are installed on new platforms, and we also perform comprehensive platform modernization programs. Our engineering department is part of the aerospace division and employs more than 1000 engineers from multi-disciplinary professions.
Elbit is a profitable and successful company and yet we at engineering found ourselves with two main challenges: There was insufficient synchronization between disciplinary departments and at the same time our engineers were constantly juggling between projects and other activities.
As part of our engineering strategy we have set a number of goals: improve our quality, time to market, cost and innovation at the same time. Our root cause analysis found some challenges with our culture: We were very execution oriented. We came to a conclusion that we needed to adjust the balance between projects execution and other important aspects like putting more effort on competence building and organizational learning.
As director of the software group, I had led some of our early efforts in bringing Agility into our software teams.
2. Background
About three years ago our operation department started the lean journey, and within a short time we realized that for the manufacturing alone being Lean is not enough because a significant portion of the problems were created upstream in the development processes. Our VP of engineering visited the States to meet Jim Morgan from Lean Enterprise Institute to hear about and visit companies which had adopted Lean practices and decided that we need to “make our engineering Lean”. I was asked to lead our Lean-Agile transformation across the entire engineering division. I knew I needed a different approach to building large complex systems at an enterprise scale.
2.1 Starting the journey
We started by learning about Lean Product and Process Development. Our leadership team got trained in the mindset and principles behind using Lean in product development. This was highly valuable as it provided the vision of how are leadership and organization can change to achieve better results.
But we needed more than mindset, we needed concrete practices. We’ve also seen great results from our software teams doing Agile. We needed a way to combine Lean and Agile for maximal success.
I contacted Inbar Oren from Scaled Agile, Inc. to see if the Scaled Agile Framework (SAFe) could help connect the dots between Agile and Lean, and turn mindsets into concrete practice.
3. Our story
3.1 Launching trains
Inbar: When I came in I found a leadership team, who already understood the foundations of Lean and Agile. They had seen success with Agile on a small scale, and could see how Lean mindsets and principles could help scale these successes to a larger group. I merely connected that understanding with the principles and practices of SAFe.
We started looking at how value flows through the organization, and asking ourselves if we can organize in a manner that aligns better with the flow of value. The existing silos between software, hardware, system engineering and more had to be broken and more direct communication was needed.
Where should we start? We wanted someplace that had leadership support, but also real challenges that we could solve. We chose the Helmet Mounted Systems (HMS) group, recruiting Ron, the System Engineering Director at that time into our transformation group.
We’ve discussed how to split that value stream into smaller groups. In SAFe we have an Agile Release Train (ART), which is a team-of-Agile-teams, it usually can consist of 50-125 people, since we need it to work as a team, but the HMD group consisted more than 300 people.
Working with the leadership of the group, we identified our first ART as well as the person who would be our Release Train Engineer (RTE), guiding the train in its processes and value delivery. This would be a cross functional group, transcending the traditional silos and able to deliver real value.
On February 7th, 2016, we trained the teams and launched our first train by planning our first Program Increment (a 10 week timebox encompassing five 2-week iteration).
This was an amazing event for us. Before PI planning skepticism had been high, but the event changed a lot of that. We had representatives from the business and manufacturing, who were not part of those processes in the past, take part in the planning itself. When the teams presented their objectives of the upcoming PI, business and engineering assigned business value together creating a sense of alignment.
The result was great, with people saying that, “questions that would have taken weeks to be answered, were answered in a few minutes with all stakeholders in the room.”
By April we had four trains running in the value stream, and we felt like we were headed in the right direction with our change initiative.
3.2 Running into challenges and finding solutions
Yael: In the coming months we started running into challenges. Starting with the technical aspects of SAFe, how do we build our teams? What should be the length of our iterations? Can we demo each iteration our system level accomplishments? What is the role of the functional manager in our new Lean world? How do we continuously improve?
3.2.1 How to build an Agile Team
We knew cross functional teams would be best, but could we build real multi-disciplinary teams? Previously we had single discipline teams working around projects, so we decided to organize differently. We built two types of teams:
- Application teams – which include system engineers, software engineers, algorithm developers, and verification & testing engineers.
- Hardware product teams – which include system engineers, electrical engineers, mechanical engineers, low-level software engineers, and verification & proof of design engineers.
In the past, we would build teams per project and then dismantle them once the project was done. In this configuration, each team could support multiple projects, and was self-sufficient enough to deliver value. This allows teams to improve and allows the train as a whole to invest in building infrastructure across projects as the same people were working on several projects.
3.2.2 What should be the length of our iterations?
We started with the standard 2 week iterations of SAFe, but teams found that hard. We’ve had a lot of discussions at the leadership team about this. We knew that some of the challenges were just growing pains, but the teams were insisting that 3 week iteration would allow them to deliver full value stories which were too hard to deliver in two weeks.
While we were still confident that the teams could be coached to learn to split stories into smaller chunks, as our value stream engineer said, “sometimes it’s better to be smart than right,” and so we decided to let the teams decide.
We’ve had them vote on the length of the iterations and they chose to move to three-week iterations, which have worked very well for us since.
3.2.3 How to demo our iterations’ accomplishments
SAFe talks about systems demos at the end of every iteration, but we are building cyber-physical systems, which means we can’t just gather in a room and demo the entire solution as many of the systems and subsystems are too big to move around.
We decided to do the iteration demo at team level, and the Program Increment demo at system level in our labs. In each Program Increment demo we would split into small groups of both team members and stakeholders and tour the labs. Each group would visit all the labs, and the team members at each lab demo their accomplishments in the Program Increment. We had rotating demos, where people would move between the different labs and team members.
Figure 1 – Program Increment demo in lab
3.2.4 What is the role of the functional manager in our new Lean world?
The role of the functional managers required thought. Historically, they were the people committed to execution, moving people around, tracking progress and ensuring success. As we transition to Agile Teams who took on the commitment for execution, it became unclear to the functional managers what their role was in the new Lean world.
We worked with them on embracing the role of Lean-Agile leaders, developing the technical competence of their people and making sure quality was good and that the architecture and infrastructure was built in the right way.
This was another great change. Managers used to be so overworked by the tyranny of the urgent, finally had time to focus on advancing the competencies of their people and the components under their supervision, empowering employees and building success.
3.2.5 How do we continuously improve?
In order to solve systemic challenges, we started holding regular inspect and adapt events, to analyze the root causes for systemic problems we were facing and come up with some ideas of new ways we could try to solve them. Most of the solutions I talked about above came about through the analysis and work of our teams, identifying root causes of problems and identifying solutions, and then implementing them during the Program Increment.
Figure 2 – Inspect & Adapt event
3.3 First wins
All this work resulted in tangible results. The predictability of our engineering outcomes has improved. We can be more predictable to our business partners, letting them know what they will deliver and when
We are much more synchronized between our teams on an Agile Release Train and within a value stream, as well as with our business and manufacturing counterparts
Functional managers are more focused on building technical competence, which increases the ability of the engineers and their independence. In addition functional managers are responsible to review the technical solution and to verify that the quality and definition of done are followed.
We’ve improved our ability to provide fast feedback through rapid prototyping, Set-based concurrent engineering, functional decomposition of requirement and frequent demos. This enables the business to provide better information to our customers as well as evaluate solution options quicker.
From metrics perspective, we have become more predictable in delivering features. We’ve improved our predictability of features complete according to our definition of done has almost doubled as can be seen in Figure 3.
Figure 3 – Predictability of number of features done in a Program Increment
3.4 What’s next for us
We’re still experimenting with the many tools of Lean and Agile. Still learning and improving our ways of working to get better results. We’ve become a better learning organization and there are some areas we need to improve.
We want to do a fuller Value Stream Mapping exercise. We want to map out the current state of our value stream, identify the wastes, delays and bottlenecks and then try to draw a future state of what the value stream could look like in the future. A value stream that can deliver value faster with fewer delays.
We want to improve the way we manage our backlogs. Today, we’re not good enough at building and splitting features and stories. We can improve how we define and build our Definition of Done.
We want to enforce stricter Work in Progress limits on features and stories, so that we stop starting and start finishing. We think this will help us reduce our time to market even further.
These are the next stages in our journey. We’ve learned a lot, and are already much more Agile and Lean than we were. We see this as a huge opportunity for Elbit to be a better company for our employees, and our customers. Enabling us to create better systems which make the world a better place.
4. What We Learned
As I said, this is still the beginning of the journey, but we’ve learned some important lessons in the process.
Lean principles are the root to everything allowing us to improve further. Practices are good, but principles are more important, we have to constantly focus on them.
SAFe works for developing systems at scale in multidisciplinary teams and makes the Lean and Agile ideas practical.
Change is hard,. This new ways of working and thinking were difficult for all of us when we started, and so the change process needs to be managed. It takes time to build a new Lean culture in an organization.
Coaching is critical at all levels. Teams need coaching, Agile Release Trains need coaching, value streams need coaching and people need coaching. Without coaching people might take wrong interpretation of the agile routines instead of focusing on Lean and Agile principles. We also learned not to rely only on external coaches. While they helped get us started, it was us, the leaders of the organization who had to lead the change and coach our people.
Process metrics are essential; as is focusing on short-term wins. Without short-term wins, people work hard without seeing results. As change takes a long time we need take the time to showcase and celebrate our accomplishments.
Cooperation with both the business units and manufacturing is a key element in the success of Lean-Agile in systems. The fact that we had people from the business and manufacturing involved in all stages of our process, from PI planning, through development, demos and inspect and adapt events, strengthened the connections and allowed us to discover problems earlier.
Management support is not enough. Management leadership is a must. It was not enough for us as the leaders of the engineering division decide on a route for Lean and Agile, we needed to learn about the new ways of working ourselves, and then lead the change proactively
5. Acknowledgements
Many thanks are due for the people who helped get us to where we are. First of all to Margaret Fogel, our shepherd, for her early feedback and continuous improvement of our experience report.
Yael: I would like to thank Kobi S., VP Engineering, Elbit Systems – Aerospace that his leadership and continuous support made our Lean-Agile transformation possible.
I would also like to thank Gil A., my partner in leading this change. His lasting optimistic attitude even during frustrating periods gave us the strength to continue. Also, gratitude goes to Shay V. from Lean Israel who consistently reminded us to put principles and mindset first and taught us how to assimilate the changes.
Last but not least, many thanks to Inbar Oren from Scaled Agile, Inc. His insights and experience helped us to restructure our organization, and to adapt the Scaled Agile Framework to our needs.
Inbar: I would like to thank Yael, Gil, Ron and Kobi for the leading this change and for allowing me to be part of it. Dean Leffingwell for letting me part of SAFe, and Ronen Bar Nahor, a dear friend, for introducing me to Elbit and starting to push the rock up the hill.
Author: Inbar Oren, Scaled Agile, Inc.; email: [email protected]
Copyright 2017 is held by the authors.
