“The pace and ability at which an organization is able to effectively innovate will be the determining factor of competitiveness in the future. The future is now.”
― Kaihan Krippendorff

Interested to know more?

Just fill this simple form, one of our team member will be in touch with you soon.

 

What is better: waterfall or agile?

We often hear people ask about the ‘best choice’ between waterfall and agile. We believe that there are products that may be better to run in waterfall: products that are predictable to build (for example copying or migrating an existing tool). There may also be situations where it’s better to not do everything in agile, because an organization has just started with agile. It takes time to get buy in from everyone if people have been working in waterfall for a long time. It also takes time to create the right culture, tooling and organizational support to move work to agile (Which is why agile transformations typically take years in a large enterprise).

Having said the above, we believe agile brings a lot of benefits to most projects and organizations. The below image, courtesy of Henrik Kniberg, shows the 4 ‘value propositions’ of agile.

Visibility

In waterfall, the visibility of a project is high in the beginning. This is because people have discussed and analyzed requirements extensively. Everything is documented in requirements documents. Once the project starts, the visibility goes down, because people use gantt charts (instead of ‘real progress’) to show completion against plan. Real, usable software, usually is delivered very late in the project.

In agile, the visibility is high in the beginning and stays high over the course of the project. Requirements are captured on boards using sticky notes (or online tools like Jira or Trello). Each iteration, the business people interact with the team to see what needs to be delivered. They then get a piece of the product delivered in the sprint which they can use, click, test and give feedback on. This feedback leads to new insights and priorities. It is always clear to everyone what has been delivered and what the bottlenecks are. There is transparency and constant communication and alignment.

Adaptability

In waterfall, everything is adaptable in the early stages of a project. As the requirements are developed, we can still chose what to build or change. But once the requirements are signed off and the team is doing the work, things can not be changed that easily. If they do, it leads to disruptions of the plan.

In agile, we welcome change. In each iteration, new insights, new requirements, can be added, removed or prioritized in the product backlog. Over time, some technical things get nailed, which is why the graph shows a small decline. Architectures get fixed, code is made and deployed, so it becomes harder to change things over time, but still things are much mroe adaptable than in a waterfall project.

Business value

In waterfall, value is delivered in a big bang. The different groups of people have been working sequentially on the software. Once the testers have finalized their work and bugs have been fixed, the product is delivered to the business side. That brings value at the end of a project.

Agile delivers value from the early stages of a project. After each iteration, a (small) piece of the product (a potentially shippable product increment) is delivered. This piece of software can be inspected and feedback can be provided to the team on what (not) to build next. Some parts of the product can already be used by customers. The value is delivered incrementally from the beginning of the project.

Risk

Waterfall is high risk. As we don’t see real software being delivered, we need to wait till the end of the cycle to see what’s delivered. All types of risk may come up: technical risks, business risks, regulatory risk. These risks stay alive until the end of the project when all is ‘done’.

In agile, risk can be managed continuously. Risk people can even be part of the team and monitor what the team sees. They can see on a daily basis what technical risks come up and how the team deals with it. They can see how users respond to the software or weather people use the software at all, once the increments are ‘shipped’ to users.