The document discusses how project managers no longer need to choose between solely using Agile or Waterfall project management methodologies. It suggests using elements of both based on the specific needs and attributes of individual projects or parts of projects. For example, using Waterfall for well-defined hardware deployments and Agile for iterative software development. The document also notes that PPM tools now support using different methodologies within the same tool, allowing for flexible reporting and comparisons. Combining the strengths of planning from Waterfall and flexibility from Agile can provide major benefits if blended carefully based on a project's unique characteristics.
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
Sciforma agile and_waterfall
1. Agile or Waterfall: Why you don’t have to choose anymore 1
Agile or Waterfall:
Why you don’t have to
choose anymore
Introduction
Choices, choices – we all love having a choice and we all
love taking sides. It appeals to our tribe mentality. In the
60’s you loved the Beatles or the Stones1
. In the 90’s you
were an Oasis fan or a Blur fan2
.
But sometimes the best solution is a combination of the
two. If you could have combined the song writing of the
Beatles with the style and attitude of the Stones, what a
super-group that would have been!
In the slightly less glamorous world of PPM software,
there has been a long running battle between the
two tribes of Agile and Waterfall. On the one hand,
the proponents of Agile claim that the collaborative,
iterative approach on which it’s based gives better
quality outcomes more quickly, while advocates of
Waterfall claim the detailed, formalised approach gives
better visibility and governance of the project itself.
Never mind that few PM’s actually followed a strict Agile
or Waterfall approach, it seemed that everyone in the
PM world joined one or another tribe and opinion was
polarized one way or the other.
But in the last year or two, more and more PM’s are
embracing both approaches and starting to combine
elements of both, in search of the optimum combination.
Whether you call it ‘Bimodal’, ‘Hybrid’, or just common
sense, the old dividing lines are slowly disappearing.
1
The correct answer is of course The Who
2
The correct answer is of course Pulp
2. Agile or Waterfall: Why you don’t have to choose anymore 2
Suggestions for Using Both Agile & Waterfall
It’s always been the case that one methodology rarely fits all projects. Most organizations will have a light
methodology for ‘small’ projects and a more detailed methodology for ‘large’ projects. So the obvious place to
start is to decide on an Agile or Waterfall approach on a project-by-project basis.
The choice should be guided by attributes such as these:
• Does the project have well defined requirements (Waterfall) or not (Agile)
• Is the project team full time and established (Agile) or part time and new (Waterfall)
• Is the culture top down and centralized (Waterfall) or bottom up and distributed (Agile)
• Is the main deliverable a one-off (such as a marketing event) (Waterfall) or iterative (such as releases
of a software product) (Agile)
• Is the ability to predict and measure when specific deliverables and work will be done of greater
(Waterfall) or lesser (Agile) importance
Within the same project, it’s not uncommon for particular tasks or work streams to be better suited to different
approaches. For example, if you are developing and deploying an IT solution, you will normally be managing a
software development stream, a hardware deployment stream and an implementation stream concerned with
the accompanying business change. In this case, the software development may be better suited to an Agile
approach and the hardware deployment to a Waterfall approach.
The challenge for you, the project manager, is that you have to manage the whole project, irrespective of the
approach being used on each task or work stream, and so you have to agree a common way of planning and
tracking both parts which is consistent. This can be made easier if you can appoint work stream leaders and
devolve responsibility to them for planning and tracking their part of the project so you only have one person in
each workstream whom you need to coordinate with.
Use different methodologies for different projects
Use different methodologies for different parts of the same project
3. Agile or Waterfall: Why you don’t have to choose anymore 3
Finally, as your Waterfall/Agile maturity grows, you may start to blend the two methodologies and take the best
of both. The formality and thoroughness of the planning and governance elements of a Waterfall approach can
be very effective in encouraging clear thinking and minimizing uncertainty while the flexibility and collaborative
nature of Agile is particularly effective in the execution phase.
There is no industry standard combination and many commentators see risks to this approach, so it’s necessary
to tread carefully. The two approaches are very different in the underlying philosophy and it may confuse
or frustrate your team to have to use elements of both. So be sure to pilot any changes thoroughly before
incorporating them into your standard way of working and involve your team in this business change. There are
other issues to consider as well:
If there is a natural bias in your organization to one, it may be very difficult to accommodate the other. For
example, Waterfall is designed around a traditional hierarchical organization with the Project Sponsor, Manager
and team members having clearly defined levels of authority and responsibility. While Agile teams are much
flatter with authority and responsibility delegated down to the team members. Having to switch between the two
can easily cause conflict unless the different roles are clearly defined.
Questions to Consider
Use a blend of methodologies in one approach
Is there a cultural bias in your organization?
4. Agile or Waterfall: Why you don’t have to choose anymore 4
Both Agile and Waterfall have their metrics for tracking and comparing project performance, but unfortunately
they aren’t the same. For example, Agile tracks task accomplishment in terms of the number of story points that
have been delivered while Waterfall uses % completion of the task duration as a proxy for this. So it’s necessary
to develop a baseline standard across the portfolio that will allow you to compare both types of project.
Similarly, metrics for tracking scope and cost will also need to be agreed, as well as and a baseline, so that
comparison between and within projects is meaningful.
If you are successful in combining both philosophies, then you can expect to benefit from their complementary
nature.
The formalized Waterfall approach means that significant time is spent in identifying business, user and
functional requirements, which helps to define the final goal of the project in a way that can be communicated to
other stakeholders and get their support. A detailed project specification can also be valuable in clearly defining
roles, responsibilities, work packages, milestones and deliverables. This can highlight risks and help to avoid
duplication of effort and unnecessary cost before you start delivering the work.
But however good the planning, there needs to be flexibility in executing the plan so that you can react to the
many unexpected events that impact your project. An agile approach, with its emphasis on communication and
collaboration, means that you get early visibility of these events and can quickly agree how to respond with your
team. The involvement of the customer in a formal role can also emphasise the need for their rapid feedback
Preparing the Next Steps
How to track and compare projects and tasks?
Rigorous planning
Flexible execution