How Agile would have saved project ORCA

Working in the Web Development industry it’s easy to get the impression that everyone involved in software knows about Agile and is at least paying it lip service even if their processes are not really Agile in practice. Clearly this is not the case. The Unmitigated Disaster Known As Project ORCA describes how Mitt Romney’s team attempted to win the race to get voters out to the polls using new technology but fell at every hurdle. It presents us with a textbook copy of everything that can go wrong in software delivery with (depending on how significant its impact) potentially election losing consequences for Mitt Romney and the GOP.

The following are some of the glaring errors made that would have been avoided using Agile/Lean techniques:

  • Putting a mission critical piece of software to its first real use on a day when failure was not an option.
  • Giving themselves no opportunity for feedback or pressure testing and gaining no validated learnings as to whether what they had built would even work – conceptually, functionally or practically
  • Using a top-down approach that ignored the huge amount of skills, knowledge and experience that could have come from the greater team (those on the ground that would have to use the product)
  • Convincing themselves they had a product so great that it was better to keep it under wraps and maintain the element of surprise than it was to allow the product to be pressure-tested by the people that were going to use it

Agile software development recognises that you will not get it right in version one, that a delivery team needs to include its end users, that software improves iteratively and that not only your software but your business model itself must be able to pivot and adapt to the realities on the ground and the feedback you receive.

Advertisement

Validated Learnings: How Heroku Pivot and Adapt

My team at Westfield.com are always trying to educate the business sponsors to implement the simplest possible thing – to release the minimum viable product and generate validated learnings rather than implement gold-plated visions of what marketing folk think that people want.

Francis Is shows how successful Heroku were at doing this in Heroku’s Early History.

Heroku’s first offering bore little resemblance to what they finally became but it allowed them to pivot and adapt: to drop the offerings that no one cared about (online code editors, no deployments) and concentrate on the stuff they did (github integration, scalability). Early releases discovered what users really wanted and mining that seam of ‘want’ resulted in exponential growth and a $212 million cash buy-out within 3 years.