Moving your delivery partners and your organisation from a waterfall delivery model to an agile model means building a transition approach that is designed to build trust by addressing the perceived risk to all parties.
The risks to the outsourcing organisation include:-
- They won't get back the running software they need
- They'll end up paying considerably more than they expected due to change requests
- They'll end up not getting what they wanted in time for the business
The outsource partners' risks include:
- They''ll end up having to fund delivery due to poorly specified requirements
- They'll end up losing money due to the cost of correcting defects in system test and production due to complex infrastructure deployments
These risks are some of the reasons that we've spent years working with lawyers and procurement trying to nail down contracts and Service Level Agreements with partners.
It's interesting that some in the agile community say we're incorrect to seek certainty. The challenge is actually that we've confused the definition of certainty. Certainty should not mean expecting to have all of the requirements documented as complete and accurate before they are developed in to code. Certainty is about removing risk as early in the lifecycle as possible.
If you suspect there'll be performance issues then gaining certainty involves creating a contract and funding that motivates the delivery of just enough of the system as executable software to be able to performance test the areas of concern. This has to be better than contracting and funding the production of diagrams showing how the system may deal with the issue.
Moving a delivery partner who is used to managing risk using the Big Requirement Up-front approach to this more agile model is challenging.
So what advice did I give to my client?
If you can't immediatley engage their agile practice (which a lot now appear to have), you'll have to move both them and your organisation in stages.
Using the call the Crawl, Walk, Run adoption approach you can start off with the Crawl approach described below. In no order:
The first thing is to move away from a long list of contextless requirements and start documenting your requirements as Mike Cohn style user stories or Alasdair Cockburn style use cases split into use case scenarios. Make sure that you've thoroughly documented the non-functional requirements and architectural constraints either in the user stories, use cases or separately linked to at least one of these so that later you can test the implementation of the story or use case scenario to demonstrate addressing the non-functionals.
The second thing is to move the delivery mechanism to iterations. Iterations being a fixed time-box which at the end results in working code, ideally of production quality.
The final thing that will ease the transition is to initially use phases that focus on building trust by removing risk and use the appropriate contract types by phase.
Love it or hate it the Open Unfied Process (OpenUP) has useful phases that, since they're built around managing risk using iterations, help the migration of waterfall type organisations to agile. Forget about the activities within the phases, they're interesting as a library of practice but less important, and focus with your delivery partner on the phase outcomes and on how to contract around those. The phases give natural contract and funding break points in the move towards agile. OpenUP also introduces the concept of iterations which are critical in the move to agile. Iterations being time the boxed delivery of user stories/use case scenarios as tested executable code. Iterations again offer a useful contract break point.
So how can the OpenUP phase goals help in the move to agile?
The phases are specifically designed with different risk profiles. They are suited to having different contract types for each phase to balance the risk for all parties. The Inception phase has medium risk as the scope is unclear. The Elaboration phase has high risk since it's purpose is to prove the high risk requirements can be delivered by building them. The Construction phase has medium to low risk since all of the high technical risks should have been removed. Finally the Transition phase’s risk profile is based on the complexity of deploying the software; a web application my be low risk to launch where as an update to a retail banking application may be higher risk.
High level requirements are defined and throw-away executable prototypes demonstrating any critical architectural risks are demonstrated. Identify requirements that are critical from a business perspective and that if built will demonstrate the removal of the main technical risks. Refine only these requirements ready for building should you proceed with the project in to Elaboration. This will give all parties some guidance on the amount of risk being taken in to Elaboration. Since the scope of what's being built is unclear this ideally would be time and materials contract.
Refinement of the requirements to the point where you and your delivery partners can agree an acceptable price and schedule range for the build of the base requirements and what the extended content is. In parallel build the requirements that are critical and also kill the technical risks identified. You don’t leave Elaboration until you've built executables that demonstrate through testing the removal of all identified technical risks. You're
The remainder of the requirements are further refined if required, designed and built in iterations. The grouping of requirements in to iterations should now be done based on business priority, having addressed the technical risk. Each iteration should be delivered as executable code that can be tested along with the relevant documentation. You should be aiming for as short an iteration length as possible but monthly iterations would be a good start. They should certainly be no longer than 3 months and you should push these to be shorter as soon as possible. Iterations are a huge risk mitigation tool. You get to deploy the software regularly into a test environment close to your operational environment. It has to be a good thing. You're only paying for working code, potentially per iteration and better still should commercially you need to deliver something to market early you can as you have production quality code at the end of each iteration. Other industries have worked this way for years.
This phase is about getting the software live and in to the hands of the business. It should be similar though hopefully with less issues. The iterations may be used to timebox the deployment of the application in to different business units, geographies or the deployment of tha application by functional area and any mixture of the above.
Let's not forget that the ideal end game not to “do” agile but to reduce the time to value of producing the right software and building it with an appropriate total cost of ownership profile. We should be striving to remove as much of the overhead created by complex contracts and unnecessary work. To do that we need to build trust both internally and between us and with our delivery partners.
- Agree to document your requirements in Mike Cohn style user stories or Alasdair Cockburn style use cases with scenarios for planning
- Agree to use iterations as the delivery mechanism, ideally monthly or more frequently if possible
- Typical contracts attempt to establish certainty incorrectly
- Use the Open Unified Process phase goals as a way of managing the perceived risk to all parties of a move to more agile contracts.
- Don't concern yourself with the detailed activities of the OpenUP if you already have a process. Focus on the phase success criteria and map your current life cycle to this.
- Structure the contract around the phases and iterations.
- You might start out with Inception as time and materials, Elaboration as time and materials, Construction as fixed price and Transition as time and materials. The contract type needs to reflect the balance of risk taken and trust established between all parties.
- Once you've earned the trust of the third parties and credibility within your own organisation you can move the thinking to the Disciplined Agile Delivery (DAD) approach.