Laboratory automation development is a field best characterized by its interdisciplinarity. In addition to their expertise, engineers (be it mechanical, electronic, hardware or software engineers) must have a deep understanding of biological processes, and vice versa. Only when both sides understand each other can productive dialogue truly take off.
Project managers must therefore find the right balance for structured coordination and personal responsibility. To facilitate this, HSE•AG CTO Konstantin Lutze adapts agile methods to tackle the interdisciplinary needs of laboratory automation. We interviewed Mr. Lutze to understand his process.
Mr. Lutze, life sciences and engineering are two very different disciplines. How can their different approaches be reconciled for the development of automated solutions?
"It is absolutely true that biologists and engineers approach problems in very different ways.
While biologists try to delve into the complexity of nature as deeply as possible, one layer at a time, engineers build their developments from the bottom up, based on the laws of physics. For example, biologists know that a certain step requires a temperature of 60° Celsius. However, for their design, engineers are more interested in whether an accuracy of one degree is sufficient or whether the temperature must be accurate to a tenth of a degree. Mutual understanding is very import - and to reconcile these two ways of thinking and proceeding. Engineers must be as interested in the biological processes as biologists are in the technological parameters.
This is why we have people who build bridges on both sides – system engineers who have worked in biology and system analysts with background in chemistry or biology who have studied engineering."
How does mutual understanding pay off in the projects?
"Let’s take a typical example from the lab. For a human experimenter, decanting a liquid supernatant is a simple, everyday procedure. But from the perspective of an engineer, this step is extremely complex. It is almost impossible to reproducibly automate it. To avoid this, biologists and engineers need to work together to create a different process workflow. This requires close communication, which is only possible if there is mutual technical understanding and mutual appreciation.
The key factor for success, however, is a mutual technical understanding, especially at the very beginning. If the engineers in the lab “look over the shoulders” of biologists and chemists to understand the entire process, they need to be able to have a say. If they ask specific questions and understand why individual steps are carried out in that particular way, this phase can result in simplifications that considerably increase the efficiency of the system."
Laboratory systems usually combine many different technologies. How can the project management ensure that all disciplines work together optimally?
"What is known as concurrent engineering is probably the biggest challenge in development projects. We have continually optimized our approach over the last 20 years. We now base this on agile methodology, which we have derived from software engineering and adapted to the specific needs of instrument development. In essence, it’s about creating viable versions as quickly as possible, which are then completed and improved in iterations as we move towards the design objective."
Iteration cycles of one to two weeks are common in software development. Is this kind of interval realistic in instrument development?
"A time frame of one to two weeks doesn’t work in an environment where components not only need to be designed, but also procured or even specially produced. We work in four-week iterations. Even this may seem to be too fast a tempo because many processes take longer. This is where our experience comes into play. You need to define the work packages appropriately. Whenever possible, we perform partial mini- integrations per iteration of implemented functionality – and learn! Longer tasks we break down to fit to the iteration heart-beat. For example, the iteration objective could be that all subsystem components are drawn and ordered and chemistry has to decide on certain compounds."
What are the benefits of monthly mini-integrations?
"Firstly, design errors become visible very early on, which means that less work is needed to correct them. Secondly, we can quickly determine why an objective has not been reached and take any steps that are needed. We always notice a big difference when we bring together the results of the various teams after four to six months in a major integration phase. This is precisely the phase when most projects exceed their timelines. Instead of just two weeks, as in successful agile projects, it often takes several months to combine the components, because many areas need to be improved. If the system is only integrated in a half-yearly cycle, then all of the difficulties remain in the dark for six months."
How do your agile methods impact collaboration within and between teams?
"Firstly, an agile approach gives each individual responsibility for their work packages, in which they define the objectives. Secondly, the team as a whole always has a certain duty. It is only when everyone supports each other that the common objectives can be achieved. Taking an iterative approach means you’re following a common, methodical and continual learning process. And that essentially defines a development project.
On our way to developing a new instrument, we frequently find ourselves in unknown terrain. The methodology enables us to coordinate the learning processes of all stakeholders and use the synergies of our know-how in the best possible way. Last but not least, this is also beneficial for the motivation of each individual in the team."
To what extent does your agile methodology increase motivation?
"Sprint review meetings take place, for example. In the meetings, we don’t just show what didn’t work – there’s a strong focus on what has been successfully implemented. This means everyone sees the ongoing progress. If someone is facing a difficult challenge, they are not alone and can rely on the support and experience of others. This also means that not only technical challenges are handled in a systematic way.
In retrospectives, we also regularly discuss how we can further improve our teamwork. From my point of view, motivation plays an immensely important role in the agile approach. Motivated employees put more thought into things and think more creatively, and that is essential when solutions are needed that go beyond simply implementing standards."
Do the approaches differ for smaller projects and complex projects where many teams need to be coordinated across multiple sites?
"The methodology is essentially the same for both complex and simpler projects. Larger projects are usually composed of several subsystems, each of which can be treated as its own small development project. This requires an additional layer of coordination. It is important in these parallel processes that the subsystems are run as self-contained units. This is necessary because otherwise the number of communication partners explodes and the developers have to spend more time reporting to each other. I’ve seen project teams that actually spent three out of five workdays on nothing other than communication."
In your opinion, what are the most important tasks that the client needs to fulfil for a development project to be successful?
"There are three important things, a client needs to consider:
- 1. Firstly, before the project is even launched, the client needs to be clear about what their objectives are and these need to be written down in a clear and concise way. This is not just a compulsory exercise – it is absolutely crucial to the success of the project. The various stakeholders need a common vision to ensure that everyone thinks and acts along the same lines.
- 2. Secondly, the client needs a project owner who has decision-making authority and sufficient domain knowledge. In my experience, pure project managers without domain knowledge do not really function as project owners in our environment. They lack the know-how needed to assess the work and give direction. The inevitable consequence is that wrong decisions are made.
- 3. The third point concerns the project timeline. Managers in other areas may be used to pressure and unrealistic timelines leading to better results. But in complex development projects this can be fatal, because people don’t think faster when they are under pressure. On the contrary, it means that better solutions are not pursued because they don’t fit into the tight timelines. If the quick fix that is chosen turns out to be a dead end, it’s too late to do it all again and the next presumed shortcut will be taken. The project then ends up in a downward spiral.
Incidentally, the main reason for unattainable and, thus, demotivating objectives is often that budget projections and timelines are set too early. A robust, risk-based evaluation is only possible after what is known as the Design Input Lock, when the requirements from the marketing team have been finalized, their feasibility has been demonstrated by the development team, and they have been aligned and reduced to the absolutely necessary requirements."
Do you have any guidelines for reducing requirements to what is absolutely necessary?
"The objective of the first product version should be the so-called minimal viable product. It should be limited to key customer needs, but it must also function properly. Teams that restrict themselves in this way can bring products to the market much faster, which is crucial in today’s competitive environment. It’s important that the first version also has a clear roadmap showing how the product’s functionality can be continually expanded.
The equation is simple: the more functions that are built into the first version, the greater the number of sources of error.
I once observed the development of an instrument that was designed as an absolute masterpiece of technology and covered every conceivable need. However, the enormous complexity led to a large number of failures among early users. These days, no company has time for that and ingenious instruments quickly become forgotten about.
Our responsibility is to always challenge the client and ask whether each of the planned functions is really necessary. In the same way, we also alert the management board when we realize that the project lacks a common vision. This benefits us, too, because we usually commit ourselves to a fixed cost and time-frame based on the Design Input Lock."
If you found this article interesting, you might also like:
