A Conversation with Pierre Vancaillie on Applying Rapid Iteration for Agile Product Development

Pierre Vancaillie Presentation
Pierre Vancaillie presenting agile at AACC

Invetech has adopted agile methodologies for in vitro diagnostic (IVD) instrument development, transforming the product development process to achieve more resolved product solutions, improved development predictability, and consistency in meeting development schedule targets.

This article is a continuation of our three-part series featuring discussions between Rob Danby (Vice President of Diagnostics at Invetech) and Invetech team members sharing their insights and learnings from applying agile methodologies to instrument development projects. In this article, Pierre Vancaillie discusses rapid iteration—one of the three key elements of the agile process.

Rob Danby: Pierre, can you please tell the readers a bit about yourself, your role at Invetech, and your personal experience using agile for product development?

Pierre Vancaillie: Sure. I have a mechanical engineering background and have been involved in the development of medical and diagnostics products for over 10 years.

Currently, I oversee the mechanical engineering and industrial design teams at Invetech’s San Diego office.

My experience with agile goes back quite a way, but during the last two or three years here at Invetech we have really started to create our own unique way of applying agile principles to the projects we undertake. Before joining Invetech, I had been involved in projects that used the idea of rapid iteration; however, it was more of a way to trial different concepts quickly, rather than a development approach. The benefit of the way it’s used at Invetech is that we also use the agile approach and rapid iteration to evolve a product throughout the design phase, from initial concept all the way to a working functional system.

Rob: Can you describe the concept of rapid iteration as it applies to agile product development?

Prototype created to get feedback from project stakeholders

Pierre: The concept of rapid iteration, as the name would imply, is about creating physical prototypes as quickly as possible and iterating on those as quickly as possible. These prototypes should be made central and visible to the development team, encouraging daily interaction and involvement from all stakeholders. It’s really about creating something tangible that can be used, not only as a communication tool, but also something that allows early and frequent feedback to project stakeholders. Identifying potential flaws in the concept designs as soon as possible helps to eliminate the waste of refining a flawed approach. We often refer to this as “try early, fail early, learn early.”

Rob: How does this rapid iteration approach differ from a more traditional product development approach?

Pierre: Typically, in a traditional “waterfall” approach, what would happen in my experience is that project plans would be created so that system-level prototypes would come together at two or three points within a project timeline. We term these points in time “big bang integrations.”

In using this approach, it’s usually a huge effort to get a whole system up and running. Typically, you could have three or four months, or maybe even longer, between these big bang integrations and you’re not really learning much about how well you’re meeting the user’s needs in the down time. This means you really only have two or three times in an entire project to redirect if you’re going off course.

With the rapid iteration approach, a system is usually broken down into functional subsystems which are developed through repeated cycles (iterations). The number of iterations of any given subsystem can be based on the risk or complexity, and different subsystems can mature at different rates.

Sometimes some subsystems can be very complex, so you actually need to iterate them more often. Other subsystems will be quite a bit simpler, and you’ll get them right the first time. Being able to plan the development of a system based on iterating the subsystems contained within it according to their complexity or risk is a fundamental difference between typical waterfall development and agile development. Iterating things quickly and often so that you can redirect much earlier if you discover that you are veering off course usually, I find, creates much more confidence in a project’s timeline.

Rob: Why has Invetech adopted this agile approach to instrument development?

Pierre: I think one of the main reasons is improved project predictability, but also improved communication. The transparency and communication that the agile approach facilitates is very, very important, especially here at Invetech where we have a lot of clients that aren’t necessarily on-site with us all the time.

We can use rapid iteration in prototypes and mock-ups to communicate where we are currently and where we’re heading in the program, and our clients really like to see that. Because you’re taking smaller steps with agile, both the Invetech teams and our clients are able to better understand and appreciate where the project is at any point in time without having to wait for the next big bang integration.

Rob: Many teams already use prototyping as part of their product development process. How is the agile approach with rapid iteration different?

Pierre: The agile approach of rapid iteration is different than traditional prototyping in that you use anything to make a prototype and you do it as early and often possible to prove functionality and test things like performance and robustness. When you’re first starting on something, the prototype can be as simple as a piece of cardboard to describe the shape and size, or it can be a piece of foam core with something printed on it.

On a recent project, we built a chassis for quite a large floor-standing instrument before we knew all the details of what the chassis needed to be. We put some foam core together to represent the general structure of the chassis and placed it in the middle of the team area. Engineers would walk by and start asking questions. They would even use Post-it notes to write down their comments and stick them straight onto the foam core mock-up with suggestions for improvement, or to share things that they liked or didn’t like.

The mock-up was being used as a communication tool and we were getting a lot of valuable information and suggestions from the team without needing to have more traditional reviews. Although reviews are still very important, the mock-up allowed the team to start understanding what the instrument would look like even before we had fully defined all of the details. That initial foam core prototype slowly morphed into a full metal chassis that was fit for purpose in a much shorter time frame than would otherwise have happened.

Rob: What were some of the initial challenges that your team experienced when adopting agile for product development, and how were those overcome?

Pierre: The core concept of rapid iteration is trying to do things as early as possible. This can mean creating prototypes before you have all the information you might typically expect to be available. For example, the functionality might not be fully defined or the requirements may not be fully formed yet—this can be uncomfortable for some members of the team. Designers and engineers usually want a black and white definition of what the design needs to be before they get into building something, whereas agile kind of flips that on its head. It is a challenge, especially for designers and engineers, to accept that things don’t have to be completely defined before they can start to be built.

Personally, the way that I saw this approach when I was first introduced to it was that it seemed inefficient. It was, in my mind, planning to fail, and I was uncomfortable with that idea. Becoming comfortable with failing, was one of the biggest challenges for me personally, and I know that others feel the same when they first start to use this approach.

Rob: As a manager, do you have any advice for when people are unfamiliar and therefore uncomfortable with this new approach that will help get them on board?

Pierre: We’re lucky here at Invetech to have a lot of experience in the application of agile principles. Therefore, if people are uncomfortable I’m able to demonstrate some recent examples and just talk through the process and reasoning. People usually like to understand the “why,” so explaining the reasons behind the change and the philosophy of agile make the transition much smoother. As soon as people start to see the benefits, their original apprehensions tend to fade.

Rob: In your opinion, what have been some of the biggest changes or improvements that you’ve experienced since adopting agile methodologies?

Pierre: For me, the biggest change has been the improvement in communication throughout the entire development team. It’s amazing to see how something tangible such as mock-ups and mechanisms placed in the common workspace can create a lot more buzz than having everything kept on a screen. Seeing something on a screen doesn’t really mean that much for a lot of people; whereas a physical prototype will engage and involve a lot more of the team in everyday discussions, as well as facilitate team consensus and understanding.

Rob: For other companies looking to adopt agile principles for product development, what advice would you offer to help them get started?

Pierre: Don’t let “perfect” get in the way of starting. Try building mock-ups and prototypes at any level that you can, and then iterate them often. Seek as much feedback from all the stakeholders that you can: clients, manufacturing engineers, service engineers, the marketing team…get everyone involved!

Rob: Do you have any further lessons learned or pitfalls to avoid that you would share with other companies looking to adopt agile principles or a more customer-centered design approach?

Pierre: My biggest lesson learned would be to be conscious of the fact that this can be a big change, especially for the designers on your team. It is a different development approach to what most people are used to. Having “failure” built into the program schedule can be confronting. Given it is a big mindset change, start implementing slowly. Select a few aspects of agile development that make sense for you and your team and then slowly build on these over time.