Agility in R&D is as a key component in New Product Development, particularly where speed is required to capture market opportunities – time is money. But perhaps the main challenge facing R&D managers is hitting the sweet spot in the marketplace, where delivery of functionality and quality matches customer needs and requirements.

The STIM consortium operated by the Institute of Manufacturing provides a forum whereby R&D managers can discuss issues of the day. A survey of companies attending STIM events through 2019 and 2020 showed that there is growing interest in the application of Agile project management processes.

In particular, discussions amongst the companies revealed that more guidance on the types of projects where an Agile approach is more suited was of interest.

This paper, by Valerie Lynch,  looks at this issue and begins with addressing a fundamental question. What is Agile?

‘What do you understand by Agile?’

This question was asked of 25 companies attending the STIM consortium and, maybe unsurprisingly, the answers differed according to context.

‘Development process used by our software team’ was the most prevalent answer but other answers included rapid prototyping, the use of SCRUM and LEAN methodologies and formation of teams selected for the project on the basis of their skill set.

Whilst the detail of the answers may have differed, the common thread was that agile was most frequently used in projects where boundaries of the work to be completed were at best flexible and at worst unknown.

There are many reports from industry that agile processes bring benefits when applied to software projects, but software is a flexible technology, it can easily be changed and new versions constructed. The question arises ‘what facets of the processes give rise to these benefits and can these be applied in non-software projects?’

Agile principles and practices

In 2001 a group of individuals, all experienced software engineers, identified 4 principles and 12 practices they agreed as being key elements in the quest to uncovering better ways of developing software and  published these as a manifesto.

The four principles are described through contrasting left and right statements. The manifesto recognises the value of the right statements but proffers the view that there is more value in the left statements.

The four Agile principles are shown in table 1 below.

Which statements are applicable to your company?

So, to explore the applicability of Agile to R&D in general, these principles and practices were presented to 35 R&D professionals within 20 companies and feedback obtained.

The participants were asked to choose which of the two statements was the most applicable to their company. The feedback was analysed simply to discover the level of resonance the statements had with the R&D professionals.

For all questions greater than 50% placed more value on the left than the right, but the responses were mixed. Notably only 20% of the companies valued all on the left. Interestingly the reasons were not related purely to company context, professionals from the same company provided different answers.

The difference was related to the types of project they worked on. For example, it was reported that for some projects, early prototypes can damage brand image. This meant that although working prototypes are valuable the risks of releasing early prototypes for evaluation to customers could in some instances be too high. The development of and provision of documentation to customers instead of prototypes was in these cases important.

Perhaps most interesting the issues of control and governance were raised in relation to two of the points. Individuals and interaction, particularly with customers, was seen as important. But 40% of the professionals reported that the need to quality assure the outputs meant that control through the use of processes and tools was more important. 80% of the professionals agreed on one thing, that they valued customer collaboration over contract negotiation. However, for the other 20% governance and regulation imposed either internally or externally meant that nothing could be achieved without a detailed tight contract.

Which agile practices do you apply? 

A similar analysis of 12 agile practices, shown in table 2 below, was also undertaken. The professionals were asked whether or not the Agile practices described were applied in their company and to comment on their level of agreement with the statements. The responses were analysed to identify the areas in which there was the most and least agreement.

Stakeholder engagement

The results were mixed but all of the professionals agreed with practices; numbers 1 and 10.

It was thought that practices that encouraged continual feedback from all stakeholders were thought to be the most important to the success of a project. It was recognised that customers and stakeholders could sometimes be difficult to engage but that in general it was thought that inclusion of feedback opportunities within a project was worthwhile to minimise the risks of project failures.

It was also reported that in some instances, for example government contracts, the stakeholders were disengaged. They simply wanted to outsource the project and not be involved until it was time for a delivery.

As part of the analysis, responses from professionals were collated across all 16 key elements of the Agile Manifesto and it is noteworthy that stakeholder disengagement was found to be linked to the requirement for tight contracts.

Simplicity encouraged

Encouraging simplicity was unanimously supported, but feedback highlighted that this was possibly an area that was very technology dependent. Simplification of the design of a safety critical or a security critical component, is often just not appropriate.

