Is Scaled Agile Stage-Gate® a viable way forward? HW/manufacturing companies experiments with scaled agile frameworks, like SAFe, still using stages and gates — does it make sense?
In the last years I have introduced agile ways of working in HW / manufacturing companies, of many now move from agile pilots to scaling agile. Here are some reflections on where I think we are heading.
First of all, transition towards an agile way of working is inevitable to happen, also in HW/manufacturing. Numerous companies move from agile pilots to make agile the new way of working in New Product Development (NPD) and innovation, such as Bosch, Lego, Grundfos, Danfoss, Saab, Tetra Pak etc. Agile ways of working is the best answer we know — right now — for development to meet fast changing technologies and markets. Every company will be exposed to change and needs to consider how to work agile.
Second, this is true because agile ways of working offers a package of decisive responses to change, such as; true customer focus, frequent releases, cross-functional teams, working in sprints and iterations with continuous learning, transparency and break down of silos, alignment between development and business, delegation of decisions, empowerment of teams, motivation of people, integrating relevant approaches such as lean and design-thinking and many more positive things.
The questions I would like to discuss are:
- What value do scaled agile frameworks such as SAFe add to NPD in HW/manufacturing?
- Can scaled agile frameworks work within existing NPD process managed by stages and gates or do we need modifications (and of what)?
- What will the future NPD process then look like?
From Stage-Gate® to Agile Stage-Gate®
Numerous HW/manufacturing companies are changing their Innovation and New Product Development (NPD) process to meet new requirements in markets and technologies, such as increasing complexity in products, need for frequent releases and opportunities in emerging technologies such as big data, blockchain and artifical intelligence.
It challenges the classic Stage-Gate® model, applied in most manufacturing companies, that in many cases are exposed to being slow and cumbersome and not really fit to support these new requirements.
The creator of Stage-Gate® Professor Robert Cooper recognizes this and have introduced Agile Stage-Gate® as a more adaptive and accelerated approach to NPD (Bob has done several brilliant articles on Agile Stage-Gate® — and I wrote a basic one with Bob, find it here).
Agile Stage-Gate® is a combination of the two worlds — working agile at team level within a high-level and transparent decision-model with stages, gates and portfolio management. We developed a framework for this, illustrated below, particular relevant for first round of agile and SME’s.
The combination of Agile and Stage-Gate® has in many cases proved feasible and successful (see article by Bob Cooper and Anita Sommer here).
Agile Stage-Gate® is particular valuable in a transformation period, as a way to introduce the agile way of working at team level by initiating pilots and experiments. At this stage, it is key not to change too much at one time.
My experience? It works! More transparency and ability to handle complex projects, more frequent deliveries, engaged and motivated people, shorter development cycles and happy customers (see example of a new microphone headset developed by agile here).
However, there is also another side of the coin by working agile without changing the classic Stage-Gate® model.
Agile teams wants to move fast and adapt scope and features as they gain more knowledge (one of the reasons why going agile). Reviews of agile pilots shows that this may clash with the required deliverables as defined in the initial plan. Furthermore, gate-meetings are often predefined in time, maybe 3–6 months ahead. When approaching a gate, teams may use most of a sprint of several weeks to prepare materials and deliverables for a gate-meeting.
Teams become goal-oriented towards delivering to the gate-meeting instead of keep focus on developing and releasing customer value. Pace goes down and teams gets frustrated.
Some teams solve it by building in gate-deliverables in the backlog, better, but the work — most of it waste — are still there, just distributed on many sprints instead.
It does not address the big challenge: We need to be agile in how we manage development — do agile governance, and prioritize between different opportunities — in order to facilitate agile teams to work at their best to develop and deliver customer value.
The simple combination of Agile and Stage-Gate® is a (valuable) pitstop on a journey. But, the journey continues, it is like a train that cannot be stopped, agile transformation is inevitable. Therefore, we need to further develop the framework to better support business agility and agile ways of working.
When initial success with agile pilots at team level are evident, management wants more. I have met expressions like: ’We want you to extend agile ways of working beyond pilots and agile islands — we want to become an agile company’.
They (we) now start a journey, with many senior managers not knowing how big a change they are actually initiating, following a path that involves changes such as:
- How to define teams (ie. purely product/value stream or with feature/function teams as well?) taking into accout existing portfolio and pipeline
- How to involve customers and users more early and frequently
- How to do early and frequent releases and MVP in a HW/manufacturing environment
- How to scale and organize agile programs and migrate existing portfolio
- How to organize capability/line organizations and the interactions to value streams, programs and teams
- Redefine peoples roles and responsibilities at many levels
- How to empower teams and delegate governance
- How to change management roles and adopt new leadership styles
- How to handle the change itself, ie. change mangement
- How to set portfolio and allocate resources in a flexible and agile way
- How to do budgetting that allows for changes shorter than the yearly budget
- How to collaborate with vendors and suppliers that may not work agile
- How to redesign the physical space to allow for co-located teams
Even at senior management level things will change in the way they work.
It soon becomes evident that agile is much more than changing the way we do projects or only a set of methods, which is just the top of the iceberg.
We need to look deeper under the surface to find new way of working, which dependens upon the culture around it. We cannot adopt agile at a broader scale (and rip the benefits) if we are not changing the mindset and the way we behave as individuals, teams and leaders.
What I have seen working well: Define a set of corporate agile-lean values and principles that guides agile behaviours at all levels — for example ‘Stay customer-centric and do frequent user-iterations’ or ‘Delegate and empower teams to take relevant decisions’. Top-management as well as other managers participate in such a process to take ownership and be able lead the change afterwards.
In addition, a framework is needed that provides a more hands on structure to execute agile values and principles in practice, but how will that look like?
Scaled agile frameworks (SAFe®) in HW/manufacturing
There are frameworks that seek to capture ’scaled-agile-in-a-box’, such as Scrum@Scale, LeSS, Nexus and in particular Scaled Agile Framework (SAFe®). These are appealing frameworks, and in many cases highly usable, in particular in pure software and in development of incremental innovations.
As a certified SAFe® consultant I see particular value of SAFe® related to:
- Systematic incorporation of agile-lean principles and (potentially) an agile way of working at all levels
- Recognizing and balancing empowered agile teams on the one hand with the need for aligning with corporate strategy and portfolio prioritizations on the other hand (like Agile Stage-Gate®)
- Adding additional layers between portfolio and team — such as program and large solution — that allow for scaling agile up (and down) depending on the need
- Using cadence (sprint-of-sprints) for syncronizing between teams and align with stakeholders and business objectives as well as delivering program increments
- Model for fast prioritization of epics and features and escalation of issues across layers, example by using scrum-of-scrums
- Agile-Lean budgeting that allows for changes in resource dedication to follow need and value-creation
- Detailed outlines of (new) roles and responsibilities, processes, events, tools and templates, in particular at program level
- An implementation roadmap and recognition of the dynamics of change (management).
For pure software teams — also in HW — SAFe® may work as is, with minor adaptions, mostly related to specifying the framework to the context.
However, I also experience that — even though SAFe® can add a lot of value to HW and mix HW/SW — there are issues or unsolved questions that SAFe® (and other scaled agile frameworks) does not answer:
More radical solutions where it is nearly impossible to make a product or program backlog of epics or features — how to organize and lead? SAFe® is excellent for incremental development ensuring a smooth flow of epics, features and stories between program and teams, but it does not provide a set-up for radical solutions. In practice one needs to consider; if an epic is in a context of high uncertainty and may require sophisticated technology or new unknown knowledge, how do we then mature epics at early stage?
In Innovation Management and Design Thinking we have vast experiences and methods for defining and scoping early stage opportunities, such as the value of research work, knowledge building, learning loops, technology screening, probing, user-research, customer journeys, service design etc.
You may still work agile, in dedicated teams, time-boxed and with frequent delivery, though the context, deliverables and set-up are different. (I will do another article on Agile Front-End integrating design-thinking, so look out for that!).
Frequent delivery and early releases are often different in HW. Things may depend upon each other — mechanical design may depend on electric design that may depend on software (such as making a hearing aid device with capsules, electric components, digital circuit, software…). SAFe® is developed for software with another set of opportunities for releases and does not provide a direct answer for this, except for one important thing; the PI planning — a core event in SAFe® — provides value in mapping dependencies between teams which (also) facilitate earlier releases compared to if teams should wait for done deliverables from other teams to proceed. Thus, many manufacturing companies now use PI planning for this reason.
I have worked with food companies where taste, texture, stability, raw materials availability, shelf life, food safety and produceability (can we produce it on existing equipment) are interconnected. Early ’releases’ may be designs, results, pretotypes and prototypes presented for management and lead-users, but it is hard to do early releases to market before the product is done and approved by customers and authorities. So, we use a lot of effort to find other types of value-added deliverables that can provide valuable feedback for development — being from lead-users and stakeholders — while we are on our way to release MVP’s of the final product.
The complexity in a true multi-discipline innovation/NPD process, which is often the case in manufacturing companies — say chemicals, food, machines and equipment — requires many different disciplines to be involved, not necessarily as dedicated team members, but merely attached in certain sprints or as external specialists. This is also true in software, but at a lower scale, and here it may be handled at PI planning events.
There are various ways to solve this using kanban boards and digital tools. However, I think it is key to delegate authority to programs and teams to handle need for and allocation of specialists.
I have implemented a model introducing three types of developers; 1) agile team members that are fully dedicated, 2) an agile pool of specialists that are shared in a program (pref. between 2–3 teams) and 3) specialists that are needed rarely or only limited time and that are shared across the organisation. Introducing type 2 relieve opportunities for attaching many types of disciplines and specialists in HW, though keeping them close(r) to the agile teams. But be aware — it is not an excuse for resource/line managers to keep their people in their own stable!
Aligning with other organizations, lab’s, external suppliers etc. that are not working agile. In practice, a supplier of new equipment needed for a HW company may work waterfall and are not able to release anything before date of delivery. If something needs to be changed after delivery, it will postpone development. I have seen internal labs using the same rigid model — queue up and wait for results, causing waiting times and additional queues.
In SW many vendors work agile, so the challenge may be less important. However, this is the reality for many HW companies going agile, and I see two next steps; take a look at agile contracts (as suggested by SAFe®) and see how they can be adapted and used in HW with non-agile vendors — and find new ways of co-creating at a practical level to align with external parties.
Governance, is the way rules, norms and actions are structured, sustained and regulated. In development it is for example the structure and process for making decisions that has big economic impact, such as choice of technologies and investments in equipment.
In SAFe®, Lean Governance is applied as a part of the Lean Portfolio Management process and is closely related to lean-budgeting, using metrics to monitor portfolio performance and using portfolio sync meetings to adjust. This is not so different from traditional portfolio management.
The interesting stuff is in the wider context of doing governance at all levels, for example at team and program level by adopting a continuous approach to build in quality and handle issues while developing. The figure below illustrates the change in the wider governance approach.
Can this work in HW/manufacturing? Yes and no.
Yes. The dynamics of Lean Portfolio Management, funding value streams and be able to change according to performance, makes good sense, also in HW/manufacturing.
What we change is what teams should work with, it is bascily human-effort, man-hours. And the approach of building in quality and handle compliance issues continuously while developing, such as build it into the backlog, are definitely applicable in HW.
And no, due to the irreversible nature of decisions with big economic impact. In HW/manufacturing, we make decisions on investments in new factory equipment, building machines, construct molds, buy raw materials etc., often in parallel with building the product and still risky business cases.
Many of these decisions are irreversible in nature — once we order and build the mold form we cannot use it for something else. Hence, the risk of decisions are often higher in HW than in pure SW, because it is more than human work we have at stake. (Using a modularized approach to standardize development components may change this, however it is a long journey and another story).
The higher risk calls for more governance and is a reason for the comprehensive governance in HW/manufacturing companies. Another reason is the cultural dimension, related to management’s praise for control.
However, we need to change the way we do governance as this is currently slowing down development, as mentioned earlier.
The future governance model may combine the SAFe® Lean Portfolio Management with lean-agile gates. And it is decisive that management let go the praise for control and delegate decision-making to lowest possible level, being programs or teams — which is key in agile transformation.
Towards Scaled Agile Stage-Gate® (SAFe-Gate?)
I believe we can get much value out of scaling agile, using elements of SAFe®, in the future NPD process. An example of how SAFe® can be applied in Agile Stage-Gate® is illustrated below:
A SAFe® program model with agile teams. Based on my experiences, most HW/manufacturing companies gets the most value from the program level, by applying agile-lean principles, program roles, program backlogs, cadence, PI planning etc., and having fully dedicated teams working Scrum and pull PBIs into their sprints. Many companies in HW have already portfolio management (that may need to be leaned!) and the large-scale level is often not relevant.
Virtual gates that are decision-points at critical steps in the process to ensure governance not taken care of by sprint or program reviews. Gates may still be used to assess maturity of a product to meet markets.
In practice, gates may be virtual and connected to decisions with economic impact over certain levels. Virtual in the sense that governors may shift according to expertise and management level required. Management should be able to take a decision within 48 hours.
Three major stages : Front-end, Development & Release and Launch. Having stages shine on what are important activities and methods in each stage. Stages needs to be re-defined in many companies to reflect what the most important activitites, methods and types of releases are.
Example: In development early releases, such as a MVP, should be defined as a core activity and relevant methods — such as 3D printing, augment reality, UX design methods etc. — may be highlighted as particular relevant to support development. In this way we have a framework that facilitate development of customer value, and not focusing on delivering reports to management.
Changing to a new Innovation and NPD process
As this article has shown, scaling agile and changing to an agile development model is not done over night and a final comment should be: The result is moving.
The most important part of the journey is not so much about finding a new single NPD model, but to adopt an agile mindset and a way of working that allow people — developers, leaders, no matter role or level — to work and collaborate with high energy, focus on customer value creation and be empowered to handle risk and take decisions. All models and processes should facilitate this.
We as consultants love to design processes that can guide and manage how people behave. I think we should really take the agile manifesto serious here — individuals and interactions over processes and tools. We must only design processes that in itself are agile and can facilitate agile behaviours with respect for individuals and interactions.
That said, I see great opportunities for scaling agile in HW/manufacturing companies, and rip the benefits of changing to an agile way of working.