When the red bus hits: Agile when things go wrong

There’s a saying in software development “If someone gets hit by the red bus ... “ which roughly translates to that if you lose a project team member or two you still want to be able to get the work done and finish the project.

Normally, red busses are rare: The realistic worst case scenario is one or two team members out with the flu or someone quitting their job. A good team can normally recover from such disruptions.

But red busses can be bigger and more damaging and wipe out large parts of a team: This usually happens if a new CEO, new management or a new government revokes funding, recession hits or an organisation just plain runs out of money.

In this case one of two things normally happen:

1. The project goes on with fewer team members


2. The project gets canned or put on hold

Waterfall

This is bad news for everyone but has a devastating effect if your project runs any flavour of the waterfall methodology:

Fewer team members:

Going on with fewer team members will not just result in major delays but will risk the success of the entire project.

Job roles in waterfall projects and organisations are highly siloed, i.e. testers test, developers code and a business analysts deal with requirements. A team losing several members will not just work at a lower capacity but some work simply cannot be done: If a project for example loses its testers testing will not be performed and the project comes to a grinding halt.

Canning the project:

Stopping the project has even more devastating effects and most likely the entire investment in the project is lost.

Waterfall methodologies use a phased approach: Requirements gathering, Design, Build, Testing and Deployment. Depending on which phase the project gets stuck in an organisation might end up having paid millions for a functional specification, technical design or developed but not yet tested software. All work on a product that cannot be rolled-out and used and that might never see the light of day.

If a waterfall project is stopped before the final phase the product cannot be used and the return on the (often considerable) investment is zero.

Agile

For an Agile project loss or reduction of funding can be bad news too but the risk when using an Agile methodology such as Scrum or XP, if implemented properly, is contained and the investment will not have gone entirely down the drain:

Fewer team members:

Going on with fewer team members will reduce a team’s capacity but as the responsibility and accountabililty for delivery lies within the entire team rather than individual job roles an Agile team can usually keep on delivering.

Agile teams organise around generalising specialists where people have both a primary and several secondary job roles and if one or more specialists have to leave the team other team members will take on their work. If an Agile team for example loses its testers the team’s business analysts, developers, scrum masters/project managers etc will share the workload and ensure that the software is tested and working properly.

Even at a slower pace the team will produce software that can be rolled out to end users.

Canning the project:

If the project is stopped or put on hold the damage is limited. Agile teams develop software incrementally and the primary measure of success is working software. Every 2-4 weeks (dependent on iteration length) the team delivers fully functional software, i.e. software that is fully designed, built and tested.

The basic rule to implement high priority features first ensures that, if the project is stopped, the most important pieces of functionality have been fully developed.

Unlike in a waterfall project project sponsors will never be left with just a functional specification, pieces of documentation or untested software. You might not get everything you initially wanted or set out to build but everything that has been worked on is fully functional and ready to provide value to the business and/or end users.

Real Life

Loss of funding and team members is what has happened after a change of government at my (now former :-) workplace, a New Zealand government entity.

My Agile (Scrum) project has already produced working and usable software in an incremental fashion. Even if it should get stopped we have delivered business value and a good return on investment.

In this case the organisation’s choice of running Agile has put them ahead of their peers.

The waterfall projects? I wish them the best of luck - they’ll need it.