In previous articles in this series I’ve discussed how to pull together a simple agile approach based around Card Conversation Confirmation. In part 5 I want to illustrate how this can be introduced in a traditional lifecycle.

With scrum the ultimate aim is to complete each iteration with “deployable code” having been produced – this being defined by some functionality that once deployed will begin to bring some of the value and benefit promised by the whole project. For example consider a project that will eventually deliver an online shop. At the end of the first sprint it may deliver 5 static web pages, the basket and checkout and the delivery process is fully manual with orders being entered into the separate accounting system in the office. This allows the business to start marketing the sale of the items on the 5 pages which may be flagship products that are easy to sell – and start selling them while the remainder of the project continues to be developed. The full set of requirements are for a full inventory catalogue that can be administered online and an order system both of which are integrated to the stock and order systems in the office – but this is another 9 iterations away.

For a small business this approach is very attractive and relatively easy to introduce to the stakeholder and persuade them of these agile benefits. For a large enterprise this persuasion is a different story because they have heavy weight governance in place that probably pivots around an approval board who preside over each gate in their "prince 2 variant" lifecycle and the finance model just doesn’t fit with the scrum approach as gate 3 probably demands that the board approve the finalised requirements before permitting any money to be spent on developing the software. However the Completion of Artefacts approach can offer an introduction to the benefits of agile without the need to completely change the finance model – it only requires some small adjustments and compromises in some areas. To see how this could work lets run through the story told by the diagram below.

Along the top x-axis is the organisation’s waterfall lifecycle showing the gates running through a 10 month project. Along the bottom x-axis are the iterations 1-10 that we suggest overlaying on top of the usual process.

To reach Gate 1 the board wants to see a mandate or project initiation document of some sort. Gate 1 coincides with the end of iteration 1. Normally some budget is required to establish a mandate – say £5k for arguments sake and this would be spent on defining the requirement at a very high level and giving some indication of likely cost and duration. This is traditionally done by talking and drawing up documents so the first change we introduce is to develop some software to back up the mandate. The software that is produced needs to be simple but effective in demonstrating the benefits of the project and this short exercise needs to provide the data for extrapolating the final cost and duration of the project relative to what has been produced to date. At this point it is highly unlikely that the software produced so far is deployable but it must be good enough to make the case for the project to continue to the next step. So rather than simply presenting a piece of paper to the board at gate 1 – support this with a demonstration of the software too - maybe when they see that this can be achieved for £5k the next time another PM turns up with just a piece of paper they might say “where’s your demo like the one Dave did last month for the same budget?”

To reach Gate 2 the board wants to see a project brief – a more detailed definition of what will be delivered and a more accurate estimation of cost and duration and the budget for the project is likely to be signed off here at plus or minus 50% as a ROM (rough order of magnitude) estimate. In the Completion of Artefacts world this gives us another 2 months and probably £15k - £20k more to spend producing more of the software to continue to illustrate the benefits of the agile approach but also stay on track with what the board want to see. By this time the agile approach should be ahead of the traditional one on the requirements artefact – more than 50% of them should have a clear definition by now and into the bargain there may be as much as 15% of the final software developed and tested – still unlikely to be deployable but great for making an impression in front of the board so they can see you are spending their money well and they have a very clear picture of what the project is likely to deliver.

So having now secured another £40k to continue to Gate 3 the board wants to see that the business requirements have been signed off – so its important to make sure this happens – now in a traditional model there are always change requests after this gate that alter the “signed off” requirements so lets say they were going to be probably 80% complete rather than 100% - which is what the Completion of Artefacts gives us at this point. When it comes to the presentation to the board the software you’re showing them now is 40% tested and could well be deployable – if it is and you can successfully demonstrate this then the benefits of agile have just been sold to the board. The fact that there is deployable code already will help with any difficult conversations with the board about whether the requirements are really signed off or only 80% complete.

Up to Gate 4 the development should be complete and ready for testing and deployment to begin and complete the 10 month project. At Gate 4 there will be more deployable code so the benefits this brings again help to counter the fact that maybe only 90% of the software is actually finished – already backed up by the revenue that’s been generated since Gate 3 three months ago that the business wasn’t expecting. Another thing that should facilitate the process is that because gates 3 to 4 are divided into 3 iterations there is a good chance that any change requests that arrived in month 6 are actually already developed and tested where as the traditional model may not have factored them in yet – this is where the Card Conversation Confirmation method comes into play – making sure that there is ample flexibility for managing change (see previous articles). The rest up to gate 5 is the same story.

This illustration is simplified for obvious reasons and to achieve this requires lots of hard work – its more of a challenge than simply riding the traditional lifecycle gate by gate in the traditional manner – much more hard work and requires very strong close-knit communications within the team. Getting it right first time is important because the risks and consequences of failing will make the next attempt much more difficult - but then courage is an important element in taking on an agile approach.