Agile vs the Long Term Plan

By Cindy on June 20, 2013 • ( 0 )

A common upper management activity is creating a long term plan, partially out of habit and partially because upper management are big picture people so they want a big picture. This often comes into conflict with agile processes where it’s accepted that it’s impossible to know what we will be doing that far in advance when there is so much change in the organization and the environment and there are so many unknowns in the complex software projects we are working on.

Benefits of a Long Term Plan

`Would you tell me, please, which way I ought to go from here?’

`That depends a good deal on where you want to get to,’ said the Cat.

– Alice in Wonderland by Lewis Carroll

Just like Alice, we need to know where we want to end up in order to decide which way to go now. Having a long term plan can guide Product Owners when they’re determining what we need to be working on now and help everyone understand why projects are important. A bigger picture gives context and links projects and stories together into a cohesive whole. One of the major criticisms of scrum is that it can put too much focus on the short-term and cause organizations to lose sight of bigger goals. However keep reading because I don’t believe such myopia is inherent in scrum, but merely another pitfall to avoid and be dealt with.

In preparing for battle I have always found that plans are useless, but planning is indispensable.

— Dwight D. Eisenhower

If you have already thought about possibilities makes it easier to identify your options and react to changing circumstances and emergencies. Long term planning can also make it obvious that you either need to compromise on how much you’re expecting or start resourcing and organizational plans to ramp up capabilities. Hiring, purchasing and acquiring can all be time consuming so often need to be initiated ahead of when they are needed.

Problems with having a Long Term Plan

The main problem with long term plans occurs when people start confusing them with guarantees. People make other commitments (especially commercial, sales and marketing in a development environment) based on the long term plan and don’t consider where they will be if reality sets in and date projections turn out to be inaccurate. Then they cling stubbornly to the plan even when it is becomes obvious that it is no longer relevant.

Another problem relates to the amount of detail in the long term plan. If there is too much detail there will be a lot of wasted time spent creating it and then updating it when changes occur, as they inevitably will. The trick is to get the balance between just enough long term planning to know where you’re going but not so much that you’re wasting significant time on planning and communicating changes. With either no long term plan, or a too detailed long term plan, you risk confusing people so much that they don’t know where they stand.

Long Term Planning Solutions

A nice way to combine agile and long term plans is to have a backlog of what I call “super-epics”. Super-epics represent the big goals of the organization and should be estimated with a different scale, possibly something like t-shirt sizes. Decide what is a realistic amount of t-shirt sizes to achieve in a year, or possibly in a quarter. You can estimate previously completed epics to help determine the likely super-epic velocity and refine this velocity over time the same as you would for a scrum team. From this you can estimate when these bigger goals are likely to be worked on and provide this information as your long term plan. Essentially it’s the same as running Scrum but from a greater height. As you are viewing things from a greater height, these super-epics won’t have a lot of detail until they are close to being implemented and are broken down into regular epics and user stories.

It’s important that progress on the super-epic backlog is regularly reviewed. The organization can run equivalents to the three scrum meetings at this higher level. Planning to decide what work will be attempted in the upcoming year or quarter. A review to see what work has been completed and a retrospective to learn how things can be improved at an organizational level. It will likely also be necessary to review the long term plan more regularly, even every sprint, to see if it is still relevant given team progress and any new opportunities that have arisen. This is best done with reps from every area of the organization so that any changes that are decided upon can be clearly communicated and made with full information. Making changes to the long term plan allows the consequences and opportunity costs of decisions can be more fully understood.

To avoid people making commitments based on uncertain long term plans, keep dates vague for far out items. Start with the year then the quarter then the month, only clarifying the date when the unknowns are reduced along with the risks. Don’t give in to pressure to be more accurate that you can truthfully be. Talk about target dates instead of release dates. It’s amazing the difference a small vocabulary change can make to communicating more clearly.

Related Books: