Achieving Business Agility in Systems Engineering (Part 2): The “New” Dual Vee

Achieving Business Agility

Welcome to the second article in a series of posts about how the key concepts of Agile can be leveraged in a Systems Engineering environment to help businesses on their agility journey.

Many companies today need to adjust how they execute work due to many factors. For some, that includes domains working together that have traditionally either worked in functional groups or were recipients of work from another altogether different business unit.

We continue our exploration of Agile in Systems Engineering with a deeper exploration of the “Dual Vee” approach.

Part 2: How to Leverage “Dual Vee” Product Development

In part one, we discussed how Forsberg and Mooz identified a better way to visualize the complexity during product development. They further refined their view in 1997 and referred to it as “W.”

I described how we must help align people and processes in ways that lead from an agile-lean mindset.

In part two, we will explore how this alignment works in day-to-day practice. We will also explore examples of how this approach has helped some organizations.

It should be noted too, that in several cases, taking a new approach was not initiated due to strong thought leadership, but rather due to a tragic event that occurred that ended up costing lives and billions of dollars in law suits.

Hopefully, future events such as these can be prevented with a more proactive approach to leading change.

Recently, on June 21, 2020, Steve Denning wrote a great article in Forbes titled “Why Hardware Must Embrace Agile Principles.” He describes how some manufacturing processes prevent innovation. It seems (feels) counter intuitive that innovation would be prevented in industries known for innovation, yet here we are, trying to escape the chains that seem to hold us back. Although intended to prevent defects, they clearly have holes. They intend to ensure customer demands are met, yet sales are low.

Our existing product introduction processes must change. They are from an era that served us well, but things are different now. The cost of people exceeds compute time cost. The market is driven in a vastly different manner. Many other aspects of product design and demand are different today, yet we continue to see the old ways of delivering intact.

We can bridge the gap much easier than many organizations believe. We can marry the past with the present in ways that provide big wins yet cause less disruption. One way to achieve that is to embrace a dual-vee systems engineering approach that is lead with and through an agile-lean mindset. The premise is that leadership must lead the way, with a newfound agile-lean mindset.

Marrying what works in modern ways

There is misconception in hardware that adopting agile-lean approaches means acting like a software company. That could not be further from the truth. In fact, I would argue that many of the concepts that have led to success in the software world have their roots in history that long pre-dates agile. When I think of agility and hardware, my mind instantly thinks of Intel in the 70’s. That is not to say that producing a semiconductor is equivalent to producing a large piece of machinery. I am alluding to the fact that when you marry new ways of thinking within leadership with an attention to adopting an agile-lean approach in your business, you get remarkably better outcomes.

When we take a dual-vee approach, we leverage what is best with systems engineering. Rather than align people functionally, we take a different approach and align people along product lines, sub-systems and components. A sub-system team in this approach looks more like the cross-functional teams you hear about in the software world. It has integration engineers, test engineers, electrical, mechanical, etc.

Planning is also quite different. One of the key beliefs when embracing an agile-lean mindset is visibility. We leverage joint planning sessions, big room planning and tools that are product focused rather than task/team focused. In cases where we are working on large products, these planning sessions can look and feel like overkill, yet the results are significantly better and hard to argue with.

Here is a slight variation of the W Model. The key is not so much the vees and steps, but how we form people across those vees.

In the original V model, two steams are described, a specification stream and a testing stream. In the W Model, they describe “code” and “code test.”

This version of the Agile Systems Engineering dual-vee model shows something similar. There are two aspects that provide key differences. The first is that teams are formed across the vees, at component, sub-system, and system levels. This eliminates the bottlenecks caused by functional silos. The second aspect is related to a desire not to waterfall the entire product through the process. Instead we leverage testable chunks. In large system development, these “chunks” are significantly different than what we might find in the IT space.

Two methods of “chunking” are leveraged. Set-based design and Minimum Business Increment (MBI).

