+49 (0) 89 58803-1000

Switching From Waterfall to Agile in an Ongoing Project

Agile Transformation. This phrase is being used a lot at the moment. Higher management wants to switch their companies from a classical, waterfall-based environment to an agile one, mostly leaning to Scrum. And there are good reasons for such a step: more flexibility, higher transparency, more customer focus, and, above all, a business-culture, which is both – more productive and more suitable for today’s modern working environment at the same time.

The Switch in Practice: How to Change your Working Model?

But how does to fulfil such a switch? Which steps are necessary for transforming a waterfall organisation into an agile one? Those questions are a tough nut to crack, even more so if you have to make the necessary changes within the context of ongoing projects without interrupting development processes. The suggestions for performing such a change are legion. Many authors and consultants make it sound easy. You just have to take a recipe from a cookbook and ‘flip the system’ from one day to the other. As I am convinced that there is no such recipe, this article does not want to lay out yet another ideal path. Instead, its goal is to share an experience of such a change and to motivate readers to think outside the usual project management toolbox in order to find solutions for adapting the new working model to the projects environment.

The first question I want to focus on is the one about the right time for the switch. The second question I will address is how the collaboration between business and IT can be optimised during the change process. Thus, there are lots of issues concerning the change from waterfall to agile that will not be touched within this article although they are vitally important. For instance, I will not write about the cultural changes or the changes in roles necessary for the switch.

An Example for a Successful Switch: The Setting of the Project

As I mentioned earlier, the following experience is not aimed at giving a recipe for the agile transformation. Rather, I want to tell a success story about a project that successfully managed to switch from waterfall to agile.

The starting point was one that could be characterised typical for many an agile transformation. Higher management ordered the lead of an IT-project with a high technological complexity to modify its workflow from a classical model into Scrum. The project was still in its starting phase, meaning that concepts were still drawn up and implementation had not yet begun. Everybody involved agreed that business and IT should work closely together within an interdisciplinary team. It is necessary that responsibilities within that team are clearly defined.

The ‘Right’ Time to Switch

Within the context of the project I was involved in, we had to decide when to initiate the change. As the project was still in its starting phase, we could identify two windows of opportunity.

The first was after the creation of a structural plan for the project that compiled all the functions that should be delivered (function-based PSP). This solution seemed applicable to us as a function-based PSP already focuses on the rough functionality of the project´s product. Thus, it was possible to break those functionalities down into the description of Epics, which are a higher-level version of User Stories (short phrases that are used to present the customers’ perspective on deliverables within projects). Those Epics could in turn be themselves be broken down into User Stories.

The latest practicable window of opportunity we identified was after the creation of the system design (a comprehensive map of all the functionalities and the architecture of an IT project). This system design could be broken down into features. Those features could then be formulated as Epics or User Stories. The challenge here would have been to find a way for identifying the smallest entity of those features, so that they could form MVPs (Minimum Viable Products) in order to stick to the principle of lean development.

Both these possibilities seemed practicable points in the progress of a project to switch the applied toolbox from waterfall to agile as they both provide the opportunity to be broken down into User Stories or Epics. A later point would have been a lot more difficult. Why? Because then implementation would already have started, which would make it hard to roll back and redefine requirements.

Cooperation in Practice

Both alternatives, however, demand very close cooperation between business and IT as the process of fragmenting a function-based PSP or system design into Epics and User Stories is both: essential and challenging. Also, it bears a huge potential for conflict.

The way we chose to avoid conflict and to guarantee cooperation was somewhat unorthodox – at least speaking from the perspective of strict agile or classical project management rules. We decided to create two different backlogs: a business backlog and a technical backlog.

In the business backlog one could find the business related User Stories, which contained the needs and wishes of the end user. While writing those User Stories business had a sparring partner from IT to ensure the technical feasibility of the User Stories, to achieve a high quality of the MVP, and to keep the IT side up to date.

The IT backlog contained User Stories from a technical perspective (e.g. IT-security, quality and integration in IT landscape, etc.). As the writing of User Stories from the IT perspective required a high degree of technical understanding business was not involved in creating the IT backlog.

Those two backlogs were the foundation for an overall product backlog which united User Stories from the IT and business perspectives. Thus, User Stories from both sides were considered in Refinement Meetings and Sprint Plannings where business and IT both had the opportunity to estimate, prioritize, and pull items into the sprint backlog so that they could be implemented.

Both sides, business and IT, were satisfied, as they were able to voice their concerns and to map their requirements to the new project management structure.

Think Outside the Box and Find Your Own Path for the Switch

The path we chose to change the project management structure from waterfall to agile was successful. We were able to find a way to make all parties concerned happy and, even more importantly, to keep the project going. In the end, the two key success factors were finding the right time for the switch and to guarantee a close cooperation between business and IT. The first was a rather analytical decision: at which point could we break the projects content down into smaller user stories. The second decision was an intuitive one. Agile theory usually forbids the creation of two backlogs within one project or product environment. However, for us it seemed absolutely necessary to give both sides the possibility of voicing their concerns.

As I have mentioned before: This story does not want to give you detailed instructions for performing the switch. Instead, by telling this story I wanted to motivate you to think outside the box and find your own solution. At TEAMWILLE we have experts that can support you in doing just that.

Leave a Reply

Informationen zur COVID-19-Situation:

Trotz der aktuell geltenden Beschränkungen wollen wir Dir weiterhin hochwertige Trainingsangebote bereitstellen.
Dafür haben unsere Trainer und Trainerinnen das Programm für unsere Präsenztrainings auf virtuelle Klassen umgestellt.

Nutze die Zeit im Homeoffice, um Dich um Deine Weiterbildung zu kümmern. Wir sind für Dich da.

Bei Fragen, auch zu bereits gebuchten Trainings, erreichst Du unser Trainingsmanagement jederzeit gerne.
Schreib uns einfach eine E-Mail an training@teamwille.com.

Wir freuen uns darauf, Euch bald wieder persönlich in unseren Trainingsräumen begrüßen zu dürfen.

Bleibt gesund!
Euer TEAMWILLE-Trainingsmanagement


Hier geht es direkt zu den nächsten Trainingsterminen