The practices that attracted the least agreement were numbers 2 and 12.

It was felt that possibly practice number 2 welcome changing requirements, even late in development be more suited to software than mixed software and hardware projects.

The need to freeze designs for hardware components at stages in the design, to allow for manufacture and build, meant that late changes could often not be accommodated. The limiting factor was thought to be component cost. Whilst hardware and product simulation has meant that risks could be minimised within hardware design, it was still costly to build product and the time for builds needed to be factored in.

Practice number 3 deliver working software frequently attracted less votes for this reason. Frequency of delivery is limited where hardware is involved because of costs and time. In addition, it was noted that often contracts were negotiated with specific delivery schedules in mind and therefore for some projects practice number 3 was just not relevant.

With reference to practice 12, time for reflection, 50% of the professionals felt that this was not built into their company practices. All however thought it would be a good thing.

Benefits and drawbacks of using Agile in projects

Of the 20 companies providing input to this research activity, 16 had, or were in the processes, of adopting Agile processes within their project work.

Advantages, such as rapid feedback through prototyping and visibility of new product development featured highly. All of the companies were keen to continue with the development of their Agile processes but they all reported drawbacks and issues with implementation.

Much of the feedback focused on the need to ‘Get Managers on Board’ with the idea that work could be progress without the need for fixed specifications or fixed deliverables.

Stage-Gate is a well-known process for controlling project development and combining this with Agile provided some companies with a way forward. However, companies found it difficult to align incumbent processes with the lighter weight processes employed in Agile.

Improving visibility and communication between development teams and managements

The adoption of the practices 4, 5 and 6 has resulted in the use of voices within agile development processes. The customer voice and the project manager voice appeared to be prevalent and are used for handling communication from the Agile team to the stakeholders.

Engineering voices were heard at regular stand-up meetings and as part of problem resolution. Voices were heard but the professionals reported that this didn’t generally assist in the helping managers understand problems any better than using more traditional project management methods. Reflection on this highlighted a possible issue. As implementation of practices 4, 5 and 6 appears to have led to the adoption of team responsibility rather than the placement of responsibility on one person, it is not difficult to see that governance issues can then arise.

SCRUM methodology had been adopted 

SCRUM includes the use of Retrospectives in accordance with practice 12 and conducted at deliveries and at the end of Sprints. Sprints, short delivery cycles as described in practice 3, provides visibility of work undertaken. The project manager role can provide a bridge between the team and governance bodies, reporting back to governance bodies at the end of Sprints and after Retrospectives.

However, with a focus firmly set on collective responsibility within the team, the requirements for governance was found in general to be lacking.

How does one keep control of an Agile process?

The experience of industry has led to the observation that although early prototyping may de-risk development it can also mask obstacles to reaching commercial goals. What happens if a roadblock is encountered on the 3rd or 4th iteration, the removal of which results in costs spiralling out of control? Would a more traditional approach which puts emphasis on fixing all requirements before starting development have been better?

In summary

Feedback from STIM companies during network events and through the survey undertaken showed that benefits could be gained from the use of Agile.

Breaking down Agile into the principles and practices enables companies to examine why some projects were better suited than others. Early-stage projects and exploration of new innovations were highlighted as project types that could accrue the most benefits as in these instances the level of governance required was minimal and the technology was at that stage flexible. The projects were by nature uncertain and more formal project controls were not appropriate.

It was recognised also that although for some projects Agile may just not be suited,  a mix of Agile practices and traditional practices could bring benefits.

Perhaps the most important take away is that governance appears to be ‘outside’ of the Agile sphere when it comes to implementing Agile methods for a project. Companies wishing to adopt Agile should therefore think carefully about how they will incorporate governance into the process if only to ensure that all parts of the Company are ‘on-board’ with their adoption.

Standardisation of process has been a driver within product development over many years, on reflection and to meet the differing scale and requirements of R&D maybe a shift towards developing custom processes for individual projects but based on a set of company wide principles and practices could be a way forward. The benefits of Agile could then possibly be realised more fully.

Find out more about Valerie on her contributor page.