Plan for Change

Deconstructing the Agile Manifesto – Part 1


When I’ve asked Program Managers and other team leaders why they don’t plan their projects all the way through to the next release, they almost always say it’s pointless. Why? “Because the requirements will change and planning things too far ahead will waste time.”

 

Yes. It will. Time will be wasted. You may then jump to the following conclusion:

 

               Time Available – Time Wasted =  Time Used Constructively

 

But what about all the things that won’t change? Changing requirements will create a delta between the known and the unknown. The known is your baseline. For many projects, one or more stakeholders expect a deliverable product by a specific date. That deliverable comprises an explicit set of capabilities. The baseline represents when that product will be complete, under the assumption that nothing will change.

 

Something will almost certainly change.

 

Agility is the ability to respond to changing requirements with as little pain as possible.

 

Is Scrum Predictable?
Scrum proponents will argue that predictability is possible within Scrum, and not just for the next iteration—and they would be correct. But predictable schedules within Scrum demand some specific conditions.

 

The essential Scrum metric that leads to predictable outcomes is Velocity. If you estimate your Stories in either Story Points or hours, you can measure how many units your team completes each Sprint. If that number is consistent over several iterations, then you know your team’s Velocity, and can use that number to project far into the future. You still need to estimate the known Stories early in the project, but you can use fuzzier methods, like Story Points, to calculate schedules accurately enough to support business goals.

 

Many Scrum teams have settled into predictable rhythms and deliver new functionality with clockwork reliability. The catch is knowing your Velocity, because Velocity is only useful if it’s consistent from Sprint to Sprint, and several factors can cause Velocity to fluctuate wildly, including team stability, the types of business problems you’re solving, the technology stack on which you’re building those solutions, where you are in your product lifecycle, team size, and seasonal effects such as vacations, illnesses, holidays, and even seasonal moods.

 

Planning for Change
If you believe change is inevitable and continual, then you’ll want a model you can use to predict the impact of change. Just as a sales team uses a spreadsheet to predict revenue, you’ll use your estimated backlog or schedule to determine how each change may or may not impact your project. Armed with data, you can make informed recommendations to your stakeholders.

 

Not every Agile project has a fixed deadline. However, if your project does have a deadline, you’ll need a plan you can use to measure the impact of changes. With an end-to-end project plan, you can plug in the new tasks and see how they impact your dates. So, whether you’re  using Scrum or waterfall or both, you’ll need estimates for all the features required in your next viable customer release, by which I mean the next collection of features that enable one or more useful business processes.

 

For Agile teams, this means estimating far into the future. Whether you use Story Points or hours, take your best guess at every Story in the Product Backlog. The material that’s too fuzzy to estimate represents risk. It’s better to know that early in the project, when there is still time to ask your Product Owner for clarification.

 

For waterfall teams, you already know the drill. Estimate your tasks in hours, link up the dependencies, and insert scope changes to see how the plan expands or contracts (it could happen).

 

Changes in scope will have varying effects on your schedule. Some changes may push out your ship date, day for day. Others will land outside the critical path and won’t affect your ship date at all. For any project with more than two or three contributors, the only way to determine the impact of a change is to insert it into a plan and re-calculate the schedule.

 

A carpenter doesn’t pre-cut all her lumber based on a blueprint. She walks the site with a tape measure and pencil. Likewise, a project manager must continually remeasure and adjust the plan.