Pretty image
If you practice going live every couple of weeks, when the big day finally comes, it turns out to be a non-event.

Something that doesn’t get talked about enough in agile development is production readiness—the practice of continuously having your code in a state where it could be deployed at a moment’s notice.

Everybody gets the importance of co-location. Most people understand the speed and efficiency that come from user stories. But rarely do I hear people talk about the importance (and challenge) of continuous production readiness.

In this article I want to get into what agile production readiness is, why it’s so important for you and your project, and what you can do to get there.

What is production readiness?

Production readiness is the practice of ensuring that your software is continuously in a state where it could be shipped at a moment’s notice.

Agile/first-iteration.jpg

It’s an attitude and a mindset in which the team treats the first iteration of their software as something that could potentially be shipped, and each iteration thereafter, they are simply making updates to what they view as a live production system.

Agile/why-do-production-readiness.jpg

Yes. When we are not in production, there are a lot of things we don’t have to worry about.

  • We don’t have to worry about testing (can do that later).

  • We don’t have to fix bugs (can always do that before we go live).

  • We don’t have to demo our software (it’s still in development, after all).

  • And we don’t have to integrate everything together (it’s easier just to hook it all up in the end).

  • </tongue in cheek>

You can see where I am going with this.

These are exactly the kind of things that, as agile practitioners, we want to be doing early and often in our software. We can reduce a lot of risk by acting as if we had to release it every week. That doesn’t mean we do (there are probably a lot of really important features like security and validation that won’t be done in iteration one). But our attitude is: we could ship whatever we have built (in its limited form) if we really had to.

What Does This Buy You?

There are a lot of benefits that come from treating your software with this kind of respect from day one.

It’s cheaper and faster.

When you are regularly producing working software you spend less time:

  • fixing bugs

  • deploying emergency patches

  • re-writing broken features

  • explaining why your project is late and nothing works

And more time:

  • improving your customer experience

  • adding (or removing) new features

  • and wowing your customer in unexpected ways

These benefits don’t come free. You have to write tests, get feedback, and tackle tough problems early. But once you make these investments, you reap great dividends later on in terms of time and money.

You always know where you are.

No need for shenanigans or tomfoolery with the schedule and plan. Features are either done or they are not. It removes any doubt with regard to where you are with the project, and how much you have left to do.

Agile/we-are-here.jpg

It reinforces the good.

To regularly produce shippable code each week there are certain things you’ve got to be doing:

  • You’ve got to break big problems down into smaller, more manageable ones.

  • You’ve got to test from the start.

  • You’ve got to improve and evolve the design as you go.

  • You’ve got to get feedback from your customer.

  • You’ve got to stop and fix things when they come up (can’t just brush them under the carpet).

  • And you’ve got to get off your butt and talk to people.

All good things for any healthy, exciting project.

Going live becomes way less stressful.

Agile/less-stressful.jpg

If you practice going live every couple of weeks, when the big day finally comes, it turns out to be a non-event:

  • You’ve automated just about everything you can.

  • You’ve hit and dealt with all the integration sore points.

  • You know who to talk to and what kind of coffee they like.

  • You’ve basically worked out all the kinks in the deployment process.

And it builds trust.

Not just between you and your customer. But between you and your team.

Once regularly producing shippable code becomes a habit to your team, it’ll just feel good. You are delivering something of value every week and your customer is seeing steady progress in a live system.

Note: This is not an excuse to stop thinking.

And just to be clear, you can’t be dogmatic about this stuff.

You’ve got to look at your situation and context and decide what’s right for you, your team, and your project at that moment in time.

Like Pete Docter, the director of Monsters, Inc. and Up, says: “Pixar films don’t get finished. They just get released.”

Agile/release-me.jpg

If I had to sum it up in one sentence: production readiness is doing enough work on a feature so you could release it into production if you had to.

Agile/warning-aint-easy.jpg

If I am making this sound all apple pie and puppy dog kisses, let me be the first to tell you—it isn’t. You’ve got a lot working against you.

First off, regularly producing shippable code changes how people and teams work. And not everyone is into change.

Secondly, you’ve got an industrial mindset (still alive and well in most companies) that believes that writing software is akin to ditch digging.

Then you’ve got unrealistic expectations, impossible schedules, and perverse incentives that all too regularly sacrifice the long term for the short.

But the good news is that it can be done, and lots of people (including your competitors) are already doing it. It just comes down to choice.

What You Need to Get There

Teams that regularly produce production-ready software usually have some combination of the following three things going for them.

Agile/what-it-takes.jpg

Discipline

In the heat of the battle, with all the dysfunction that comes with the work place, you are going to be tempted like never before to take the easy way out:

  • You are going to be tempted to not write that unit test.

  • You are going to be tempted to guess what the requirement is instead of talking to your customer.

  • You are going to be tempted to check in on top of that broken build (because you know your stuff works).

Agile/temptation.jpg

This is what separates you from everybody else. This is where the courage and discipline to do the right thing (often at your own personal expense) comes in.

Don’t expect much in the way of appreciation initially. You won’t get it.

What you will get is the begrudging respect of your peers (for having the courage to say “enough is enough”) and the self-respect that comes from knowing you produce quality work.

A Culture of Excellence

“Some people aren’t used to an environment where excellence is expected.” –Steve Jobs

Most people aren’t used to doing excellent work <insert favorite excuse here>. The ironic thing is that most people want to do great work. It’s like they are waiting for someone to give them permission.

If this is you—permission granted.

Agile/permission-granted.jpg

You can create a culture of excellence by setting the bar high in the beginning and keeping it there for the duration of the project:

  • Don’t accept untested, poorly implemented features.

  • Don’t accept people abusing the build.

  • Don’t accept bugs—any.

  • Pair.

Setting the bar high in the beginning is way easier than trying to raise it later. Set it high at the start, lead by example, and keep it there for the duration of your project. Make excellence an assumption and it will soon become a habit.

People Who Really Care

I know you care about software. You are here, still with me at the end of this article, when you could be doing any of a thousand other fun things. It’s not you I am worried about. It’s everyone else.

You are going to need to find and track down more people like you—people who care about software, delivery, and excellence.

Finding, and attracting, people with this mindset for quality and craftsmanship is important, because when people care about what they’re doing the little things take care of themselves:

  • You don’t need a lot of rules.

  • You don’t need to write everything down.

  • You don’t need to be afraid.

Because the good people don’t need to be told what to do. They take initiative and do the right thing because they can’t help it—that’s just the way they are built.

“Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” –Dee Hock, founder of Visa

This is the Start

There’s a lot more we could say about production readiness. We haven’t even gotten into the software delivery practices that help us get there. But if you are still here at the end, chances are that’s not going to stop you from finding out what they are.

If your team isn’t thinking like the next iteration’s worth of work needs to be ready for battle, start fostering that culture now. It will pay big dividends later on in terms of time and cash.

And if you’re already there—good for you! Now be vigilant. Don’t get cocky. And show others how to do it. It’s a fun way to work and the more people we can get working this way the more fun it’s going to be for you and me.

Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai.

Send the author your feedback or discuss the article in the magazine forum.