Continuous delivery: release early, release often

If you’re in the business of building a car, you only really only have one chance to get it right. Those years of research and development, trials, testing, marketing and building culminate in a single, big release – your car launch. You only have one chance because by the time your customers drive your car away from the lot, it’s too late to fix that overheating problem with the brakes, or add another 0.5L engine capacity. Shame.

Software used to be the same way. A software project would be analysed, specified, analysed again, specified again, built and re-built and finally, after months or years of development, would be burned onto a CD or floppy disks, put in a box and sent to a store. Before the internet getting updates to software was tricky. You had just one shot to get it right.

Today, we live in a very different software world – especially true for those of us working on web products. With the internet we have a delivery immediacy unlike any other product manufacturing system in the world. We can make a change today and our customers see it in their product, today. You can add a new feature today and start generating new revenue or new customer acquisitions tomorrow.

It goes further. You can release a feature today, and watch, in real time, how your users interact with it. If your key metrics go down, you can roll the feature back out. If there’s a problem, you can either fix it quickly, or roll it back. You have the power to interact directly with your customers immediately over the best channel possible: the product itself.

This is what continuous delivery is all about. It’s like a beautiful gift for any product developer, and I think not making the most of it is a waste of that gift. Release early, release often.

Be like water

Flowing water

I remember reading about a concept from Taoism called Wei Wu Wei. Roughly translated it means “action without action”, or “effortless action”. In the same way that running water naturally and effortlessly flows around obstacles, so should our actions be thoughtful and mindful, but effortless.

Bruce Lee, when describing his martial art Jeet Kune Do, said:

“Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.”

Software development process is like this: like water. The path from concept to released software is a flowing stream, and as product creators it is our responsibility to ensure that it can flow easily and effortlessly.

Your product development process can either help the stream flow, or it can create dams. A broken development server, for example, is a dam. A bureaucratic and document-heavy change management process is a dam. Dams create tension and confusion. Dams create waste.

Focus on avoiding wasteful process. Tear down dams.

Be like water.

Software’s worst enemy: consensus

A vote for everybody is a vote for nobody.

A committee (parliament) voting on something

Photo from here.

The best software and products dazzle out of the box. They set new boundaries and exceed expectations. And they don’t settle for less than outstanding.

Designing software with lots of stakeholders is complicated, but when the product manager prioritises reaching a compromise between all the stakeholders instead of pushing for unique, beautiful and remarkable, the result is more often than not unspectacular.

Worse still are product teams that are set up without a clear product leader – product teams comprised of a group of ‘area’ product managers, who are each responsible for their own product piece, but who together, and in a purely democratic way, are supposed to come up with one aligned, cohesive and most of all compelling end-to-end product proposition. This is called ‘design by committee’, and nearly always ends in mediocrity.

The problem here is that each area product owner is focussed on his or her piece of the overall proposition, and each have their own priorities, visions and strategies. Just packing these guys together in a room is not going to result in them coming up with a remarkable and balanced product proposition. What this scenario often results in is some kind of portal; it’s at best a mash-up of separate products – something that tries to do everything and ends up doing nothing particularly well.

A product needs a product leader – someone who is willing to make decisions that displease some people and to fight for the ultimate product vision. Michael Arrington, founder of Techcrunch, says:

“Product should be a dictatorship. Not consensus driven. There are casualties. Hurt feelings. Angry users. But all of those things are necessary if you’re going to create something unique.”

A product team should not be a democracy. A product team needs a leader; it needs someone who calls the shots and makes the decisions that will displease, disappoint and delight.

Consensus-driven teams often have challenges understanding and agreeing on what is important now (prioritisation) and what is important overall (scope). A product team made up of area POs have by definition conflicting objectives. The PO for component X believes that part is the key product proposition; the PO for component Y sees it differently. The result of the ensuing debate is often a compromise; “ok, let’s build it all”. In their fantastic book Getting Real, 37 Signals founders share their view on software design:

“Some people argue software should be agnostic. They say it’s arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible. We think that’s bullshit.”

Of course, there are important requirements that the ‘master’ Product Owner needs to fill. He or she needs to understand the product and be able to present a compelling vision. He or she needs to be able to make difficult decisions and disappoint some people, but be convincing and considerate in the explanation. Most of all, he or she needs to understand the product extremes that make the product unique and remarkable, and not compromise on them. In other words, they need to be a leader.

I’ve seen product teams try to fill this role with a Program Manager. It doesn’t work: a roadmap slide is not a product vision. I’ve seen product teams try to fill this role with a Requirements Manager. It doesn’t work: a requirements list, or even a product backlog, is not a product vision. I’ve seen product teams try to fill this role with senior managers who poke their heads in every so often. It doesn’t work: a day’s worth of rash, under-informed decision making does not substitute consistent and detailed thought.

A product needs a product leader. And if that’s you, then my tip is: don’t give in to consensus, and don’t settle! You will never please everyone… not all users, not all colleagues, not all bosses. So please, give up trying. Sometimes innovation comes from having the courage to disappoint people (and the wisdom to know when!).

Focusing on your product vision

In agile we promote working in small iterations, and building just enough to solve your problem today. I try to encourage my team to avoid designing a problem to the very end, but to focus only on what is necessary to solve the first; most basic problem.

BUT: focus and iterative execution should not be confused with a lack of vision…

Vision (why are we doing all this? What direction are we heading in?) is long term, far reaching and top-level, and vision is crucial to help you make the right decisions about what is important today, and what will be important tomorrow.

The execution against the vision however is based on small increments; small, little steps that move you towards what the vision looks like today. I say today, because the vision can change. In fact, the vision should change over time; it should adapt and adjust to evolving competition and user/customer feedback. Building in iterations allows your vision to adjust, and allows you to adjust to your vision.

Working in agile is no excuse to forget your product vision. Agile is all about taking small steps and adjusting along the way: but you still need to know where you’re going.

The dinosaur might be the solution

What happens if you start building a castle and you end up with a dinosaur?
That’s ok – maybe in the end the dinosaur is the solution to your actual problem.

What happens if you build a castle, but it turns out you really needed a dinosaur? Well, then you’re in trouble.

With any creative endeavour, whether it’s a software project or something else entirely, build quickly just enough to solve your problem today. Start with the problem, break it down into smaller problems and prioritise them – then work on one problem at a time.

The thing with designing a whole castle is that it’s hard to know where to stop. How many turrets are enough? How thick should the walls be? How deep do we need the moat? Even if you can answer all of these questions today (and chances are, you can’t), the time you invest designing complex castle architecture could have been spent building the wall you really need to keep the attacking vikings out. Then during the years you spend building your mega-castle you are relatively unprotected, since the value of your castle comes when it’s complete.

Even if a whole castle is what you need now, chances are by the time you finish building the castle the world will have changed. How do you know you will still need a castle in 2 or 3 years? What if by then you need a dinosaur?

Solve today’s problem today, and save tomorrow’s problem for tomorrow. As counter-intuitive as it sounds, solving problems of the future today is very often not smart preparation, but waste.