agile · Project Management

Waterfall is Dead. Long Live Agile!

Many companies have adopted an agile methodology for their projects. They may have adopted a specific agile methodology such as Scrum or introduced a hybrid model with some topics managed using an agile methodology or agile practices. Therefore, we can announce that pure waterfall projects are dead!

While there are challenges, issues, and problems in introducing agile methods, we can say agile practices are successful, no matter the project type. The following is our view on when some agile practices work and why.

First, the figure shows the most popular agile practices according to the 2021 version of the “State of Agile” survey, which had 1.382 participants.

Next, in our experience, practices work for or have challenges for the following reasons.

PracticeWorks whenHas challenges when
Release planningInvolving internal/external stakeholders in the release planning sessions

Risks are considered in the release planning sessions

Having a release plan that aligns with the sprint/iteration planning and the project objectives

Sharing it with internal and external stakeholders
Does not exist

Not aligned with the stakeholders esp., the sponsor, steering committee, product owner

Makes formal commitments about the exact 100% guaranteed content of a release
Short IterationsThe duration fits the type of work—not too short and not too long

No more than 30 days  
Duration is too short to deliver any meaningful work

Duration is too long, so the work scope starts changing during a sprint/iteration  
Sprint/iteration planningUser stories have been refined and prioritized

An authoritative decision-maker (e.g., product owner) participates with the team in the planning

What is in/out of scope is negotiable

Considers the schedule/availability of the individual people in the team

External dependencies are considered
Not aligned with the release planning

The backlog is not clean / user stories are not defined

User stories are too big to estimate

User stories not prioritized

Individual people’s availability / schedules are not considered in the planning

Key people do not participate
Daily standupIs kept short (less than 30 minutes), even for big teams

Has all the participants responsible for actions in the project

Is focused on the work and issues of the day
There are long problem-solving discussions

Does not include all the people with actions in the project

Is not focused on key stories; tasks needed to reach a specific goal

Too frequent for the type of project
Planning poker/team estimationAll team members that will do the work are involved in the estimation

Estimates are anonymously submitted before discussion

Wideband, not precise estimates

Open discussions about why people estimate the way they did, and the scope is refined/detailed accordingly
No common agreement on estimation type – ideal days/story points

Not agreeing what is in and out of scope

People are pressured to change estimates without changing user story/work

Some people are ignored
Kanban Most people use a Kanban board like a task board, i.e., work-in-progress is not considered
Task boardUsing the board in the sprint/iteration planning

Using it as a day-to-day tool for work, including in daily standup

Each team member updates their items and discussions
Focusing on the technology and status of charts on the board without using the board in the daily process
Sprint/iteration reviewThere is a clear purpose for the review  Too much preparation is required for a review that does not contribute to the deliverable.
RetrospectivesUsed early stages of teamwork

Used to drill into a specific problem or issue

Everyone contributes at least one topic in each category—what worked, what didn’t, and improvements decisions

Topics are discussed with the whole team

Items are followed-up

Used to find improvements/optimize work
Actions and recommendations from past sessions are not followed up