Combining stage gate and agile process models for product development

When it comes to balancing long-term development and short-term customer needs in a setup that blends agile principles with a traditional waterfall model, it is all about finding the right process.

Most R&D departments execute project from a roadmap based on strategy, market insights and solid business cases. It’s key for a development organization to be able to deliver new products in a predictable pace, in order to meet the requirements from a market. At the same time, the effort to support existing customers with bug fixes and adaptations should not be neglected. So how is it possible for a medium size development department to meet these two, sometimes opposite, requirements of predictability and responsiveness?

First, let’s look at how the process for development projects can look like. In Napatech’s case, we have a hybrid model, which blends a classic stage gate model with an agile model. For simplicity, I will only cover three of the stage gates for now. At Milestone 1 (M1) the project is initialized and goes into the planning phase. At Milestone 2 (M2), the planned the project goes into execution. And at Milestone 3 (M3), we execute the project and it is ready for release. The decision makers in M1-M3 is the executive management team.

The agile part of the model is what we do between the milestones, where we have short iterations, frequent feedback, are open to changes and focus on finalizing features that bring value.  If we try to illustrate this model, it could look like the figure below, where the gates M1-M3 from our stage gate model is mapped with the agile flow.

This model is the result of having a traditional stage gate model implemented in the organization while R&D is moving toward an agile way of working inspired by the principles in SAFe (www.scaledagileframework.com). Looking at the model from a R&D perspective, we allow the development team to ignore the stage gate model, and instead look at the team as a part of an agile release train. This can be achieved by having the team only looking at what is in the team backlog. The team backlog only contains the set user stories and enabler stories where the corresponding feature have been approved at an M2 milestone as a part of a project.

This model gives the R&D team most of the benefits from the agile principles, this is while the rest of the organization may not be using the agile model and SAFe on a portfolio level yet, and still rely on a traditional state gate model. It’s not always ideal to use such hybrid model, but we must accept this as a step in our agile transformation.

If we look at what is needed for an effective and responsive application support, there are some differences compared to the project model above. In our case, our application support handles minor customer requests, security patches and bug reports. These tasks require a much shorter turnaround time that can’t be achieved with our stage gate hybrid described above. So, the first deviation from the project model, is to remove the stage gates. This makes good sense, as the stage gates focus on business cases, purpose, customers and strategic fit. These parameters are all given in the support cases listed above.

The support manager collects the input from a support portal, and together with his team, makes the first assessment. This step can be compared to the work towards an M1 milestone in our project model except that the time scale is very different. In the project model, we count in weeks and months, while in our support model we have to count in days. If a support case can’t be resolved by the support team, the support manager, together with the product manager and project manager, will evaluate if the request should go into the team backlog or the product backlog. In order to make that decision, the project manager needs to have a rough estimate of the effort associated with solving the support request, as the capacity allocation vs effort in most cases is the decisive factor for whether the request ends up in the team backlog or the product backlog as part of a project.

This flow has been illustrated below, and there are many similarities between the project model and the support model. In fact, the only thing we are changing is the time scale and the decision-making process, and this is what allows us to be responsive and quickly react to our customers’ needs. At the same time, the process looks the same from the development team, which allows them to focus on their tasks and come up with innovative solution.

Now I have covered the project and support processes surround the R&D team. Next time, I will look into how these different tasks can be handled inside a single R&D team, and how Kanban can help us take care of both project development and support tasks.

If you have any experience with mixing agile and stage gate models for either project or support task, I will appreciate your comments below, even if your solution is different from our two-speed model described above.