Using agile methods in traditional research projects – is that possible? Andreas Lettner, expert and agile coach at RISC Software GmbH, describes how a research project was led to success. The conditions were anything but positive. However, the use of agile methods in an ongoing project is possible and effective – even in research!
Table of Content
We, RISC Software GmbH, are a research and development company. We connect research with applications in practice. Our approach in development projects is clear – use agile methods to create individual software solutions for users that are goal and value-oriented. But how do agile methods work in classical research projects? This report presents a simple case study on how a selection of agile methods were used in a research project under difficult circumstances to achieve improvement.
One more thing: This case study shows problems that occurred in a project. Projects are carried out by people – our colleagues. And that’s why it’s important to handle the information we receive in a non-judgmental manner. We are all not machines and that’s a good thing
I received an email regarding a project where various problems are approaching. Specifically, there are concerns that the project may not be completed on time and that employee satisfaction is suffering. With this knowledge, I arrange a meeting with the project team as soon as possible.
I’m sitting in a meeting room. With me, the project team. Consisting of data scientists, developers, project coordinators, and someone from the “executive floor.” Of course, with enough distance. Corona is still around, unfortunately. I see some desperate faces and in some, a spark of hope that we can make a difference. I’m not so sure anymore. I just realized that it’s a research project. My pulse rises. My experience is limited to agile methods in customer projects in the industrial environment. How well these fit with research projects – no idea. Also, I have no understanding of the topic. I’m sitting in front of professionals – definitely not my league.
I start asking my usual questions. Mainly W-questions. Where’s the rub? Why is it there? What would you like to be different?… Gradually a picture emerges. My notes after a few minutes:
Then a short break. I look at my notes and become more optimistic. A weight lifts from my heart – they must have all noticed. I see problems and challenges in front of me that many projects have. I thank everyone for the information and schedule a follow-up meeting where we want to define the first possible measures.
The same round as a few days ago. I have brought along some suggestions, which will be discussed with the team.
Measure 1: Product Owner and Responsibilities
Until now, content coordination was taken over by a project coordinator. However, due to her involvement in research activities and the associated organizational overhead, she cannot devote enough time, so a Product Owner is appointed. The project coordinator essentially assumes the role of a stakeholder and provides a primary vision that corresponds to the research application. The Product Owner develops the product goals and requirements. Up to here, there is hardly any difference from conventional product development.
One small thing is different: in conventional projects, a Product Owner collects feedback from users and incorporates it into further product development. In a research project, this shifts to another group of people – the researchers. In our case, the data scientists. Product Owner, project coordinator, and data scientists jointly determine the further research-relevant path. The Product Owner then develops the next goals and requirements for the developers.
Measure 2: Cadences and a few associated “minor matters”
The communication within the entire team should be more focused and active. Especially necessary is a regular exchange among the subteams. We set a weekly meeting. The initial idea is a hybrid of events known to us from Scrum:
Why only 1 meeting and why every week? We want to make small changes and keep the time spent in meetings low. At least it’s easier to coordinate if only one appointment per week is scheduled.
This weekly meeting also has some “unofficial” reasons:
Measure 3: Transparency
There is already a backlog in the project with the vision until the end of 2020 and a Kanban board for both developers and data scientists together. Yet, a status is not quickly and easily ascertainable, and thus predictability also suffers regarding achieving the goals by the end of 2020.
We divide the board into several areas:
That’s it for now. The measures were jointly defined. A few days later, an initial refinement is conducted, and the existing tasks are integrated into the new process. The “weeklies” take place, and there is much discussion. Gradually, a change is noticeable. Let’s jump to the end of the year.
A lot has happened. Not in the agreed process. That was barely touched. But quite a bit can be seen in the Kanban boards. Also, today is a special day. The project is ending. Three weeks earlier than originally planned, but there are reasons that make this necessary.
The good news: the contents of the research application have been met. Barely – yes, one must be honest, but they were met. Three months ago, the team’s statement was rather pessimistic about reaching the goal by the end of December 2020! Eagerly, I conduct an evaluation and look at the metrics:
Figure 1: Cumulative Flow Diagram
The initial development speed (dotted line) would actually not have been sufficient to achieve the project objective (blue line). The measures implemented resulted in a corresponding increase in performance, which made the project’s success possible. No, of course it is not the measures that make this possible, but still the people who ultimately do the work and get involved in these attempts. The measures ultimately support cooperation.
It is also clear to see that it took some time for the speed of development to increase. This shows once again that the most important tool we have is patience. We hadn’t changed anything. It just took time for everything to settle in.
In the period from mid-October to mid-November, an extremely constant rate of development can be observed, which also clearly exceeds the average speed. The continuity is also clearly visible in the delivery rate (Figure 2). In fact, there was a positive mood in the team towards the successful completion of the project in mid to late October.
Figure 2: Continuity
Finally, Figure 3 clearly shows the weekly meetings that arise as a result of refinement and planning.
Figure3: Plateaus
However, a proper analysis also requires looking at the reasons why the project was not “performing” before the measures were taken. The reason for 2020 is clear – corona. We were also affected, as we handle a not inconsiderable number of customer projects, which led to short-term fluctuations in capacity. But one thing is clear from this example:
Agility and motivated and committed employees create resilience against coronavirus. Even in research projects, where there are hardly any recommendations on how agile methods can be used effectively.
The title of the case study includes Kanban, but Scrum is still referenced in parts of the text. Of course, it is not Scrum that was used. Scrum is still a long way off here and it would hardly have made sense due to the short-term nature and other factors.
Why is it Kanban? We started where we were. We introduced small changes and monitored them. We ensured transparency. We created feedback cycles….
Why did we still use Scrum terms? Scrum has probably had better marketing in recent years. The terms are simply more present in many teams, are immediately associated with agility and there is also quick agreement on what is meant by them. Kanban, Scrum, LeSS, SAFe, etc. offer us a corresponding repertoire of methods that help us to handle projects in a more professional, value-oriented and human way. Ultimately, it shouldn’t matter what we call things. We just need to create the same understanding.
Head of Unit Domain-specific Applications, Head of Coaches
