Agile transformation in IT projects

Agile Waterfall Hybrid

Companies are increasingly trying to implement IT projects in Agile. Agile is a whole methodology in project management and encompasses common practices, such as SCRUM or XP (Extreme Programming). Reasons why companies want to carry out their projects more agile are obvious: more efficiency, faster processing and presentable results, more control whether the delivered corresponds to what was desired. Sow more interaction between the stakeholders, the project sponsors and the proje
ct team. However, this is a disaster in many cases, because companies are struggling with a radical change. Most of the time it is not because the changes are not lived. But because the environment in the company does not allow for a radical change.

Reasons why the first Agile project in larger companies usually fails:

  1. Dependencies on other teams of delivery objects that are not Agile
  2. Stakeholders are engaged in other projects and work and cannot spend the time necessary to attend and review and review meetings more than once a week
  3. Change management has rigid release cycles of 1-2 times a month, making weekly changes impossible
  4. Existing operations team is overloaded and can’t maintain capacity to maintain new software/infrastructure

What can then be observed is an unintentional change back to certain waterfall elements. For example, the project reviews are suddenly monthly instead of several times a week. The work packages or User stories are pushed from sprint to sprint because the dependencies cannot be solved. And the first official MVP (Minimal Viable Product) is delayed. Finally, management begins to question their decision to run projects agile and demands explanations.

In such cases, when companies are of a certain size and individual IT departments have different management approaches, a hybrid model could be used.

Because there is no “one-size-fits-all” solution to any kind of project. Agile is on trend, but even if waterfall sounds old-fashioned, it takes into account certain approaches that allow companies to plan better. Especially when the environment around the project seems rigid and restrictive.

The best of both worlds

The Agile Waterfall Hybrid model introduced by Erick Bergmann and Andy Hamilton is the most well-known and widely used model. The phases from the waterfall model are used and supplemented with agile elements during the development and testing phase. Here’s what an Agile Waterfall Hybrid would look like:

The advantages of such a model

  1. In the early stages, other teams review the requirements, dependencies, and schedule. The aim is to ensure that the hardware is ordered in advance if it can take months to arrive. Similarly, other teams are tested according to their capacities and planned in advance to deliver certain elements.
  2. The critical paths are first identified and classified as a risk accordingly.
  3. The design is fundamental and can be discussed with the stakeholders. You try to prevent when stakeholders are unavailable, when false assumptions are made, or when the project team is waiting for requests.
  4. The development and testing is then done as agilely as possible. There are daily standup meetings, sprint planning and a product backlog. As far as possible, you try to plan all dependencies in such a way that the sprints work. If changes are desired, they can be taken into account at an early stage.
  5. Project reporting can be done traditionally and project sponsors can be informed accordingly.
  6. Continous improvement is given because multiple iterations can be made and delivery objects can be continuously improved.

Similar to a house building, the initial planning and clarification of the availability of craftsmen in the waterfall is basically done at the beginning. The individual delivery objects then use agile elements to be as flexible as possible with changes.

Such changes are easier for companies because they can gradually adapt to the agile approach. Software teams can work agilely and do their delivery objects in sprints, while hardware teams and product managers can continue the waterfall elements.

Share on facebook
Share on twitter
Share on linkedin
Share on xing
Share on pinterest
Share on email
Share on print