Achieving Business Agility in Systems Engineering (Part 1)
Achieving Business Agility
Today’s businesses have multiple competing forces to contend with. There are changes in market dynamics, changes in workforce competition and competitor landscape, not to mention global influences.
More companies than ever before are leveraging agile approaches or have plans to do so. Although it appears on the surface that companies who create and leverage complex hardware and machinery in the systems engineering realm might be lagging behind the IT space in terms of being able to adopt and adapt to Agile methods, in reality they are optimally positioned for embracing agile methods.
Those that are successful have followed a pattern that allows them to leverage the benefits of agile methods while maintaining a standards-focused foundation.
This is the first article in a series of blogs specific to key concepts related to Agile in Systems Engineering. Each blog will contain key insights into the topic of leveraging modern product development techniques within a non-IT environment, specifically those that create complex products requiring engineering disciplines like electrical, mechanical, aeronautical, geo, chemical, runtime, etc. The goal of this series is to help organizations achieve business agility, which in turn helps them successfully implement their market strategies.
Part 1: How Systems Engineering and Agility Fit Together
We are familiar with traditional development approaches, namely “waterfall,” and its subsequent “adjustments” (see figure 1). This approach to development aligned well at a time when compute cost was much higher than people cost. It also aligned well with certain projects where the requirements were well-known and only minor adjustments were envisioned.
Fast forward a few years, Forsberg and Mooz identified that the visual depiction of what occurs during development did not match reality.
Back to the future
In their paper titled “The Relationship of System Engineering to the Project Cycle,” Forsberg and Mooz presented their experience with systems development and included hardware with software in their assessment. Their depiction of the product development process would become the “norm” for systems development. It was a “V” depiction of product development macro-steps.
The irony of what was presented, versus what I see in practice, is that most companies’ waterfall their product development and phase-gate these steps. Entire governance protocols were established to reinforce this paradigm.
In retrospect, if we look at V, and we think in terms of three key concepts, we arrive at the conclusion that agile values and principles could have been at play the entire time.
In a 1997 paper by Forsberg and Mooz, they presented this refinement of V and referred to it as “W”. I have always thought of it as “Dual Vee”. This version, as I considered it years later, solidified for me that agile, lean, systems engineering, mechanical, electrical, runtime software, ISO standards, etc. could all play nicely together. More on that later.
Fast forward to today
Over the past two decades we have seen a significant shift to embracing Agile methods. Although this change has been driven primarily within the IT Software arena, there have been some bold pioneers in the systems engineering space that have seen significant benefits in transitioning to Agile approaches. I have done a decent amount of work in the system engineering, R&D and scientific research arenas. In each case, I have been able to achieve great things leveraging an agile-lean principle-based mindset along with my experience in execution. After many years of delivering high visibility, mission critical work, I ventured into coaching. I found that I could help more people through coaching.
Putting it together
The way to think about how we organize cross-functional teams in a system engineering environment using an agile-lean mindset is based in the W model (“dual vee”). We must help align people and processes in a way that fosters agile values, removes waste from processes and brings visibility to the moving parts. Sometimes this is easier said than done, but it does work very well. Another key lesson is to recognize that things ARE different in a system engineering environment. There are various frameworks out there; Scrum, KANBAN, SAFe, DAD, LESS, etc. Fundamentally, all frameworks are wrong, and some are useful. A one-size-fits-all approach rarely works in systems engineering as well as tailoring what works to the nature of the business and its people.
What this means is that when you are working to bring agility into a system engineering environment, several things will help. The first is to get help, the right help. The second thing is to remember this is a journey, one that might begin with training, but certainly does not end there. Find someone who has a track record of success in your environment. To remember that this is a journey may sound cliché, yet if you ask any organization that has successfully transformed the way they do things, they will agree. Along the way, there will be a lot of continual improvement, adjustments and uncovering of more improvements to be made.
Wrap-up
A company’s ability to adapt rapidly, adjust in product and process on the fly while maintaining the highest quality, along with the ability to meet market demand all while attracting and retaining top talent helps to define a company today. There is a lot to learn when transitioning to agility in general. Add to that the complexities of building complicated products and it can feel overwhelming. We can apply concepts from the past that have served us well, and bring in more modern approaches to product development. The key is to not wait too long. Market changes, consumer demands, and the current COVID-19 crisis have all influenced companies to turn around products and solutions much faster and given a glimpse into how some companies are handling rapid change in demand and direction.
Upcoming
In the next issue, we will discuss more details around how we form teams of people around the Dual Vee such that we accomplish an Agile approach. We’ll also explore the robustness necessary to build complex products in a systems engineering environment.
