Over the course of the last year, I’ve found that advocates of system engineering share some common beliefs. The transition to smart, connected products is driving increased development complexity. System engineering is a means to mitigate that increasing complexity. Yet, system engineering can slow things down. While attending the INCOSE (International Council of System Engineering) Symposium in Washington, DC in July, I wanted to find out if some companies had found ways to address this conundrum. Sure enough, I found that Lockheed Martin had adopted something called Agile System Engineering.
This post reviews how Lockheed Martin adopted Agile System Engineering for the development of the F16 and F22 fighter programs.
Setting the Stage
First off, let’s set the stage as to why this kind of initiative is so important.
#Agile #systemengineering at @LockheedMartin: "We had slowly realized over time that we needed to change. Or solution would be to beef up our SE capability. We actually slowed down. We looked at scaled agile as a means to get faster." #INCOSEIS
— Chad Jackson (@ChadKJackson) July 9, 2018
#Agile #systemengineering at @LockheedMartin Focused on the F16 and F22 at the Integrated Fighter Group (IFG). Faster changing threads need urgent defense response. Taolired baseline of Scaled Agile Framework. Involved 1,200 people. #INCOSEIS
— Chad Jackson (@ChadKJackson) July 9, 2018
For those unfamiliar with modern warfare, the name of the game is change. Modern threats are emerging from foreign entities that require an incredibly fast response. That means contractors like Lockheed Martin have to react quickly. System Engineering practices are needed. But they must be agile.
The Plan
Adopting an Agile System Engineering process, however, isn’t a snap, especially with 1,200 employees. With executive sponsorship, Lockheed Martin developed an operational model that is a mix of agile processes and system engineering processes.
Architectural pattern. #Agile #systemengineering at @LockheedMartin #INCOSEIS pic.twitter.com/GWUOjteXHV
— Chad Jackson (@ChadKJackson) July 9, 2018
Measuring Success
Over the years, Lockheed Martin had realized the truth about “prove-out” initiatives. Any theoretical new process can be successful if you have enough executive scrutiny and your best people work the problem. Instead, Lockheed Martin deployed their changes to a production program. This truly stressed their initiative processes, training, and performance measurement.
#Agile #systemengineering at @LockheedMartin “We picked a system that was in the main path of work to experiment. We targeted about a 3 month train for a team of teams. That was successful. We went to a full weapon system.” #INCOSEIS
— Chad Jackson (@ChadKJackson) July 9, 2018
During that time, when Lockheed Martin aimed for “high flow” of completed tasks as part of the Agile System Engineering process, they learned to treat it as a workflow. They used this approach to identify bottlenecks and then address those bottlenecks. The driving metric was this overall “high flow” of completed tasks. They specifically measured that as a quantified metric.
#Agile #systemengineering at @LockheedMartin “A lot of what you have to do is control dependencies to have high flow.” #INCOSEIS
— Chad Jackson (@ChadKJackson) July 9, 2018
Details on what metrics they tracked to implement #Agile #systemengineering at @LockheedMartin. The focus turned away from minimizing requirements change, which fundamentally conflicts with agile. #INCOSEIS pic.twitter.com/lVHMd5X6pL
— Chad Jackson (@ChadKJackson) July 9, 2018
Ultimately, Lockheed Martin found reasonable success with this process model, as you can see by the increased throughput in that last chart.
Overall, Lockheed Martin had a problem to solve. Agile System Engineering is part of that solution. And given the overflow of attendees at their presentation at the INCOSE event, so are many other companies.
