Plans Change. So Why Bother to Plan?

It’s true. Plans change. They change often. In fact, elaborate, detailed plans will change almost continually. Is it worth the effort to plan?

At times, agile software development is criticized because it’s perceived to lack planning. The perception is that developers simply jump in and start writing code. The process of writing code and delivering the executables to the users determines the end result. Plans, managers and metrics are cast aside as unimportant.

While there are some developers guilty of supporting such ideas, most don’t. Plans have value — when done appropriately.

Consider a simple example. Let’s say you intend to embark on a hiking trip tomorrow. You’ll be hiking in an area that you’ve never been through before. You know it’s wooded and hilly but you don’t know much else about it. You don’t even know how far you’ll hike. It will depend on how you feel during the trek and what the weather is like.

If you didn’t do any planning at all, tomorrow you’ll simply head out as is — wearing whatever you happen to have on, carrying whatever happens to be handy. You might end up hiking in casual shoes and slacks with no supplies or necessities. Crazy, right?

Plan. Don’t Agonize.

Clearly, you’d do some minimal planning. You’d assemble proper hiking clothing and set aside a few necessities such as a water bottle, a few munchies, jacket, hat, etc. You wouldn’t have a detailed route nor even know exactly what to expect but you’d be ready for the most common situations encountered by hikers.

A plan for dealing with emergencies would be an extra measure of safety. What will do if you fall and suffer a serious cut or a broken bone? Could you get lost and unable to find your way back? If the area is heavily traveled, these may be minor concerns but if the area is remote, a little planning could save your life.

As your hike progresses, you’ll make detailed decisions such as which paths to follow, what pictures to take, and when to stop and rest. These are decisions that would be difficult, if not impossible, to make in advance.

Agile Development Needs Agile Planning

A similar concept applies to agile software development. We don’t lay out elaborate, detailed plans. Such planning takes a lot of time and effort at the outset and also takes an ongoing commitment to keeping the plans current.

What makes more sense to us is defining a high-level plan, and making detailed decisions that align with the plan along the way. The plan keeps us headed in the right direction at the appropriate speed. The plan does not determine precisely what will be done or when. It guides us to the destination without dictating how we’ll get there.

How much planning should you do at the outset? Enough to give you confidence that the major project goals can be achieved. You have defined the major goals, right?

photo credit: DanieVDM via photopin cc

Updated: December 17, 2012 — 10:36 pm


  1. Well see, we agree on some things.

    This is something I’ve been wanting to blog about and probably still will blog about but this is an excellent post.

    The problem with agile lies in binary thinking — either you plan OR you allow for change.

    Of course one should do both…

    One should plan and also plan to have divergences or changes…. We need more AND in this world.

    Plan AND adhoc. Not just plan OR adhoc


    1. Yes, agile development is not either/or. It’s about finding the best ‘minimalist’ approach within your environment. It takes time and experience to get there.

      1. Well, whether agile development “is” or “isn’t” either/or, or should or shouldn’t be either or, the extant reality is that

        1) Everyone has a different opinion of what agile is or isn’t

        2) Most of what is practiced in agile land is strict by the book recipes with plenty of binary thinking.

        In other words, whether agilists should or should not, worship idols, they DO worship idols.

        And every agile coach has a different opinion of which idols should be worshipped.

        So for that and many reasons, I don’t think it’s possible to “reform” agile….agile is too tainted for reform or serious conversations.

        It’s time to leave agile behind and create something new.


Comments are closed.