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.
| Practice | Works when | Has challenges when |
| Release planning | Involving 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 Iterations | The 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 planning | User 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 standup | Is 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 estimation | All 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 board | Using 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 review | There is a clear purpose for the review | Too much preparation is required for a review that does not contribute to the deliverable. |
| Retrospectives | Used 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 |
One thought on “Waterfall is Dead. Long Live Agile!”
Comments are closed.