Agile Project Management: No Planning Needed?

Linda manages a large program LargeEngCo calls “Sales Order Support,” SOS. The SOS program contains four projects.

The goal is to provide to the salespeople in the field the list of what products this customer had previously ordered, and what was now available as add-ons for those products. Linda has asked Paul, her CIO, when she can expect to see the product roadmap. She’s trying to coordinate the efforts of four teams, and the teams are confused by the order of the features. One of her project managers explained, “We could have done some of the communication to the database a different way last iteration if we’d known this next feature was so important now. We’ve made more work for ourselves.”
The SOS program is critical to the company success in these uncertain economic times, so the senior management team is deciding when each feature will need to be in the product. The senior managers haven’t done enough strategic planning to know what they really want, so they can’t trust the product owner to make those decisions for them. They believe they need to make the decisions themselves, and they are late doing so–which is why they can only decide iteration by iteration. They then send that information to the product owner who works with the team.
Paul seemed confused. “Hey, this is agile. Why do you want to know about the product roadmap? Don’t you just need to know what’s going on in this iteration? I thought you didn’t need to plan with agile.”
Linda replied, “Well, we do know what we want in this iteration, but it’s really helpful to see the greater context. We can suggest better ways to accomplish what you want in a feature, and sometimes, a better order of implementation.”
“You mean a cheaper order,” Paul replied.
“Maybe,” Linda replied. “But if we know you want this kind of communication to the database here and that database access security there, we might be able to implement in a way that makes more sense and does what you want better. When the product owner gives us just a few features at a time, it’s like ordering a gourmet meal one small piece at a time but ordering the wine before you know what you’re going to eat. You don’t get to pick exactly the correct wine with each course–you end up with what you ordered a while ago, even if it’s no longer quite right.
“And, I have another problem. You know we’re building SOS from these three pieces of legacy software. Well, we have a lot of technical debt in the build system and in our testing. We need to work on the tests and a little on the build system–they are slowing us down. But I don’t know when I can work on them because I don’t know when you want to release and what’s coming next.”
Paul chewed on that for a few minutes. “Well. I still thought agile meant you never had to plan. You’re doing more planning now than you did before.”
“Well, we plan more often, but for much less time,” Linda replied. “I spend way less time planning.”
“But why do you need to see the roadmap? I thought agile meant we didn’t need to plan anything.”
Planning Provides Context and Vision for the Team
If you’re new to agile, you might think that the only planning you need to do is for an iteration, or maybe just a little planning for a release and then move directly into planning just the next iteration. But many projects require different levels of planning–especially larger projects and programs–and you may need to plan at these levels:
Product vision: A long-term guiding vision for the entire product created by the product owner and/or product manager. This vision helps you know the boundaries of the product. In this case, the senior management team has to create the product vision.
Product road map: A time-based view of high-level features that the product owner and product manager may want in the product. Here, Linda’s team could use a quarter-by-quarter road map. The road map can change over time, but it helps the team by providing a context for the product.
Release plan: For a given release, which of those features the product owner wants the team to deliver. This helps the team and the product owner know when the product is done enough to release. If Linda knows when senior management needs a release, she can discuss her technical debt backlog with the product manager and see when it makes sense to address these issues.
Iteration plan: For a specific iteration, what the team commits to deliver. Linda’s project managers are happy to work with the team to remove obstacles to delivery, and if previous work is an obstacle, that’s frustrating for the teams.
Daily commitment: For a specific day, what the team commits to do. Each team member knows what he or she is doing, whether they have to swarm on a feature, or if the project manager needs to remove an obstacle.
The idea is to plan just enough so everyone has sufficient context to complete work they can commit to as a team. Linda was responding to a lack of product vision, product road map and release plan. She knew what each iteration’s features were, and what “done” meant for those features, but had no idea when the SOS product would be done. How could she know when LargeEngCo wanted to release?
Paul didn’t understand why this was an issue–after all, wasn’t the product done when the features were completed in the iterations? The features were done, but could the product be released? Even if the testing is done in the iteration, for SOS there’s technical documentation and user training along with sales training. For other products there might be other deliverables, such as marketing collateral or other documentation.
Because of the backlog of technical debt to pay off, Linda really needed more context. Some of the technical debt backlog items helped the team build faster and test faster. But some of those items were tricky, and would take a spike to determine what to do next. Without knowing the release plan, the product roadmap and the product vision, Linda wasn’t sure she would have room for these items in the iteration plans.
Since neither the product owner nor the senior management team was providing context about the larger issues of the how the product fit into the organization’s plans, Linda was concerned about adding the technical debt items to the backlog for a given iteration. What if management wanted to release after this iteration? Did it make sense to defer some features to pay off technical debt or did it make sense to live with the debt until after a release?
All’s Well That Ends Well
The senior management team finally made commitments themselves: to a product vision, a roadmap and a release plan. The project teams didn’t anticipate work–they still completed just what they committed to each iteration. But they were able to discuss tradeoffs with the product owner. Linda was able to manage the program better because she had a context and understood how to facilitate the entire program. And even Paul realizes that agile requires some planning.
I thank George Dinwiddie and Don Gray for their review and comments.
© 2009 Johanna Rothman. This article originally appeared on

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.