Risk management via incremental delivery

What I saw

The meeting was attended by the people who would form the project team: developers, tester, business analyst and project manager. They had each been specially selected as being among the best in the organisation. But they had not worked with each other before, and none of the developers had worked with the upstream third-party system.

I listened as the project plan was outlined to the rest of the team by the project manager: the first release milestone was for a “basic” integration to be delivered into production in 3 months’ time (that would be the week before Christmas). The 3 months’ work had been broken down into a series of 2-week sprints, each of which had an assigned set of deliverables.

What I did

I sat watching for 45 minutes as this plan was presented to the team, and then I stopped the meeting. I discovered that the project had no risk register, and so I outlined the risks I could see. Top of my list were:

1. The week before Christmas was one of the businest times of year, both for my client and for their upstream partner. It seemed crazy to deploy the first, untried, deliverable into production at that time.
2. Running a very tight schedule with a team that had no prior knowledge of the technology or the business domain seemed likely to result in schedule slip. That could cost millions in lost opportunity revenues (again, for both parties).

The fact that the plan had been broken into 2-week “sprints”, and was thus deemed to be “agile”, seemed to me to be pure window-dressing. Fundamentally this was a high-risk waterfall project, and no-one in the room could give me any confidence that the risks had been considered or addressed.

At this point I proposed a different approach: We would work with the upstream provider to quickly get a “walking skeleton” into production, and then increment it every day until it could be put live on limited real business traffic.

The core of my proposed approach was that we should place learning as our top priority: learning about how to do the integration, about the real business priorities, about how to work together as a team, about how to work with the given technology stack.

I set up new working practices for the team: the developers and tester worked together as an ensemble, rather than as a set of talented individuals, and continuously evolved their practices by holding daily retrospectives. I coached the developers in outside-in, test-driven development (TDD), and the non-developers in incremental delivery and planning based on live feedback.