In software development, there are two popular and much-debated categories of process workflow in software development: Waterfall and Agile.
Agile software development requires thorough planning with rigid requirements at development time. Agile software development is executed in short iterations where planning is done in its entirety up front in Waterfall.
Even on a Waterfall project with a fixed scope & cost, a strong management team will move the operational strategy in the direction of agile development borrowing processes and practices to improve team collaboration and efficiency.
Waterfall
Software professionals will cringe when they hear the word “Waterfall”.
The truth is that Waterfall does have its place and the predictability is suited to certain projects.
The problems with a waterfall process arise when a project passes that threshold where it is no longer fully predictable in terms of requirements, workflows and technical challenges.
As a project management discipline, waterfall also makes a lot of sense. In this model a significant amount of time is invested up front in thoroughly defining requirements so that every possible caveat is covered and we know when it is going to be delivered.
The team will then plan how they are going to approach the problem and how long it will take. The project plan contains time for testing and bug fixing before deployment with maintenance being carried out under warranty or retainer.
This is perfect in fields where requirements don’t change after scoping and implementation time is predictable to an extent with the construction industry being a good example.
The beauty and challenge of software projects is that we are doing something unique. The nature of such endeavours is that these undertakings are inherently unpredictable.
The reasons I believe Waterfall isn’t always the correct choice for software are:
1. Estimations are done up front and do not take the status and learnings gained throughout the implementation into account.
2. Waterfall assumes requirements are thoroughly fleshed out on all levels. Particularly on large, complex scopes of work, this is an unrealistic misconception.
3. A fixed scope does not respond to evolving customer needs over time. The finished product can be what a client thought they wanted rather than the solution they really need.
4. Little or no feedback loop to harness learnings and gain efficiencies during implementation.
Agile
There are several subsets of Agile. Each tie back to the principle of iterative work cycles.
Another defining characteristic is flexibility on all sides so that scope evolves to meet the needs of the customer throughout implementation. This can be best achieved by releasing what is a minimum viable product early and assessing its effectiveness against key KPI’s.
The term agile development does not correlate with a particular way of doing things. It is an umbrella term which covers a number of different processes and practices. Two of the most widely adopted processes are Kanban and Scrum.
**Tell me about Kanban?**
Kanban interestingly has its roots in car manufacturing with it originally being the brain child of Toyota in the 1940’s. Toyota took their inspiration from an unlikely source: the supermarket! The supermarket clerks restocked grocery items by their stores inventory levels and not by their vendors supply.
Toyota used this quite simple and yet profound realisation to drive the adoption of a revolutionary “just-in-time” process that would match inventory with demand throughout the entire production lifecycle in turn achieving higher levels of efficiency and throughput.
In software the idea is that a Kanban board will have various columns that represent task statuses e.g. in progress, test, ready to deploy. If you are trying to visualise this, think Trello boards. With each column containing tasks, it gives the entire team a visual representation of the current project status.
Kanban as a software development process emphasises limiting the number of tasks in any column prioritising a smooth, lean flow right through to deployment. The number of tasks in progress at any given time should correlate with the capacity of the team.
If a bottleneck is identified with too many features sitting under any one status, the entire team will work together to identify the cause of the impasse and keep features moving through.
What about Scrum?
Scrum teams develop projects or products in an iterative, incremental model. It borrows its name from the term in Rugby Union which refers to when a team of players interlocked together push in a common direction against the other team.
Development in Scrum is executed in cycles called Sprints which are typically 2 week iterations.
A Sprint planning meeting happens at the start of a sprint where work is prioritised, estimated and committed to depending on capacity. After a sprint planning, there are no changes in the scope of what is being committed to during this iteration.
Each morning the Scrum team will gather to give each other a status update and discuss next steps working towards the common goal of delivering all functionality committed to.
At the end of the sprint the team demonstrates what has been delivered to all stakeholders before entering into a retrospective where an open, honest conversations takes place discussing learnings and what actions are necessary to improve the velocity of the next sprint.
The most important takeaway for this is that scope is frozen during a Sprint. While Scrum does embrace change, any changes need to go into the next sprint.
Kanban or Scrum?
I have seen both Kanban & Scrum used effectively in the right situations. It’s not a case of one methodology being better than the other, it’s about using the right methodology in the right place.
In both Kanban and Scrum, a prioritised and unified product backlog is essential to the success of the project. Product management will prioritise that backlog having a clear vision of what gets worked on first and the development team will decide how.
Another consideration is the deployment infrastructure. Kanban relies on frequent releases of software so a mature continuous deployment infrastructure is essential.
Deployments in Scrum are on the other hand less frequent so manual deployments, while not ideal, would not be as much as an obstacle here. Many Scrum teams choose to batch the product of their sprints into quarterly release plans although there are others who choose to release monthly or in extreme cases by sprint.
Last but definitely not least the single biggest factor to consider when choosing a methodology is the type of project or product this is and what your goals are. If your goal is to frequently add new features to an existing product, Kanban is the way to go. Spotify is the most famous exponent of Kanban done right. A solid product with frequent releases adding new features.
Scrum on the other hand is very well suited to moving new scopes of work forward with product management being very closely integrated with the development team. Velocity in scrum projects is tracked against sprint planning estimations which gives the product management team improved project plan visibility.
Keep it simple
Whatever methodology you choose for your project, the most important thing to realise is that every organisation is different and what works for some will not necessarily work for all.
Remember that the defining characteristic of agile is flexibility.
Try something, see what works, see what doesn’t work, get feedback from the entire team and evolve. The key is to keep it simple. Do not over-complicate and you will reap the benefits.
Johnny Mullaney 