We have all heard it before: a team states with some confidence how Agile or Lean they are, maybe because they work in iterations (or sprints), manage their work on task boards or both. However, what is often unclear and usually controversial is, are they really practicing Agile or are they mini Waterfall or ‘Wagile’? We will start with some definitions to provide some clarity.
Waterfall
As we know, the Waterfall model is a sequential process where progress is seen as flowing downwards (like a waterfall) through the phases of requirements specification, design (including architecture), development, integration, testing and deployment. The Waterfall model or ‘big design up front’ method works well for simple projects or when requirements are known, do not change significantly and there are few significant unknowns.
Agile
As a reaction against the heavyweight waterfall methods, which were criticised as being regimented, micromanaged and overly incremental approaches, a group of ‘lightweight’ software development methods evolved. These methods were collectively labeled ‘Agile’ and are based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organising cross-functional teams.
Lean
Lean is a systematic method for the elimination of waste in a production system, a management philosophy originating from the manufacturing industry. Lean is based on making obvious what adds value by reducing everything else, taking into account waste created through overburden and waste created through unevenness in workloads. Value is seen as any output that a customer would be willing to pay for.
Kanban is one of the most popular Lean methods used in software development, mainly as a visual process-management system, with an emphasis on just-in-time delivery, while not overloading team members who pull work from a queue.
While Agile and Lean are often interchangeable, both being lightweight development methods used to deliver business value early, how could either approach be confused with Waterfall?
Mini Waterfall
Contrary to some beliefs, adopting a few practices from Scrum, Kanban or Extreme Programming does not make a team Agile. We have seen that a team can develop in iterations, with planning, stand-up, backlog refinement, demo and retrospective meetings, and yet not be following Agile if they require further sequential iterations for integration, testing and deployment before releasing the product to users. That is essentially Waterfall and at best is mini-Waterfall or ‘Wagile’.
In contrast we have also seen that teams who collectively share the core Agile principles, and the values that underpin them, will naturally adopt the relevant Agile practices and deliver business value early.
Assessment
One method of assessing the extent to which a team is developing with Agile is to review their response to the following questions (adapted from the Nokia Test).
- Iterations – Are development iterations or sprints consistent in duration and no longer than 4 weeks, so they can deliver rhythmic value to the organisation?
- Sprint Testing – Do the team take joint responsibility for all testing and does the sprint product have sufficient quality to be immediately deployable?
- Sprint Stories – Do the team commit to work only when backlog items conform to a Definition of Ready, so they can generate business value fast?
- Product Owner – Is there a single Product Owner that helps the team understand and prioritise value?
- Product Backlog – Do the team have a value-ranked backlog to enable focus on work that will generate the most business value for the least effort?
- Estimation – Are the team’s estimates largely free of statistical bias, so stakeholders can rely on release forecasts?
- Sprint Burndown – Do the team know their progress toward completion of backlog items, so members can help with high priority work in progress?
- Retrospection – Do the team review their processes to sustainably improve productivity?
- Servant-Leader – Does the Scrum Master or Agile Coach competently enforce process, remove impediments and provides transparency, so the team can focus well?
- Team – Do the team work together effectively to release their software, so they can get software to users earlier and adapt rapidly?
In summary, iterations must be consistent, less than 4 weeks and end with all features in the iteration tested and working. In practice, we have seen that two weeks is the optimum iteration length and automation testing is necessary to test the current iteration and regression test work completed in previous iterations.
Teams not developing in iterations, but following a lean pull-system such as Kanban, should still 1) have a Product Owner / Champion type role that prioritises the backlog or queue by business value, 2) continuously improve and provide realistic estimates, 3) help each other to deliver high value items early and 4) have a Servant-Leader role that enforces process, transparency and removes impediments.
Using mini Waterfall is not wrong when it is appropriate to do so, as long as the team and stakeholders are clear that this is the approach being used. Honesty and clarity are central to efficient delivery.
If you would like to discuss how to deliver business value early, please contact us.
Share this post
