In recent years, there has been a surge in interest, and generally quite a buzz, around the concept of Agile, more specifically in the use of Agile Scrum, as a project management method in new product development. All industries seem to be succumbing to the allure and mystique of being “Agile” and pressure is being felt to adopt the methodology as a “best practice” for innovation. In this article I will highlight my reservations as a practitioner, and document some of the likely challenges and pitfalls associated with Agile Project Management with Scrum as applied to Medical Technology development.

Software development teams are “Agile”. They can seamlessly convert customer problems into user stories, and then into short bursts of activity (Sprints) which culminate in something that they can test rapidly with real customers. Like Pavlov’s dogs, they log in each morning, salivating to see how their latest improvement, addition or change has been received by a willing, or at least compliant, early adopter user population. A healthy shot of adrenaline to fuel the fervour for more improvement and more rapid learning. And why not? It costs nothing, right?

That is the critical point, it costs nothing.  If a decision is made to try something new, and it is negatively received, it can be easily reversed, and a team has only forfeited a couple of days. In fact this rapid experimentation demands less rigour in planning as oftentimes the team happens upon surprise results which point them in a new direction. Long-term planning is an anathema to this new, nimble system. Long-term planning restricts and confines the ability of the team to react, adapt and change. It asks you to continuously refer back to assumptions made seemingly light years ago, before you embarked on a major phase of learning. It frustrates the teams and often kills innovation.

In a world with limited regulatory requirements, decisions can be made without significant risk to the business and if a decision is wrong, there is a low cost of change. In this world Agile is the perfect way to go. An innovative, Lean solution to the problem of inadequate project management structures for their industry.

“We must be more nimble, more agile, and able to react and change”

This success has generated a buzz which has led to a clamour to adopt Agile Project Management methods across a wide range of industries, but this is where the wheels come off. This is especially true in life science research and development but also applies to the development of most physical products.

Here are the main problems as I see them:

  1. You still need a detailed plan.

In the software world the continuous feedback loops from customer to development teams essentially dictates direction, and direction will change regularly based on learnings from the user population, hence the agility. In Med Tech, you cannot test your design iterations on real life patients (thankfully!!) without the rigour of regulated trials, therefore the results of most your experiments to test early hypotheses are likely to be learning and evidence, as opposed to absolute facts. They may point to a revision of the plan, but they in themselves are not going to determine the plan. Appropriate planning is vital to ensure you are still on course to solve the right problem and avoid building assumption into your decisions.

  1. User stories may take years to resolve.

Software developers can identify a problem, create a story, define sprints and release an update in days or weeks. Gaining closure and resolving a user need or problem in Med Tech may not be achieved until the approved product is in the hands of the end user, or in the internal organs of hundreds of patients!

  1. Sizing work is a dark art.

In software development there are far fewer “foundational” variables and the technology is consistent. Most stories can be adequately tested by flowing them through the same process (coding) whereas with science and engineering, learning will require a large number of highly variable investigative processes. Every week, a task that you thought would take 3 hours, will turn out to take 3 weeks. How do you build that level of buffer into a Sprint plan? And what if this happens to most of your Sprint tasks? It rapidly becomes unworkable and you will expend huge effort and time revising the short-term plan and keeping it current.

  1. The sprint window will not make sense.

For the IT sector, one-two week sprints tend to be the norm, solely due to the fact that the work can be subdivided into chunks that suit this cadence of iteration. Scientific research will regularly present you with bodies of work that will take weeks to complete, with activity split unevenly between the weeks. One option might be to split each experiment into convenient bite sizes to suit the Sprint window, but in reality this will not make any sense to the researcher, and you will only be doing it to maintain your system. Moving to longer Sprint windows is also an option but now you are creeping back to the days of yore and conventional planning methods (longer, less frequent meetings).

  1. You will micromanage.

Fundamentally, product development teams in Med Tech companies are made up of highly skilled Engineers and Scientists, who have inquisitive minds and have been trained to solve problems. When you reduce their work down to the level of task management, you have put a cap on the value which they can add and are likely to have obliterated their motivation at the same time. The Project Lead will inevitably assign smaller, standalone pieces of work, for instance a HPLC test. The assigned team member will go off and perform the test, and then the Project Lead will inquire the very next day as to the outcome. The ownership of the problem will have shifted to the manager, and the role of person who carried out the test will have been restricted to executing a set of instructions as opposed to solving an important problem. This approach will devastate team ethos, restrict personal development and make your team run for the door.

  1. Beware of the customer proxy.

Agile, as applied to medical technology and life sciences in general, has strayed into “Lean Start-up” territory by championing customer interaction and feedback early and often. As discussed earlier in this article, getting real customer feedback is virtually impossible for a medical device until it has completed many stages of the development process, hence the approach from many Agile practitioners to solicit as much feedback as possible from customer proxies such as physician round-tables and so on. I have even read an article which suggested that you should try to sell a non-existent product to potential clients as if it were approved and on market! I would never suggest that talking to potential customers is a bad thing, but I would definitely caution against over emphasizing the importance of the feedback as it is not a real life situation. There is a big difference between “would you buy this?” and “will you buy this?” and by placing too much credence on this type of feedback it is entirely likely that a key decision could be made on false premise and assumption.

I strongly believe that some elements of Agile, judiciously applied in the right environments, have real merit, and represent innovation in project management and product development. It has solid Lean credentials; however, it is worth noting that many of the successes to which Agile has been accredited, are really just foundational elements of Toyota’s Lean Product Development System, and have been around for decades (take multi-disciplinary teams, product managers, visual planning and management, daily huddles etc. etc.). This doesn’t really matter, a good idea is a good idea and it is a moot point if Agile is a repackaging of Lean. The bottom line is that the truly new elements of Agile Scrum, such Sprint workload management and user stories, were creative solutions to particular problems in a specific industry, and they do not work at all well in life science product development. Project managers should be fully aware of it as a method, and should understand why it works so well in certain circumstances, but should not feel a need to implement it in any stringent form. The one caveat I would highlight is if there is a software component to the technology you are creating, you should definitely consider Agile Scrum to manage that part of the project, particularly if there is an external partner who will probably expect it.

The people who created Agile were themselves innovating their processes to develop a “right-fit” for them and this is the challenge that faces Med Tech companies right now. What is your Agile? What will allow you to innovate at speed, while minimising risk and ensuring the highest quality? My opinion is that you should focus on excellent Lean management of decisions with high impact AND a high level of knowledge gaps, and use the learning needed to close these knowledge gaps (and make such key decisions without assumption) to form the basis of your plan. Applying appropriate structure to making your key decisions will allow you to rigorously test the level of assumption and drive you to eliminate project risk, and this will increase your speed and predictability. Trust yourselves to figure this out. Who better to innovate process than innovators themselves? Create your own paradigm shift and don’t rely on someone else’s supposed best practice.

If an Agile practitioner darkens your door my advice would be to turn them around and invite them to sprint off in which ever general direction they may choose. Anywhere but here…..