Agile practices originated in the software domain but are increasingly applied to the development of physical products. The promise of faster time-to-market, increased flexibility, improved transparency, and higher customer satisfaction are some of the benefits that have accelerated adoption in software development.
However, the practices common in software development are difficult to transfer to the development of physical products without modification. Therefore, they have to be changed to fit the context of your product, company and industry.
As part of a working paper at the University of Cambridge, a multiple case-study involving 17 manufacturing companies from a variety of industries was conducted to understand how agile is currently applied in industry practice.
Agile doesn’t always mean agile
The stage-gate process has long been the standard for physical product development, where products are developed sequentially in defined steps with a long initial planning process. Generally speaking, implementing agile practices aim to break down these sequential stages into time-boxed iterations without the need for lengthy advance planning. However, constraints of physicality mean that agile can take many different forms. There is no one point where you move from being non-agile to agile, but a wide spectrum of possible combinations of sequential and iterative approaches.
While frameworks such as SAFE or Scrum@Scale offer comprehensive guidelines, most cases had their own interpretations of agile. Based on the findings from the case studies four mutually-inclusive clusters of interpretations were derived, with agile frameworks combining all four interpretations:
1: Agile as a method to improve team collaboration: The focus here is on bringing people from multiple departments together and foster product/project ownership for an Agile team throughout the whole development process. Another aspect included under this categorization is the notion of self-organizing teams and increased team autonomy.
2: Agile as a method to increase customer integration: Some companies focused their efforts on involving the customer more. This didn’t necessarily coincide with incremental development, but solely getting the customer on board throughout the development process.
3: Agile as a method for better task management: Another major interpretation of agile was as a bottom-up project management tool to organize tasks while maintaining a constant rhythm. Time-boxing is used to evaluate progress and prioritize tasks more frequently. A large automotive company, for example, used a 2-week time-boxing and subsequently only evaluated the accomplished tasks and prioritized work for the next two weeks, with no customer involvement or early prototyping.
4: Agile as a method to learn fast using early prototyping: Here, agile is interpreted as a method for failing fast and learning from failures using prototypes. These prototypes can be either physical or digital, such as rapid prototyping. Interestingly, companies who focused on this interpretation, such as a research & technology company and a global aerospace & defense company, tended not to use strict time-boxing.
The main takeaway from this conceptualization is that the differences in how agile is interpreted affect aspects such as:
- For which products/projects is agile suitable?
- What agile tools are applicable?
- What performance indicators should be measured?
As an example, if a company decides to focus solely on agile as task management, it would not make sense to measure its success by prototype maturity but rather by velocity.
Using agile for physical products requires customization
While the majority of companies suggested using agile only selectively, some cases mentioned they use agile in all product development projects. The main difference is that these companies select and adjust agile tools over the span of the project rather than have a uniform approach. For example, an industrial furniture company suggested using agile throughout the whole project, but later in the certification stages keeping only the tool of time-boxing to maintain a rhythm (thereby using the task management interpretation).
Three approaches on how agile can be adapted to the specific context emerged from the case studies:
1: The first approach is to understand the “ideal” agile process – and specifically Scrum – and then adjust this textbook process to fit your constraints.
2: The second approach is to first analyze your current sequential process and then select agile tools that are suitable.
3: The third approach is to simply use an existing framework (SAFe, Scrum@Scale, LeSS, Nexus, etc.).
Some companies used multiple approaches throughout their journey. A European aerospace and defence company, for example, started using an adjusted SCRUM method in specific projects since 2016 and then decided to use the SAFe framework in 2018 to scale across the whole product development.
Governance in an agile development process
In addition to changing agile elements such as the role of the customer, the definition-of-done and the team composition, project governance must be adapted as well. One of the main principles behind agile is self-organization of teams, which in software development has shown to lead to a higher productivity, as lengthy top-down planning is reduced and task allocation is more efficient. However, there is inevitably a conflict between maximizing team autonomy and aligning the team with the rest of the company (technology strategy, program management, etc.).
The study found that two imperatives are effective to overcome this challenge:
- Self-management but not self-direction
- Clearly defined safe space for the agile team
A new governance model must accommodate these imperatives, as seen in the model below.
Role of Product Owner/Project Manager: This role serves as the interface between the agile team and the management and customers. They are responsible for steering the project and prioritizing tasks. Rather than just representing the voice-of-customer as prescribed in agile in software development, they combine the voices of the customers (value), management (technology strategy, alignment with other projects, standardization) and the team (technological risk, team capabilities). Hence, they do not receive orders from the management to be broken down into work packages but see the management as a voice to consider when steering the project.
Agile team: The agile team has a clearly defined decision autonomy. This should vary from product to product, as dependencies and company-specific constraints can make a generalizable approach difficult. The team should, either way, have clearly defined interfaces and autonomy in design changes within specified boundaries. Additionally, the team could receive a spending budget and the freedom to choose suppliers themselves to allow for quick procurement without lengthy approval processes.
Role of the customer: The customer is in direct contact with the Project Manager / product Owner to define what adds value.
Team empowerment: The team has the responsibility of breaking down the prioritized requirements into tasks, estimating the time for each task, and finally allocating the tasks to the team members.
Moving forward
Most case companies are still in their early stages of implementing agile. Though there were initial challenges, all companies planned on extending their use of agile, some even beyond product development. This is because soft benefits were experienced relatively quickly, such as improved communication and transparency of progress. However, whether hard benefits such as shorter-time-to-market are actually materializing for manufacturing companies is yet to be determined.
More details can be found in a working paper recently published through the CTM Working Paper Series of the Department of Engineering, University of Cambridge. The study was conducted by Linus Gerdes, Dr. Rob Phaal and Dr. Val Lynch, all from the University of Cambridge.
Read the paper
Agile New Product Development in Not-Purely Software Projects. https://doi.org/10.17863/CAM.66232
This post was written by Linus Gerdes, one of the authors of the paper – visit Linus’ LinkedIn page.
