go to content go to search box go to global site navigation

Lonely Planet blog

Behind the scenes

Website technology success part 2: the process

By admin   19 December 2008 10:14am Europe/London

It is the fantasy of every business sponsor that IT projects might one-day behave more like their buttoned-down legal or sales projects. They go so predictably!

  1. Spend days (or months) up-front ritually drafting and negotiating a detailed contract that covers every possible role, responsibility and remedy for a failed outcome.
  2. Produce a 3cm thick document focused on the penalties that will frighten the parties into performing on time, on budget and to specification. The weight of that thing feels so good!
  3. Have a ritualized signing ceremony to lock in the expectations.
  4. Deliver the outcome, sleeping comfortably at nights using the contract as a pillow.

It’s not reasonable for business people to believe that anyone would welch on a 3cm thick agreement and a highly governed process – coming in late, running over costs, or under-delivering. It’s a guaranteed result… or dammit someone will pay!

The ritualistic specifications document preparation, signoffs, handovers, and the secret handshakes of waterfall development methodologies are a remarkably good mimics of the ‘business’ contract process. I should know – I used to coach MethodOne in a past life.

So how come 80% of IT projects still fail to deliver on at least one of the key components, leaving the business owners as the ones out of pocket, cursing the IT Crowd, and wondering how they got suckered yet again?

Agile software development is initially not very appealing to business-people, because good agile scrum-car_smpractitioners just won’t fall for trying to make those business people comfortable by predicting and committing to everything up-front. There are no ream-thick contracts – there is just process, transparency and people.

Building our commitment to agile software delivery was as big a deal as building a 4 million page website for Lonely Planet. At lunch one day in August 2008, Ian P (our wise GM of Human Resources) and I were discussing the challenge of doing agile well and we came up with an interesting metaphor.

Business owners (substitute product managers, sponsors, GMs, Online Directors…anyone with money) all want a project delivery as predictable as traveling by air. They expect to know when the flight leaves, where the flight leaves, which gate, their seat number, exactly where it lands (maybe even the runway number), and when it is scheduled to land. It’s amazing. It gives confidence. Your ticket is your contract.

Trouble is, there are way too many subterranean approaches when it comes to software development as a metaphorical plane flight (Ian’s colourful term – he worked for many years in the airline industry).

balloon-agile-3_sm1Agile development is much more like a balloon ride.

In competitive ballooning there’s a discipline called Convergent Navigational Task. The target is placed in a secure area – usually the festival site. You can launch your balloon anywhere outside a 5km radius of the target, and the winner is the balloonist who drops their marker closest to the X. At top level, they immediately lift off again and take on the next task. Short hops, fail quickly if you must, and get on with it.

Great balloon race captains think really hard about the starting point. They are accepting of wind changes along the way, adapt to them quickly, and have an experienced chase team follow them from the ground, measuring and tracking progress.

These balloons are big, expensive machines to control, sometimes slow to react to pilot inputs, at the mercy of the elements. Captains are intuitive risk managers, and it takes thousands of hours ‘doing’ to be world-class.

Perhaps the greatest challenge was learning to manage multiple agile streams of development in parallel. Splitting application/product streams into horizontal layers (front end, services, back end) led to a lack of conversations from end to end. Moving to vertical integration (follow data from end to end) later in the project brought a fair few disconnections to light, but not too late to correct course and jettison some architectural ballast from the balloon to quickly gain altitude.

The sooner you get used to the thrill and risk of  ballooning, get some on-the-job Agile coaching, and admit that carrying around a 3 cm thick pile of paper is not really being in control, the sooner you’ll get some proper, 21st century IT. Perhaps every agile project initiation should include a sunrise balloon ride for the business sponsor?

img_board_sm

The pig emerges from the agile python as website launch approaches - a nearly full story board prior to launch day.