From Here to Continuous Delivery

Situation Normal

There’s a clear pattern for software development. A pattern of lost opportunity.

In most, if not all, places where I’m called in the base question deals with the inability to deliver. Management sees that the plans they have are simply not going to be realised.

Business opportunities are lost waiting. Waiting for the next available spot in the product roadmap. Waiting for the development team to finish ‘stabilizing’ the system. Waiting for lengthy ‘refactoring’ phase to complete. Waiting for new servers to be delivered (in only six weeks!). Waiting for a PMO organisation to complete project initiation and relative priority. Waiting for development to complete coding. Waiting for a testing phase to complete. Waiting for management to analyse long lists of known issues and risks so they can decide whether a release is possible.

Anyway, there’s waiting involved.

As with any interesting problem, this one doesn’t have a single identifiable cause. The marketing department will blame the development team for being too slow. The development team will blame the marketing team for not knowing what they want. The development manager will blame his team for being slow and writing buggy code and all his stakeholders for not being realistic. Upper management will blame the marketing and development managers for being slow and not delivering.

They are, all of them, right.

And you can’t point a finger at one root cause. Yes, development messed up and wrote crappy, unmaintainable code. Yes, the business focused too much on short term gains and put too much pressure on development to deliver early. Yes, management should have focused on mission and strategy so the rest of the company could have managed scope. Yes, all were too hasty hiring new people when the pressure was on, and too much incompetence entered the company.

I’m willing to bet you’ve heard most of those complaints, made a few of them, and been the subject of others.

How do we get out of this vicious circle?

Step one: Fix execution

Stop. You’re trying to do too many things at once. The first thing that needs to be done is to get your technical house in order. As long as you can’t deliver a working, tested, system at the drop of a hat, you’ll always be too slow.

So now, immediately, start changing your technical practices to support better quality. Deploy automatically, Test automatically, test everything, and test in all manner of ways. Change your architecture to support quick change and better practices. And do all that while still delivering value.

That sounds difficult. It is. But it’s possible. I’ve done it. Others have.

You will slow down a little, initially. But you can use architectural changes, such as a Strangler Pattern or Branch by Abstraction, to quickly start over without throwing all your existing systems away.

And focus on quality. This is hard. Management needs to be extremely explicit in this. Technical teams are used to a focus on progress and speed, and will automatically revert to those and subvert the quality of your system in any case of perceived pressure.

Focus on quality

Add all the elements that give you more control over your systems. That means fully automated deployment, include the automated testing that you need to be confident enough to have every push of a developer going to production. Then make sure that actually happens.

Introduce feature toggles, so that your decision to supply a new feature to end-users becomes exactly that: a decision. And not related to your release cycle.

Measure everything.

Measure the results of new functionality on your business. Whether it’s in use of features for an internal system, or all your Pirate Metrics for your product website.

Step two: Fix alignment

Now that you’re able to deliver, it’s time to start making use of the opportunities that gives you.

You already know, now, how to measure the effects new features have on the use of your product. For some, that is already a direct link to the money being made by the product. For the funnel on a product website or web-shop, we can calculate the revenue increase (or decrease) from a change. Other types of applications need a little more work and imagination, but we can certainly get to some measure of value.

If you can’t measure the effects of your work, you can be sure you are not doing the right things.

But that is all still a bottom-up approach. Effective for short term goals, but potentially dangerous if the metrics we use aren’t aligned with longer term business goals.

/images/2015/06/im_example1.png

If you have your mission and vision defined for you company, and there’s a strategy that you expect will bring you there, you should now spend some time to hammering out a small set of actionable metrics that we can use to prioritize our opportunities on a day-to-day basis. The post linked to above shows a way to determine that, based on Gojko Adzic’s excellent Impact Mapping.

You pick a very few metrics. In fact, you should aim for that One Metric That Matters. This is your compass, steering the whole of the company. Be careful that you don’t have other metrics hidden that undermine this, for instance in a target/bonus system.

/images/2015/06/dashboard-metrics.jpg

This OMTM should be permanently visible for everyone. It should be continuously, and automatically measured and updated. And it should be directly coupled to the various day-to-day activities of everyone in your company.

On the level of product development, all your priorities should be determined by the impact on your OMTM.

For most companies, this level of focus and clarity of purpose is far off. It requires clear vision and leadership. And will transform your organisation.

When are you getting started?