The idea here is not to pick an achievable goal, or even a stretch goal, but instead a goal that seems unachievable. Instead of an end-state, the goal defines a journey - a direction for long-term improvement.
Let's take one more look at that goal.
For example, one of the companies we work with wanted to "automate testing" by having a computer run predefined scripts through the user interface in order to deploy more often. They had no interest in automating the deploys, which consisted of turning the servers off, pushing a new build and turning the servers back on. Rolling out the deploys took over an hour, which meant the software could only be deployed late nights during a weekend.
If we automated the checking, but not the deploys, the process would take close to a year and the fastest deploys possible would be once a week.
Instead of starting with a target (like "automate testing"), we start with an objective, then analyze the entire test/fix/deploy process to find where the impediments are.
Step 2 – gap analysis and identify the next target condition
Once we know the desired state, we study the current system to identify gaps that matter. In this example, we are talking about release management, so everything from the last commit of code to version control ("code complete") to on the production servers. Some organizations consider immediate implementation support ("stabilizing") part of release management. Others run an entire mini-project around the end game of a deploy, including days to months of regression testing, a large series of bug fixes that next to be triaged, done or marked WILL_NOT_FIX, then re-tested. Another common mini-project is the deploy itself, which can include days of coordination and a final, multi-hour rollout process.
One way to conduct a gap analysis is to look at the entire process: Build, Test, Fix, Deploy-Coordinate, Deploy/Do -- looking at how long each step takes if done ideally, and the various ways that step breaks down. Eventually, you'll find a bottleneck: a step that’s holding back improvement the most. Sometimes, the what-to-fix isn't the bottleneck, but the easiest to improve right now.
Once what to improve starts to come into view, the next question is how to improve it – what the next small step should look like.
The Toyota Kata term for this is the target condition. That's different than a numeric quota, like "12 deploys per year." Numeric quotas are dangerous because they are so easy to game. As Charles Goodhart put it "when a measure becomes a target it ceases to be a good measure."
Target conditions don't just give a number, but also describes the operating attributes, how the game will be played to obtain the results desired. "Shrink the build to 10 minutes" is a quota; adapt a Continuous Integration (CI) system or build server like Jenkins to automate builds after every commit looks more like a target condition. Target conditions also include a delivery date, which can be established in concert with the team.
Sign up for CIO Asia eNewsletters.