Agile process models and tools serve the iterative development of products and are based on incremental development in recurring cycles. It is common for companies not to use only one agile method, but to use several frameworks like Scrum or Kanban, which today represent the most common process models. Particularly in the non-IT environment, many companies resort to so-called hybrid development processes, which represent a combination of an agile approach on team level in combination with a waterfall like superordinate project and strategy control on portfolio and program level. This is often easier to implement, especially at the beginning of an agile transformation, and can already provide some advantages in terms of process flexibility compared to the Stage-Gate process.
In a separate post on Value-oriented Work Breakdown we explain, that it is mainly the product environmental conditions determined by the level of complexity and the majority of the respective technology that determines the approach for your development strategy. The magic on when to use which strategy to slice down work is thus mainly depending on the environmental and market uncertainty.
However, it is important to emphasis the direction of this causality:
“Not the development approach determines the risk profile, the uncertainity determines the development approach!
In a given situation according to the underlying uncertainty you choose your approach, not the other way around. To make this somehow clearer, I would like to provide some risk profiles for three cases: Classical Waterfall, Agile and Lean Development.
Classical waterfall development
The risk profile of a classical waterfall development usually is linked to a huge batch size and with it comes a high risk profile. Just at a very late stage of the development you start to build some “Prove of Concept” prototypes, that can be seen more as a number of “0-Series” products than as prototypes. In fact, at this point in time the development has already devoured a vast amount of the planned costs, many technical details are impossible to change at this stage or linked to a tremendous rework effort.
Lean Development
In those cases, where your analysis tells you, that you are certain about the product that you need to provide – so you need to slice work in the solution area – we suggest to develop a product delivery strategy, that delivers valuable parts of the final product, so that the customer can already use those increments.
A classical example in mechanical development that also Donald Reinertsen refers to in his talk about “The Big Ideas Behind Lean Product Development” is to reduce the batch size of a review and approval process of technical drawings from many at once to one piece flow or some few at a time.
Agile Development
If you have less information about the to be developed product and might not even know customer requirements and demands, you are confronted with overwhelming levels of complexity and uncertainty. Defining too much upfront without the required certainty will simply be followed by rework after rework in the curse of your product development. A probe-and-response approach is here the better choice.
Cutting the customer problem into smaller pieces, prioritize the backlog of customer problems and build products that simply aim to answer this incremental problem demand is the better approach in that case. You simply use the scientific method, include the customer early and often. Thus the respective risk profile in this case looks as follows:
With each incremental product you learn more about the requrements, develop your technical capabilities and in the best case have allready something that your custmers can use.