Agile Advisor

Agile Planning Benefits

Agile planning does not mean "no planning"; it means a flexible plan that changes with the situation.

• By Aaron Bjork
• 09/20/2011

One of the most common myths with regards to agile teams centers on planning.  It seems there are large factions who believe being "Agile" means avoiding planning.  It's a common stance taken by folks who have never been on an agile team, or who love to defend the status quo.  This myth couldn't be further from the truth, and I find myself increasingly frustrated when people use it as a way to avoid agile practices.  In fact, I'd argue that a healthy agile team does just as much (if not more) planning than a team using a traditional software development methodology.  In this month's column I want to dig into the key differences between planning on an agile team and traditional planning.

Planning Approaches
The first and largest difference revolves around how to think about planning and the value it brings to a project and team.  A traditional approach to planning requires you to spend large amounts of time studying requirements, architecture and design options in an attempt to produce a plan that will guide you to success.  Without the correct initial plan, the project won't succeed.  Agile teams think differently.  An agile approach to planning also involves studying requirements, architecture, and design; but an agile approach puts a stronger emphasis on getting started on the well-known and well-understood requirements and architecture over continued planning.  The expectation is that the team will derive greater value from starting on the known requirements than it would from continuing to invest in additional planning.  Said differently, the value of any learning that results from getting started will have a greater return on investment (ROI) than the value from continued planning. 

ROI
Figure 1 shows the expected ROI using a traditional approach to planning.  Notice that the ROI in the early stages is significantly higher than the ROI in the later stages.  This is quite common because in the early stages of planning the team is able to uncover and solve a lot of the well-known problems.  Every hour spent on the planning results in a high return on that investment.

[Click on image for larger view.]

Figure 1. Traditional planning gives strong initial benefits, but they don't continue at the same level.

However, the longer planning continues, the lower the team's confidence level in the overall plan.  ROI starts to diminish significantly.  Why?  Because the plan is building on assumptions made in the early stages, and not on any concrete learning.

Contrast this with Figure 2, which shows an agile approach to planning.  Planning begins in the same manner; but shortly after the planning starts, it's stopped to begin execution.  Why?  Because the team anticipates learning more from getting started than it would learn from continued planning.   After the team has executed on what is well-known and well-understood, it returns to planning.  This process continues throughout the duration of the project.

[Click on image for larger view.]

Figure 2. The ROI of agile planning continues to deliver greater returns over time than does traditional planning.

Let's take a look at a non-software scenario as an example.  Imagine that you're planning a road trip across the country from Seattle to Boston.  You're likely take the time to plan your route to ensure you know the correct the freeways and highways you'll travel on.  You're also likely to plan how far you think you'll be able to travel each day.  It's a good investment of time, and it will help make the trip successful.  

However, you're unlikely to plan each and every stop upfront before leaving.  You could calculate your ideal mileage for each day of the trip, and even go so far as to plan when and where you'll stop for gas.  The return that type of time investment is likely to be very, very low.  Things change, and you want to have flexibility to adjust and react to those changes.  You clearly want to have a plan for where you're headed and approximately how you'll get there.  But you also want to leave room to adjust your plan as the trip begins to unfold.  This is similar to an agile approach to planning.

Responding to Change
This line of thinking comes from the fourth statement in the Agile Manifesto: an agile team values "Responding to change over following a plan."  Note that the manifesto doesn't state that an Agile team does no planning; instead, it makes a clear statement that an agile team puts more emphasis on how it responds to change than it does over the team's ability to follow a plan.  An agile team expects that once it gets started, executing the plan is more than likely to change based on what the team has learned. 

George Patton, one of the most famous generals in American history, stated rather eloquently "A good plan violently executed now is better than a perfect plan executed next week."  As your teams look to improve planning and increase the value derived from that planning, try an agile approach and see if your team doesn't see a higher return on its investment.