Responding to change vs. Following a plan

“Recalculating …” We’ve all heard it. You’re driving along and take a wrong turn. Your GPS unit responds anxiously, as though frustrated: “Recalculating …”.   Soon, a new set of turn-by-turn instructions appears with a new most-direct route to your destination.

Isn’t it great? Your GPS is smart and flexible enough to re-plan your route when it realizes you’ve gone awry. You don’t have to backtrack and find the way to your original route. Instead, the GPS plots a new course from your current coordinates. It’s a great feature.

Agile software development teams take a similar approach to planning their routes to delivery.  Like your GPS, they begin with a destination goal and plot a course from a starting point. The roads we travel are like our software development projects. They are both a complex network of possible pathways with many potential hazards, delays, and diversions.

The fourth and final value of the Manifesto for Agile Software Development—my last post in this Agile values series—is about responding to change versus following a plan. It is still important for Agile teams to start with a plan, but it is even more critical that they recognize and respond to the many hazards, delays, and diversions that can turn a project sideways.

Similar to your GPS, Agile teams quickly recognize when they are off-course and respond with a new plan to bring a project to its destination. This is achieved by presenting frequent opportunities to revise short-term plans and reflect on progress. For example, in Scrum, an Agile process framework, teams are asked to plan every day and at every development iteration. In fact, teams that employ Scrum are always planning rather than following a plan.

The reason to be ‘always planning’ is that with each passing day, Agile teams learn more about the goals they strive to achieve, the work they are doing and the environment in which they work. They gain knowledge and information as they go. And obviously a newer plan is more predictable than its predecessor—certainly better than any plan developed at the beginning of the project.

The new information Agile teams gain comes in the form of validating previous estimates or predictions. When teams guess correctly, they become more confident. As confidence builds, teams gain experience.  The more frequently you stop and validate your predictions, the more quickly you will gain experience. With experience, Agile teams can confidently and predictably deliver the commitments made every day, during every iteration.

New information can also be gained from something that can never be anticipated—change. Agile teams that are always in planning mode should consider changes in goals, the work, or the environment, when they craft a new plan. Agile teams respond to change, rather than try to control it. As changes in direction are identified, Agile teams devise new plans around them. They don’t attempt to bring a project back on the original track. Instead, they simply plot a new course from the current state of the project. Responding to change, Agile teams recalculate.

As we navigate our projects to delivery, or drive to a destination, we need to quickly respond to the many hazards, delays, and diversions we may encounter along the way. The ability to recognize when a project is off-course, and to quickly reformulate a plan when things have gone awry, provides the best opportunity to mitigate the impact of those diversions. Your GPS has this ability. And so does your Agile software development team.

Share on

linkedin sharing button twitter sharing button