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.


IT program and project managers are expected to do much more than just monitor compliance with processes. Highly qualified IT managers master effective change management, comprehensive reporting, people management, extensive strategic understanding and high resilience. In an environment as dynamic as digital transformation, few managers can achieve measurable success. At Akana, we are committed to promoting and challenging the greatest talents in order to make companies fit for the challenges of digitalization.


There are various reasons why projects fail. It could simply be the result of insufficient project requirements, high complexity, unrealistic project expectations, even poor leadership, among many others. What many Project Managers (PM) underestimate is the social factor in project management—an inherent risk to any project.

The comparison with projects in other industries shows that IT projects are increasingly failing and are being cancelled. Or they end, but are over deadline or budget. According to an international study by the Standish Group, representatives of large companies in DACH, UK and North America stated that 84% of the projects would not be completed or fail in line with deadlines or budgets.

The ever-increasing amount of data is becoming a major challenge for our companies. The variety of data ranges from employee and customer information to complex scientific data—data that impacts decisions and strategic business movements.

SCRUM has been made an everyday term by Jeff Sutherland and you are often confronted with it. Certain elements from SCRUM, such as the Kanban Board and the daily standup meetings, were very well received – even outside of IT.

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