Written by Harry Koehnemann, 321 Gang Director of Technology
321 Gang is a SAFe® Gold partner that consults with companies that build large, engineered systems: aerospace, defense, automotive, medical device, consumer electronics, etc. These systems are characterized by siloed engineering functions (systems, electrical, mechanical); physical parts that have with long lead times, supply chains, engineering work that must be captured and traced for compliance, and highly regulated environments. And many of them build really, really big things.
We’ve helped many of these customers adopt and scale agile using the Scaled Agile Framework® (SAFe®). In doing so, we met with Dean Leffingwell (creator of SAFe) and the team at Scaled Agile (SAI) to discuss some of our perceived challenges using SAFe in an engineering environment. We were looking for support for engineering work (requirements, designs, modeling, simulations, trade studies), different role names, support for supply chains, and inclusion of manufacturing and production — just to name a few. Our plan was to become a Scaled Agile partner and deliver SAFe-based training that 321 Gang would supplement with our expertise on engineering. At the same time, SAI was also looking for ways to serve the needs of the large system builders, and invited us to collaborate on a version of SAFe for Lean Systems Engineering…and so it was that SAFe LSE was born.
We quickly removed the Portfolio layer (not the biggest challenge for large systems builders) and replaced it with a “System” layer at the top to coordinate ARTs towards building a common system. We explored ideas for adding that engineering work, focusing on small-batches, continuous flow, and keeping options open. The result was a SAFe model with substantially the same Team and ART layers, but included several additions:
- Engineering role name – Systems Engineering, Lead, Integration & Test, etc.
- A System Intent to align teams on a common direction and manage engineering artifacts
- Support for supply chains and system-of-systems environments
- Enablers as a broader definition of Architecture to include that engineering work
- Milestones for showing progress to stakeholders
- “DevProd” to bring manufacturing closer to engineering (similar to DevOps).
Working with the folks at SAI has been a pleasure. They are open to exploring new concepts; They see and discuss ideas through a lean and Agile lens. As an example, our discussion on a repository to manage engineering work became the System Intent with fixed and variable parts. And with the learning and decision made in flow. Although convincing them that the engineering work was more regular and planned than simply calling it a spike took some time :). Which led to the Enabler, BTW.
We frequently reviewed the evolving LSE framework with several of our engineering customers and others we met for feedback. The entire team delivered LSE Preview 1 in April, 2015 to a full class of big system builders: engineering folks, IT folks, and several experienced SPCs and SPCTs (SAFe certified consultants and trainers). The event was very humbling for me—a room full of brilliant minds at work, all informed by a vast diversity of field experiences. The feedback was also humbling, and we learned many things, including:
- Maintain the Agile role names as we want our existing engineers to understand that parts of their jobs will fundamentally change in an Agile transformation
- Large IT initiatives also need the “Solution” layer to coordinate ARTs, including Enablers and the Solution Intent.
- Two SAFe frameworks would be too confusing
Here’s a link to the LSE Preview 2.
The highlight of this experience was that we had a very smart and experienced audience telling us they wanted one framework. That meant that the new knowledge must be implemented quickly for fast feedback because the next LSE preview was already scheduled for two months away. I was frankly surprised that Dean and the SAFe team planned to update the framework and completely rework both the web site and course materials for Preview 2. But that is what agile organizations do in order to get feedback.
I write this article on the flight home from delivering LSE Preview 2. We were happy to receive feedback consistent with Preview 1, and learn that this latest LSE was a substantially better fit for large, system-of-systems organizations.
Personally, I have many takeaways from this LSE journey. First, lean and Agile principles are universal. Flow, small batches, cadence-based learning cycles, frequent integration and feedback, and face-to-face alignment apply to all big systems, both IT and engineering. Requirements, designs, and recording decisions are universal as well. Second, we have more work cut out for us as we look for ways to communicate how SAFe addresses the challenges of the engineering community. That will be our task at 321 Gang as an engineering-focused Scaled Agile partner.
But, like most things in life, my largest takeaway was the journey itself. I had the good fortune to meet and learn from brilliant, experienced practitioners who helped review and contribute ideas to LSE. And of course the folks at SAI who are not afraid to explore large initiatives, move quickly, and respond to change. They help cultivate strangers with engineering backgrounds like me! Those that know them already understand that Dean and his team “walk the walk” of a continuously improving, value-driven, Lean-Agile organization led by Lean-Agile leadership. Creating LSE this past year has been quite a ride— easily an “E-Ticket” from life’s amusement park. My sincere thanks to everyone who participated and contributed.