Insights · Approach
Traditional, agile or hybrid: how to combine the approaches sensibly
The question is rarely "traditional or agile?", but rather: which part of the project needs which approach? How to combine both without getting the worst of both worlds.
Dr. h. c. Konstantin Dirbanis · · 4 min read
Hardly any topic is discussed as passionately in training as this one. Some consider traditional project management outdated, others see agile working as chaos with sticky notes. Both fall short. In over 35 years of project work I have learned that the most successful projects choose their approach not by conviction, but by the task.
Traditional project management in brief
Traditional, plan-driven project management defines goals and scope at the start and works through them in phases. Deadlines, budget and result are planned, and changes go through a regulated procedure.
Its strengths: predictability, clear responsibility and a good basis for contracts, audits and approvals. It fits when requirements are known and changes become expensive, for example in construction, hardware or highly regulated initiatives.
Agile project management in brief
Agile approaches enable short learning and feedback cycles. Results are reviewed regularly and the further approach is adapted. Scrum works in fixed sprints for this purpose; Kanban supports a continuous flow of work.
Its strengths: fast learning, early results and the ability to respond to change. It fits when requirements are unclear at the start and a result can be developed piece by piece, typically in software development. Well-known frameworks are Scrum for individual teams and SAFe for many teams working together on one product.
How to recognise what fits
Instead of asking the question of principle, examine the project, or better still each of its parts, using a few questions:
| Question | points to traditional | points to agile |
|---|---|---|
| How clear are the requirements? | largely known | unclear or changing |
| What does a late change cost? | a lot | little |
| Can the result be used in parts? | no, only as a whole | yes, step by step |
| Are there fixed requirements? | regulation, fixed-scope contract | few |
| Are users available for feedback? | rarely | regularly |
| Does the team know agile methods? | hardly | well |
The table is for orientation. Even with binding requirements or high costs of change, agile elements can make sense. What matters is which parts of the initiative need early learning and regular feedback.
If the answers are mixed, and that is the norm, a hybrid approach is usually the best choice.
Three proven patterns for hybrid project management
1. Traditional framework, agile delivery
Externally, the project has phases, milestones, a budget and a steering committee. Within this framework, the teams work in sprints. This pattern is particularly suitable for companies with plan-driven governance, such as banks and insurers, and for projects with a fixed deadline but open details.
2. Sub-projects with different approaches
Some parts of the project run in a traditional way, others in an agile way. An infrastructure or a rollout is planned, while the software for it is built in sprints. The key is shared integration dates, when the parts come together and are tested jointly.
3. Explore first, then roll out
The project starts with an agile phase: prototypes, tests with users, a first usable product. As soon as it is clear what works, the plan-driven rollout follows, for example across many sites or in several countries.
The most common mistakes
Waterfall with a daily stand-up. The team adopts the rituals of the agile world but gets no freedom to decide how the work is done. The result is more coordination without more impact.
Two plans that know nothing about each other. A schedule for management and a backlog for the team, with no connection between them. Link the two through shared milestones and release goals.
Unclear roles. Who decides on content, the project manager or the Product Owner? Clarify this in the project charter before it turns into a conflict.
Reporting in two languages. If the team reports in story points and the steering committee expects percentages of completion, in the end nobody understands the status. Agree on a few shared measures, such as milestones reached, budget and the main risks.
What project managers need to be able to do
Hybrid working calls for more than two sets of methods. Project managers must be able to judge which approach fits when, and bring both worlds together in their team. The IPMA® competence standard describes exactly that: it assesses not the method, but the ability to lead projects to success in their environment, with people and with suitable methods, whether traditional, agile or hybrid.
How much structure a project needs overall is, incidentally, a separate question. More on this in the article How much project management does my project really need?
Conclusion
Traditional and agile are not opposites, but tools for different tasks. Good hybrid project management does not come from mixing by feel, but from a conscious decision for each part of the project and from clear rules for how the parts work together.