has been performed 10 years ago could also alter these conclusions, especially the ones related to the human resources differences between HW and SW development.
Finally, it is interesting to note how, after noticing the positive impact of this approach on product development processes, other departments at Teuco demanded to try similar approaches as well. Despite the short timeframe, that did not give enough time to the author to state them as successful, the adaptation of such an approach over sales and marketing was providing surprisingly good results.
3.5 Case 5: Product Development of Medical
For this project, a team made of seven members, responsible for design, simu-lation, requirements management, and agile procedures, worked six moths at the product development. Thanks to the combination of classic and agile requirements’
management, and thanks to the adaptation of the manufacturing processes to additive manufacturing, they were able to give birth to a final product, while taking medical guidelines into account. As a result, a 3D-printed prototype was created, as reported in Figure 3.7. During the process, a new geometry to enable more cell-friendly microfluidics – required by the product’s specifications – was implemented as well, after various simulation runs.
Figure 3.7: CAD model, on the left, and 3D printed microtiter plate, on the right (Gerber et al., 2019).
Speaking of the process itself, Scrum was kept as the method at its basis, but some modifications made are worth of mention. Daily scrums were initially implemented via Slack™, an online communication tool, rather than in person.
Soon after the project started, however, they moved into video chats or on-site meetings, that proved much more efficient. Retrospectives were held with a similar structure to the original Scrum methodology ones, and provided suggestions for future improvement potentials. Among the tools used, the authors listed: user story mapping (see Figure 3.8a), Starfish retrospective (see Figure 3.8b), timeboxing, feedback pitches, and joint visualization of the share emotional perception (see Figure 3.8c).
The results of the project were evaluated by making use of the team climate inventory (TCI) (Anderson & West, 1998) – a structured self-report measure to
Figure 3.8: Sprint impressions (Gerber et al., 2019).
assess the climate for innovation within groups – and a feedback log. Firstly, it was noted how the distribution of tasks at the beginning of the project was not clear. Explicit rules turned out to be needed, in order to control the Scrum process. Similarly, also the formulation and maintaining of user stories was found to be difficult. In this case, the solution adopted was to adapt the user stories to physical product development. Continuing, the team was skeptical about the possibility to produce complex medical products within one sprint. This feeling changed throughout the project, thanks to the periodic retrospectives that boosted the team’s expectations for its own results. This trend was accompanied by an increasing need of physical presence during working hours. This lead to the a first answer for RQ-1, and provides an interesting observation on how agile product development, also for HW products, benefits from a physical presence and suffers the use of remote working. In the previous chapters, it was questioned how the modern trends and technologies, as well as a the different dynamics involved in HW development, could influence the original agile mantra according to which teams should work together in a single room. This survey seems to provide a preliminary answer to this kind of doubts. Going back to RQ-1, the authors got to the following conclusion:
Agile methods accelerate the team development process at the beginning, but the additional effort due to the new process rules is most profitable after about 3 sprints. Afterwards the well-rehearsed team can benefit from the known scrum standards and developed practices (Gerber et al., 2019).
3.5.2 Practical suggestions
From these observations, Gerber et al. (2019) elaborated a list of suggestions for future works, providing an answer to RQ-2. These thoughts have particular importance in the agile development of medical technology:
• Shorter sprints and a division into pre-phase, iteration-phase, and final phase are recommended.
• Research, interviews, and joint workshops on the topic would be urgently needed before the actual development. This would allow consensus to be built on the goals and vision of the project, technical knowledge, boundary conditions of the product, a common picture of the end-user of the product, and primarily an understanding of agile methods.
• The approaches of Design Thinking could be used to align the project goals and vision.
• The iteration phase should have the structure of a sprint/Scrum. Innovative solutions for partial problems can then be systematically developed.
• To select the documentation and technique level during a sprint, the sprint missions should be used.
• In order to keep an eye on both technical requirements and user needs, personas should be used. Their use allows evaluating the work results from the preliminary phase.
• It would make sense to coordinate the final phase independently of the regu-lations and sprints. This would make possible to adapt the documentation to the requirements of a previously untreated risk and quality management system, and thus meet the most important requirements of medical technology product development.
• The length of the final phase should not exceed one to two sprint lengths.
The above suggestions refer to the process identified by the authors as a possible solution for agile product development of physical products, reported in Figure 3.9.
The process is not analyzed in detail in this section, as its further evolution will be discussed in Section 3.6.
The project results were overall satisfying. Prototypes were printed with additive methods and simulation models. Sprints lasted four weeks, and enabled a sort of product development process that very much resembles the one encountered in the
Figure 3.9: Recommendations of an agile process for physical product development (Gerber et al., 2019).
SW domain, with frequent adaptations due to changing customer requirements.
The following section will analyze a second case study reporting further development of this methodology.