“We’re going agile now” – or: “Here, only waterfall works.” In many organisations, the question of the right approach is treated like a matter of faith. Yet choosing between agile and traditional project management is above all a practical decision: How clear are the requirements, how much technical uncertainty is there, which regulations apply, and how does the organisation work? This article explains the key differences, gives concrete decision criteria and shows when a hybrid approach makes sense – and when it does not.
In traditional project management – often called waterfall or plan-driven – the project is divided into sequential phases: initiation, analysis, design, implementation, testing, rollout and closure. Scope, schedule and budget are planned as completely as possible at the start; requirements and functional specifications describe what will be delivered. Milestones and phase approvals (quality gates) make progress measurable. In the German public sector, the V-Modell XT is widespread; it pairs each development stage with a corresponding test level.
The strength of the traditional approach is predictability: everyone knows early what will be delivered, when and at what cost. Its weakness shows when requirements change during the project. Every change then becomes a formal change request, and wrong turns often only surface during testing – at a point where corrections are expensive.
Agile project management assumes that not everything can be planned in advance. Instead of a complete plan, there is a product goal and a prioritised backlog. The team delivers in short iterations – in Scrum, sprints of one month or less – each producing a usable increment, gathers feedback and adjusts the plan. Its foundation is the Agile Manifesto of 2001, which values, among other things, working software and responding to change over comprehensive documentation and following a plan.
The best-known frameworks are Scrum and Kanban; for multiple teams there are scaling approaches such as SAFe or LeSS. Agility is more than a set of meetings, though. Without real decision-making authority for the Product Owner and an organisation that values results over plans, you end up with agile rituals inside a traditional frame – more on this in our article Agile Transformation: What Scrum Really Means.
A useful orientation is the question of clarity and uncertainty, as described by the Stacey matrix: the clearer the requirements and the more familiar the technology, the better a plan-driven approach works. The less clear the goal and the newer the technology, the more iterative work makes sense. In practice, further criteria come into play:
One criterion is often overlooked: the contract model. A traditional fixed price with a fixed scope fits poorly with an approach in which scope deliberately changes. If you want to work in an agile way, take this into account in the tender and contract, for example with a fixed budget frame and variable scope.
Many IT projects in mid-sized companies and large enterprises work in a hybrid way today. A typical pattern: a traditional master plan with milestones, budget and phase approvals gives management planning certainty, while software development within that frame is organised in sprints. Another pattern combines agile development teams with traditionally planned workstreams such as infrastructure, data migration or training.
Hybrid works when the interfaces are designed deliberately: How do insights from the sprints flow back into the master plan? Who decides on scope changes? How is a milestone assessed when scope is variable? If these questions remain open, you get the worst of both worlds: a rigid plan that is regularly missed, plus agile meetings without real room for decisions. The PMI standard reflects this too: since its seventh edition, the PMBOK Guide explicitly describes predictive, adaptive and hybrid approaches.
The difference is particularly visible in testing. In the traditional approach, there are dedicated test phases with system testing, integration testing and acceptance, planned in a test plan. The risk: when implementation runs late, the test phase gets cut. In agile, testing is part of every iteration. A story only counts as done when it meets the Definition of Done – including tests. For this to work in every sprint, you need a growing, ideally automated suite of regression tests. In both worlds, quality assurance must be firmly scheduled in the project plan, not treated as a buffer at the end.
There is no blanket answer to “agile or traditional?”. Traditional project management plays to its strengths with clear requirements, fixed constraints and many dependencies. Agile project management is superior when the goal only becomes clear during the project and early feedback makes the difference. Often, a deliberately designed hybrid approach is the most realistic solution. What matters is adapting the method to the project and the organisation – not the other way round. How to keep schedule and budget under control regardless of method is covered in Keeping IT Projects on Time and on Budget.
Not in general. Agile project management is particularly suitable when requirements are unclear or change frequently. Traditional project management has the advantage when scope, constraints and dependencies are fixed early. What matters is which approach fits the specific project and organisation.
Hybrid project management combines elements of both approaches, for example a traditional master plan with milestones and budget and agile delivery of software development in sprints. For this to work, decision paths and interfaces between both levels must be clearly defined.
Yes, but not with a fixed scope of work. Contracts with a fixed budget and time frame, in which scope is managed through prioritisation, have proven effective. A fixed price with fixed scope and agile delivery, on the other hand, often leads to disputes about changes.
30-minute initial consultation — free and without obligation. Together we look at your project and show whether traditional, agile or hybrid fits best.
Book a Free Initial ConsultationMore about our service: IT Project Management in Hamburg →