Most people will be familiar with the concept of MVP (minimum viable product). For some reason, business has mainly rejected that concept due to not having the ability to get customer feedback on a product that is not meeting minimally viable production standards. If you think about a generator as an example, it will need to be able to pass certain safety standards and basically be sellable before being able to be used by a customer to provide feedback. The phrase MBI was introduced as a bridge to the concept. We might produce a low-end version of that generator as our MBI-01, with the ability to start capturing revenue and feedback, while at the same time, continuing to develop the high-end version (MBI-02) of the same product.

Ideally, set-based design is leveraged with large product development. In set-based design, we might describe three possible solutions to a component or sub-system during design. We down select during the build phase as we are far more able to see the “moving parts,” do experiments and tests that help us determine which path will be best. This eliminates a couple of traps that sometimes occur: thinking we know everything before getting into build, thinking we know better than those building the product and taking far too long up front, thus delaying revenue and feedback potential.

Sub-systems themselves may need be part of a different process. Take for instance the engine in a large construction machine. That engine may be part of multiple products (maybe even our generator we described earlier). The engine has a SKU and is a sellable item in and of itself. Variations of that engine can become part of several different products (machines, generators, etc.).

Faster feedback cycles, visibility into the moving parts, planning together, working on components and sub-systems rather than working in a functional manner, decentralized decision making, safety nets, etc. are all part of the new way of working. We do this in a way though that is safe, embraces governance, are standards compliant and leverages systems engineering approach.

Showcasing examples of success

In the past decade, there has been a concerted effort to align hardware groups with the successes their counterparts in (IT) software have been achieving. A few examples of how an agile approach is making a major difference follow.

Anne-Françoise Pelé had a great interview with Jean-Christophe Eloy, CEO of Yole Développement, during which he explained the benefits of taking designers out of their functional silos and integrating them in self-managed multidisciplinary teams. (EETimes 6/6/2020)

Case study titled “Agile Systems Engineering at Lockheed Martin Aeronautics Integrated Fighter Group” by Dove, Schindel and Garlington – presented at the 28th Annual INCOSE International Symposium, July 2018:

Asked in early 2018 if the new agile approach is noticeably better than their prior approach, they summarized with this comment: “After the inevitable growing pains, the introduction of this new approach has been beneficial. Incremental releases and the release planning process permits earlier detection/correction of potential technical and programmatic issues. Major milestones have been accomplished on time, and customer response has been positive.”

Some of the key findings:

• Finding defects early
• Leveraging combined planning approach has created the ability to highlight issues and align efforts
• Integrated learning and improvement (using the process to define and improve the process)
• Transition is hard, leadership is critical

The list goes on and on with many companies embracing different ways of designing, building, and supporting large, complex products.

Putting it together

Although it is often noted as lessons learned in white papers, it should be apparent to readers that change is challenging and must have leadership leading the transition rather than “just” supporting it. In the hardware space, I suggest that we take an approach that leverages the best of what we already have going for us (systems engineering, standards based, governance, etc.) and marry that with an agile/lean mindset. There is a nuance there that is more difficult to describe in words than it is to see it in action.

The key to a successful hardware transformation is having leadership embrace lean-agile values and principles, learn as much as they can about new ways of approaching complex work, and embrace the idea that they are going to need help through the transition. This critical point married with the concepts presented here, will go a long way to creating the kind of environment where quality is kind, time to market is where it needs to be, the market loves what you are selling and employees love working in the new ways.

Wrap-up

A company’s ability to adapt rapidly, adjust in product and process on the fly while maintaining the highest quality, the ability to meet market demand, all while attracting and retaining top talent, helps to define a company today. There is plenty to learn when transitioning to agility. We should learn how to improve the way we work today so that we have a system of safety bets to work in as we start to change the system itself.

Upcoming

In the next issue, we will look at the product introduction process. These processes tend to be critical opportunities for improvement. At the same time, we also need to learn to work with them, improve them and work to our advantage. We will also explore if the time is right to consider alternative ways to address the reasons why they were created in the first place.