Agile Medical Device Development: Do or Don’t?
Process aspects
In this article we highlight two important differences between traditional organizations and agile organizations. These two process-oriented aspects demonstrate that working agile requires a different view and therefore a different approach to the same problem. These aspects are:
- Flow
- Cadence and Synchronization
This article is the second of three articles explaining the differences between a traditional way of product development and a more agile way of product development. These articles are based on a survey conducted on agile product development with medical device companies. The previous article on organizational aspect can be found here.
1. Flow or slow
A couple of weeks ago I was on my way from the airport to a conference venue, where I was up to present at 9:30 hrs. In the taxi I asked the driver how long it would take to get to the venue. He answered that it is very busy on the road with several traffic jams, so his estimate was that it would take about 50 minutes to get there.
The only thing the taxi driver mentioned was the traffic jams (delays). He did not mention what the top speed of the car is or what the maximum speed on the highway is. He did not mention that he is an amateur race driver with good driving skills. He didn’t mention the road conditions – wet or dry tarmac – Why did he not mention any of this?
The taxi driver knew from experience that none of these aspects would make a substantial difference to the overall time to get to the venue. He knew that the traffic jams – delays – are the main influence on the time to reach the destination.
What is lead time?
Simply said: Lead Time = Waiting Time + Processing Time.
In the example of the taxi driver the lead time is the actual time from getting into the taxi at the airport to getting out of the taxi at the venue. The processing time is the time the taxi is actually driving, and the waiting time is the time the taxi is standing still as a result of traffic jams.
Value Stream mapping
Let’s take a deeper look at applying lead time to business processes. As an example, you see below the process and steps needed to go from a request to implement a feature in an application to the actual deployment of it.
The above example clearly shows Waiting Time and Processing Time. The total processing time is (1 + 1 + 1 + 4 + 1 + 3) 11 hours. The total waiting time is (1 + 2 + 2 + 1 + 1) 7 weeks (280 hours). The total lead time is 280 + 11 = 291 hours and only 11 hours are needed to do the job. This results in a time efficiency of less than 4%.
The above exercise is called “Value Stream Mapping”. It is a systematic way to visualize all the steps in a process to deliver value. And as shown in the above example, most of the time in your business processes is waiting time.
How to improve flow?
Looking at the above example, what would you do to improve the process? You have 2 options to choose from: improve processing time or reduce waiting time. Let’s examine both.
Improve processing time
Let’s pick the activity with the longest processing time: “Code & test”, which takes 3 hours. Assume we realize a massive improvement and reduce it with 1 hour (33%). As a result, the lead time is reduced from 291 hours to 290.
Reduce waiting time
Let’s pick the longest waiting time, for example “E-mail Tech Lead” (and wait for an architect to become available), which takes 2 weeks (80 hours). Again, assume that we realize a massive improvement and reduce it with 27 hours (33%). As a result, the lead time is reduced from 291 to 264, a much bigger improvement than achieved by focusing on improving the processing time.
Accuracy & completeness
There is one more aspect that you may want to take into account and that is Accuracy & Completeness of the work done during processing time. If the work is not accurate and/or incomplete, it prevents the next step in the process to start, causing both rework (extra processing time) and as a result additional waiting time.
Conclusion
In traditional organizations you typically see that the focus to improve the overall process is on reducing the processing time. The most commonly used improvement is to add more resources to the task – see previous article about hand-over time.
In agile organizations we believe that people are already doing the best they can, but their performance is limited by the system itself – the waiting times in business processes.
If you want to improve your business processes, focus on reducing waiting time instead of processing time. You will improve flow so much more.
Improving flow brings another advantage to the table. It enables earlier feedback and as a result provides the opportunity to learn and make adjustments. In agile, learning is an integral part of the process. In contradiction with a traditional process where a lessons learned is done as part of decommissioning the project – to produce a report that seldomly gets read, let alone apply the recommendations –, agile has implemented learning at each iteration, enabling the continuous improvement of the teams and the solution they build.
2. Cadence, synchronization and cross-domain planning
Every development of a new or improved medical device starts with a plan. As part of the FDA’s guidance (FDA 21 CFR 820.30 (b) and ISO 13485) a design and development plan is required.
What we see happening in many organizations is that the project manager creates the plan at the start of the project. The plan is worked out in a great level of detail, so the plan is regarded thorough and well thought-out.
The plan
I don’t know about your plans, but mine seldom go the way I was expecting them to go. Along the way, all kinds of things pop-up which I didn’t foresee at the start of the project. And this isn’t strange because at the beginning of a project you have limited knowledge and experience. You may have a few hypotheses and assumptions, with no evidence or assurance that these are achievable. In terms of deadline, number of resources required, total cost, etc. anything you provide is an estimation, however management will often interpret these as certainties and commitments, causing a rigid control of the plan and eliminating any flexibility.
An administrative nightmare and low commitment
The other thing we see is that the project manager creates and manages the plan. He will ask input from all stakeholders and may even involve them in the initial plan. In addition, he works out the plan in a lot of detail, creating the impression that everything is well thought-out and carved in stone.
There are a couple of problems with this approach. As the project manager creates and manages the plan, it will be HIS plan. The teams in the project will feel this as something that has been forced on them. It isn’t their plan and as a result they will feel less committed to it.
In addition, because the plan is so detailed, it becomes an administrative nightmare to keep it up to date with reality. I have seen cases where project managers have stopped updating the plan, due to the number and frequency of changes. It’s hard to stay on track when the track is gone.
Planning is a regular effort – not one-time only
In a Lean-Agile world a different approach is taken towards planning. First, Lean-Agile takes changes to the plan as a blessing instead of a curse. Change is based on new insights and learnings and therefore an opportunity to steer into the right direction and make the outcome better. In order to achieve this, Lean-Agile sees planning as a regular activity that is executed in a certain cadence – for example every 10 – 12 weeks (quarterly). This enables a review of the previous phase and learn from it. In addition, it enables to adjust because of new developments and/or priorities.
Planning is a team effort – not one-person only
In Lean-Agile the plan is not owned by the project manager; it is made and owned by the teams. In a cross-domain, big room planning meeting, all team members (as much as possible) and stakeholders are present to make a plan for the next 10 – 12 weeks. The teams base their plans on their estimation of the size of the work and the capacity they have available to do the work (velocity). In addition, they will identify cross-team dependencies and resolve those through face-to-face contact between the teams involved. As a result, they synchronize their team-plans to ensure the overall plan is achievable. Finally, they will identify risks and mitigations to minimize impact on the plan.
When planning becomes a team effort, the teams own the plan and are much more committed to deliver according to their plan. In practice we see the teams overachieving on their plans.
Conclusion
Cadence creates predictability and provides a rhythm for the organization. Synchronization causes multiple perspectives to be understood, resolved, and integrated at the same time. Applying cadence and synchronization, coupled with periodic cross-domain planning, provides the tools needed to operate effectively in the presence of uncertainty, inherent in medical device development.
