Imagine we want to develop and then manufacture a wireless controller for small solar power plants. We’re talking about a hybrid product consisting of software and hardware. How should we approach this project? Lean, Agile, waterfall? All these options and their combinations are available to us. Agile Approach
Each of the presented production approaches has its advantages and limitations.
- Traditional manufacturing makes sense in environments with low margins, less reliable infrastructure, and less educated workforce.
- Lean manufacturing is suitable for environments with low margins, educated and motivated production workers, reliable logistics, and stable employment policies.
- Agile manufacturing is suitable for smaller customized series and products that require rapid innovation cycles.
There are also differences in product development.
- Traditional (waterfall) development approach is acceptable in stable industries with less competition. In environments where technological pressures are not high and there is plenty of investment capital available.
- Lean development approach (Kanban) enables larger teams that cover both software and hardware development. It is also suitable for hierarchical organizational environments.
- Agile development approach (Scrum, XP…) enables faster innovation cycles, larger development initiatives, and more breakthrough solutions. However, it requires an Agile transformation of the organization.
Based on organizational and market priorities, companies can practice all of the above combinations of Agile, Lean, and traditional approaches when launching a product. There’s no rule saying that Agile-developed product can’t be manufactured using Lean or even traditional methods. Sometimes this makes sense.
In this article, I focus primarily on Agile approaches. These are extremely suitable for complex development activities. These are activities where there is only a loose vision of the product or service, and the path to reach it is unknown. Usually, such a vision only describes the desired effect of the solution, while how the solution will look in practice is left to the development teams. These teams are self-organizing and self-directing*, operating only within the framework of product and organizational vision.
This is an expected and desired state that, under the right conditions, fully activates the creative and innovative potential of the development organization. The result of such initiative is usually innovative solution.
* Due to negative connotations from the past, I try to avoid the term “self-managed”, although it would be the most appropriate translation of the term self-managed.
Positioning
Cynefin framework is often used for positioning Agile approaches. It helps us decide for or against it.
Waterfall
Projects for which best practices or at least good practices exist in the Cynefin framework are implemented using waterfall approach. In waterfall, all planning is done before implementation begins. When the detailed project plan is approved, implementation starts. Changes to the plan, once in the implementation phase, are not desired, are usually expensive, and must go through a demanding approval and replanning process (Integrated Change Control).
The stereotype of a waterfall project is the construction of a new building. The investor expects to receive a building as was approved to the designer at the beginning of implementation.
Waterfall in the Cynefin model thus covers problems with obvious and (depending on circumstances) complicated solutions.
Agile
When dealing with complex problems where the relationship between cause and effect isn’t self-evident, the Agile approach is more appropriate. For example, we can develop a technically and functionally excellent application, but if the market doesn’t want it, we won’t recover the invested resources (application quality isn’t causally related to its market success).
For this reason, Agile is based on cyclic incremental development, where each subsequent cycle builds on the insights of the previous one. This feedback can be technical in nature or directly from the customer, who is continuously involved in the development process.
Probe – Sense – Respond in this context means that we develop a partial solution, verify it with the customer, and adjust the development direction in the next cycle based on the received feedback.
Agile in the Cynefin model covers complex and partially complicated problems. The latter in cases where there’s a higher possibility of requirement changes during implementation.
Another way to position the Agile approach is the so-called Stacey matrix. I think the image doesn’t require special commentary.
What about the chaos zone, when there’s neither consensus about requirements nor a known technical approach?
Agile doesn’t function in chaos. In such cases, it’s better to break the initiative into multiple sub-projects, which will largely be feasibility studies. The results of these sub-projects will ideally be rough models or prototypes that will then serve as a basis for further decision-making and defining requirements and technological approaches. This information will move us from the “chaos” territory to the realm of complex problems.
Often Overlooked Conditions for Agile
We’ve positioned Agile regarding the types of problems it addresses. But what about organizational factors?
In my opinion, for the Agile approach to be possible, the initiative must meet the following conditions:
- We’re developing a solution where the goal is known, but the methods to achieve it are not. Or:
- We’re developing a solution where the goal is loosely defined and can change during the project according to new insights that will emerge during development.
- The proposed solution is in a form that allows incremental realization of business value.
- The contractual relationship allows for incremental solution realization.
- The development organization allows and supports the use of Agile approaches.
- The customer is willing to continuously participate in the development process.
With the above conditions ensured, we’ve created an environment that allows for the Agile approach and the realization of its potential.
However, if the conditions aren’t met, it’s better to tackle the project with a linear waterfall approach. This doesn’t mean it will automatically fail, just that there’s less chance of success and the cost will be higher. Companies tackling complex problems/projects that aren’t ready for Agile transformation must accept this risk.
The decision between Agile or waterfall is of course also conditioned by the type of contract between supplier and client. I’ve prepared an extensive overview of Agile-adapted contract types in this article.
Organizations considering Agile transformation are invited to consulting services that I provide in various forms (including free). Choosing the right framework is an important factor for future success, as Agile approaches differ considerably from each other. Plus, there’s also Lean…
