Many have discussed, and some have questioned, how Scrum and agile principles apply to non-software disciplines. Can they apply? Will they provide benefits? We’ve been working with a large program that has gone “all in” scaling and applying agile.  They build complex defense systems with hundreds of mechanical, electrical, and embedded software engineers and significant compliance demands. This program is completely organized around delivering value through dozens of cross-functional agile teams, strongly influenced by SAFe LSE for alignment and coordination.

Interestingly, the cross-functional teams focused on hardware appear to have better performance than the software teams. Their velocities are continually increasing, they meet their Sprint commitments, and their cumulative flow WIP remains stable. Further, their results have far exceeded previous programs’ results for physical integration. An assembly that normally takes six months was realized in ten weeks – cutting the assembly time by more than 50%. In addition, a well-known system integration point typically seen more than a year into a program was realized in seven months. A significant acceleration in value delivery.

The program has varying thoughts as to why these hardware and mechanical-focused teams are excelling, especially since many of the software team members have prior agile and Scrum experience. Had the software team members become “Scrum Zombies” lacking Kaizen and ownership? Are teams that are newest to agile likely see greater benefits?

A third more interesting observation is probably at the heart of the hardware team’s success – they are operating in a new system. This agile program is likely the most empowering, collaborative environment in which many of these team members have worked. Where collaboration is encouraged and truly valued. Where everyone feels collectively responsible for the whole system’s success, not simply the success of their part. Where, if a team member sees a good idea, they have the ability to act on it – even if it doesn’t appear on the schedule for four more months. It’s not surprising that program-level retrospectives include comments like “more focused teams”, “open dialog”, “honest and collaborative”, and “more ownership”.

So, yes, not only can non-software teams can benefit from agile, they may actually benefit more! As Dan Pink says on aligning people on a common purpose, “You probably want to do something interesting, let me just get out of your way”. This reminds us of Edward Deming’s observation in his book, Out of the Crisis, that people are already doing their best, the problems are with the system, and only management can change the system.That is a harsh, but all-too-true statement. Fundamentally it takes leadership — from the organization’s VPs to the program’s Chief Engineer and Program Management — to commit to this type of change, and see these types of results.

Written by Harry Koehnemann, SAFe Fellow, SAI

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Other names may be trademarks of their respective owners.