Although I have talked about this topic before, I cannot write a series of blog posts about Agile planning without acknowledging one of the fundamental realities of software development that Agile so rightly embraces: sometimes your plans need to change. No matter how much time and effort you invest upfront trying to figure out requirements and document your entire development plan, you cannot anticipate everything.  Emerging technologies, shifts in the market, unexpected obstacles, new client opportunities – any of these things can impact your development plan.

While more rigid software development models fear such shifting plans and resist responding to new information that might alter or derail a project, Agile embraces the fact that sometimes you learn new things between and within sprints.  The key question is how should you respond when new information arises?  The answer depends some on what you learn.

1. If you learn that your approach is not going to work, then by all means stop what you’re doing and find an approach that will work. An active product manager can make sure that the impacts of such a change are quickly communicated to the business team so that expectations can be appropriately managed, but if the team learns that their planned way of developing a new feature or fixing a bug won’t work then don’t waste any time continuing down a dead-end street; turn around and go a different direction.
2. If you learn there is a better way to do things, then talk together as a team about which way to proceed; weigh the trade-offs on taking extra time now to do something ‘better’ versus sticking with the current plan knowing you will likely have to cycle back later to resolve any technical debt. The team might also decide that the original approach is good enough.
3. If you learn that your solution will only solve a piece of a larger problem or that the full solution will take longer than you initially expected, then again talk with the team about whether it makes sense to shift sprint plans and fix the full issue currently or instead to stick with the original plans and complete the larger solution in a future sprint – or maybe decide to pick up something entirely different from the backlog and wait until a later sprint to address the full issue (this gets into questions about releasing ‘working software’ every iteration and how the team balances this).
4. If you learn that an important competitor is about to release new functionality, then discuss with the product manager or product owner what this market intelligence means for the positioning of your own product. Do you now need to add extra features to compete?  Do you need to release your product faster than initially planned (which may mean re-examining what constitutes the minimally viable product given new market conditions)?  Do you need to pivot in a new direction to offer functionality that your competitor can’t match?  Responsiveness to new market information allows the Agile sprint team to make certain that the product you release addresses real market needs in a timely manner.
5. On top of these larger issues that the team may confront, there are also all of the ‘little learnings’ that come from iterative development. This is where Agile shines as a methodology, allowing the daily interactions among the coders, testers, designers, product owners, and end users to promote quick learning across the team.  This kind of rapid feedback is at the heart of Agile development and provides one of its core strengths.

Whether you learn that you are heading in the wrong direction with your product development or simply that your user interface would benefit from some minor tweaks, incorporating new feedback rapidly as you develop your product allows you to remain responsive even as you pursue your overall product plan.  This responsiveness requires the team to discuss what people are learning all throughout the sprint – making scrum and other daily interactions among team members vital.  Staying nimble in this way is a core value of the Agile methodology, encouraging the team to continually enhance its knowledge of the market, new technologies, and the best user-experience practices.  As valuable as it is to plan effectively, strong planning must be kept in balance with the need to respond to new information.  While whipsawing in reaction to every fresh data point is also unproductive, adhering rigidly to predetermined plans in the face of valuable new insight rarely produces a successful product.  Responding appropriately to new insights and effectively incorporating new feedback isn’t easy of course because in truth it’s not that simple.