If you follow me on Twitter (@asbiv) or if you read a post I made to my blog last week, you may have noticed that I recently started reading The Emperor’s Handbook by Marcus Aurelius, a Roman Emperor and a Stoic.  When writing about the ways that people ‘abuse their souls’ Aurelius decries those whose “actions and efforts have no apparent purpose and [who therefore]… operate at random and without consequence.”  All of life, according to Aurelius, ought to be lived with a goal in mind; without planning and conscious effort, people end up living random and meaningless lives.

Although I don’t agree with everything that Aurelius has to say about life, I do agree that planning is important to avoid wasting time and energy on scattered pursuits.  Knowing the value of consistent planning is a key part of why I am writing this set of blog posts about planning in Agile.  Unfortunately, I also know from experience that planning – especially for a team of people collaborating together – can be very challenging for a number of reasons.

1. Planning is tough to do on a consistent basis because it requires being proactive and deliberate in the midst of busyness.  It is simply easier to be reactive or to rely on vague goals than it is to do the hard work of analyzing your alternatives, determining your priorities, and structuring your time and effort to pursue what matters most.  I like the idea of planning more than the discipline involved in doing it well, and so I often find that the busyness of my days swamps the efforts I make to establish and stick with a plan.
2. When it comes to planning Agile software development, effective planning means understanding the market well enough to know what to start building when – and that too is difficult.  Reacting to the latest piece of feedback I received or simply going with my gut feeling is easier than gathering the data the product team needs to plan well.
3. Creating and sticking with a plan for Agile development can also be challenging because it requires saying no (or at least not yet) to seemingly urgent requests.  As I’ve made clear in many previous blog posts I am not at all suggesting that solid Agile planning somehow means that you never say yes to new ideas that disrupt your prior plans; however, Agile planning is not the same thing as ‘pivoting’ every time you get a new piece of information from potential prospects.  A flexible product plan leaves room for appropriate responsiveness, but the hard work of planning is also crucial to avoid ‘operating at random’ by reacting to every apparently urgent request.
4. Another reason that Agile planning can be tough is the simple fact that it takes time to plan, estimate, and prioritize and gathering the team to do this work regularly can sometimes feel like a distraction from the ‘real work’ of writing and testing code or selling the product.  Getting buy-in from the team about the fact that the work of planning is truly worth the effort can be challenging – especially if the team is used to being reactive or having only vague goals rather than specific and measurable plans.  This ties into yet another reason why Agile planning can be difficult.
5. True Agile planning isn’t a ‘once and done’ activity like waterfall project planning; it involves daily interaction with both the development team and the market so that you can respond flexibly to new information.  Creating an initial plan is only the first step in Agile software development.  As the team works together and the product vision evolves, you will all learn new and important information that will shape ongoing planning – information about technology, about the true complexity of the product and features you are building, and about market demands for your product.  This collaborative learning means that Agile plans are always developing and so planning is a never-ending part of creating and enhancing a product.
6. Finally, I find Agile planning can be difficult because it has to be a collaborative engagement.  Since no one person on the team has all of the information required to plan fully, Agile planning isn’t something I can simply sit in a room and do on my own or that I can squeeze into short blocks of free time I find during a week.  Multiple people – often the entire team – need to be actively involved in the planning process, which means planning has to be a deliberate activity.

For all of these reasons Agile planning is a difficult undertaking even when the whole organization understands and buys into this approach.  The firm where I work has been growing as an Agile shop for over seven years and we are still wrestling with how to improve in this area.  Even as I start this blog arc on planning our company is trying to initiate a deeper level of planning discipline that will no doubt inform the things I write about in the coming weeks and months.  No one wants to fritter away a life or career in random activity as Aurelius rightly observes, but with all of the obstacles to consistent Agile planning the fact is that in truth it’s not that simple.