Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Test, deploy, release ... repeat

Matthew Heusser | Sept. 22, 2015
When it comes to release management, what sounds great in theory doesn’t always work in practice. Here are four steps to building an effective strategy.

not agile thinkstock

The term "release management" might bring images to your mind of meetings that run from 4 p.m. - 8 a.m. and involve a build, sign-offs and lots of coffee, soda and vending machine snacks. 

Or you might think of a programmer clicking a deploy link. 

Not all companies can trigger a deployment whenever they're ready (relying on the version control safety net, of course), and not all should, but most can benefit from moving away from the first example and toward the last. 

I’ve written before how many organizations can reduce or eliminate regression testing, making rollouts more predictable and less painful. 

While that might sound great in theory, getting there is a different story. One way to achieve what may sound like deployment nirvana is the Toyota Kata, an improvement method that Mike Rother learned from Toyota.

rother toyota kata

What is the Toyota Kata method? 

Take a meeting with six people discussing  the release process, and you'll likely leave with 12–20 ideas for improvement. Calculating the return on investment for those improvements won't be easy. Even if you can rank the improvements in some way, implementing the five or six best ideas will not have a systematic effect. 

Before you can talk about improvement, you need to define a goal. 

The Toyota Kata refers to this as establishing “strategic direction.” To Stephen Bungay, though, it is strategic intent and Hoshin Kanri calls it strategy deployment. 

Once you have a strategic direction, you can find out where the gaps are, then establish immediate steps, called a target condition and move toward that goal. 

Step 1 – desired state 

Having a test tooling or a rotating release manager, incident manager, or ITIL certification are certainly goals, but exactly what that means for software development is not defined. Test tooling and automation could be a desired state, if the goal included releasing more often, decreasing the time for regression test/fix/test to under one day, and so on.  Here are a few specific examples: 

  • Move from last commit of software to deployed within one hour.
  • Be able to fix issues in production by rollback within one hour of notification.
  • Develop software in pieces small enough to build and deploy in the same day.
  • Reduce the risk to a production deploy so much that any team member can make the deploy without a release manager.
  • Shrink the production support team by half.
  • Bring production support into the shipping team. 

Depending on where you work, some of these might be the existing state – or they might sound unbelievable. Some also read like arbitrary measures --  and they are. In order to make these strategic, each goal needs a "so that..." attached - what the final benefit will be to the organization. For example, shrinking production support allows those team members to switch to new feature development; pushing to production in an hour changes the economics of deploys to encourage deploys and so on. Those benefits will be grounded in the organization, and can't be predicted here. 


1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.