Defining ‘Done’: clearing the path to production

With agile, work that is ‘Done’ is ready to be put live. But are you sure your feature is done? Can you tell if you could really put it live?

To elaborate on this theme, I want to look at two projects I’ve been involved with in my career. Each took a different approach to this definition of done – resulting in two very different outcomes.

The one that wasn’t done

The first project, fairly early in my career, was to deliver a feature-rich web-based portal.

We had a year to develop the portal before it was due to be launched. We started with an inception and a small cross functional team and set about creating thin slices of functionality, ticking off features as being ‘done’. Our automated tests allowed us to release to our fully tested staging environment every other day. We rapidly and steadily grew to having around 80 people working on features and content for our portal, and as requirements were fed in, features and content would rapidly fly out. Everyone was really happy with what we were doing. We. Were. Agile!

Then we had a change of senior leadership, swiftly followed by a change of strategic direction.

Although our portal was still relevant, suddenly there was no appetite to launch it. The project was cancelled and our highly mature teams were disbanded. We all went home, nothing ever went live, no value was ever recovered. Millions of pounds were wasted. Devastating.

At the time, I felt that this situation was completely outside of my control – but was it? What could I have done differently to try and prevent so much money from being wasted?

The one where done came first

The second project was with Equal Experts, when our team was asked to deliver an analytics platform.

Once again, we started with an inception and a small cross functional team. Within days we’d created a very small, thin slice of (really rather awesome) functionality, which our client loved. They were astonished with how quickly we’d given them a glimpse of what we were capable of providing. They were excited about the value this would deliver and were bursting with ideas of where to go next to make it even better. They asked us to work on adding more features.

This time, the team said “hold on a second…..”

“Where do you envisage hosting this functionality? Who is going to operate it? Who is going to monitor it? Who is going to manage access to it? What is our path to production? …“

“Don’t worry about it”, came the reply. “We’ll sort that, you just build the product.”

We did worry about it. We kept asking questions and pushing for answers. The lack of answers lead us to understand that operating whatever we built in a production environment hadn’t been thought through.

Nothing is done if it can’t go live

We’d shown the client how quickly we could deliver functionality. But we had no way of predicting how long it would take to derive business value from that functionality, since we couldn’t see our path to production. This was a massive risk, since it was a totally unknown cost.

To help the client think this through, we proposed putting a “hello world” feature into production. This simple feature would meet all of the appropriate security and non-functional requirements. We used this approach to drive out the many, many conversations and negotiations that the business needed to have about our path to production.

At the beginning of this project, the client expected the cutting-edge functionality to be the difficult part. As we’ve seen though, it’s often the business’ readiness to put work live that is the real challenge to crack.

By tackling it head-on, we encouraged the client to spend 6 months navigating its internal politics to lay a clear path to production for the delivery team. What’s more, they are grateful that we pushed them not to underestimate how painful the business change aspect of digital delivery can be. By front-loading the risk to clear the path, we were able to provide the client with true visibility of how long it will take for us to build features that deliver real value.

Looking back at the first project, I now wonder if we could have done more earlier on. This is what learning from failure looks like. Pushing the uncomfortable conversations is a remarkably effective way to prevent subsequent waste, and it’s something I’ll be doing on every project to come.