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!
Contents
We, RISC Software GmbH, are a research and development company. We combine research with practical applications. Our way of working in development projects is clear – we use agile methods to create individual software solutions for users in a goal- and value-oriented manner. But how do agile methods work in traditional research projects? This report shows a simple case study of how a selection of agile methods were used in a research project under difficult circumstances in order to achieve an 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 that we handle the information we receive without judgment. None of us are machines and that’s a good thing.
I receive an email regarding a project that is experiencing various problems. Specifically, there are concerns that the project might not be completed on time and that employee satisfaction is suffering. Knowing this, 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”. With enough distance, of course. Corona still exists, 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’ve just discovered that it’s a research project. My pulse is racing. My experience is limited to agile methods in customer projects in an industrial environment. I have no idea how well these apply to research projects. I also have no understanding of the topic. There are professionals sitting in front of me – that’s definitely out of my league.
I start asking my usual questions. Mainly W-questions. Where does the shoe pinch? Why does it pinch? 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. It’s a load off my mind – I’m sure you’ve all noticed that. I can see the problems and challenges that many projects face. I thank them for the information and arrange a follow-up meeting to discuss the first possible measures.
The same round as a few days ago. I have a few suggestions in my luggage, which will be discussed with the team.
Measure 1: Product owner and responsibilities
Up to now, a project coordinator has been responsible for coordinating the content. However, as she cannot devote enough time to research activities and the associated organizational overhead, a product owner has been appointed. The project coordinator takes on the role of a stakeholder, so to speak, and sets a primary vision that corresponds to the research proposal. The product owner develops the product goals and requirements. Up to this point, there is hardly any difference to conventional product development.
One small thing is different: in conventional projects, a product owner collects feedback from users and incorporates this into further product development. In a research project, this is shifted to another group of people – the researchers. In our case, the data scientists. The 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 related “little things”
Communication within the entire team should be more focused and active. Above all, a regular exchange between the sub-teams is necessary. We set a weekly meeting. In terms of content, the initial idea is a hybrid of events that we are familiar with from Scrum:
Why only 1 meeting and why every week? We want to make small changes and keep the time spent in meetings to a minimum. At least it is easier to coordinate if only 1 meeting per week is planned.
But this weekly meeting also has some “unofficial” reasons:
Measure 3: Transparency
The project already has a backlog with a vision for the end of 2020 and a Kanban board for the developers and data scientists to work together. Nevertheless, it is not possible to quickly and easily determine the status of the project, which means that it is difficult to predict when targets will be achieved by the end of 2020.
We divide the board into several areas:
That was it. The measures were defined together. A few days later, an initial refinement is carried out and the existing tasks are integrated into the new process. The “weeklies” take place and there is a lot of discussion. Slowly, however, you notice a change. Let’s take a leap in time to the end of the year.
A lot has happened. Not in the agreed process. That was hardly touched. But a lot can be seen on the Kanban boards. Today is also a special day. The project is coming to an end. 3 weeks earlier than originally planned, but there are reasons that make this necessary.
The good news: the contents of the research proposal were fulfilled. Barely – yes, you have to be that honest, but they were fulfilled. Three months ago, the team’s statement was rather pessimistic until the end of December 2020! I’m excited to do 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 easy 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 clearly exceeds the average rate. 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.
Figure 3: 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 sensibly.
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.
Chief Product Officer,
Head of Unit Domain-specific Applications
