Today I talked to a friend who wanted to know how I organized software projects. His team has grown rapidly, and their attempts to create and manage detailed plans are spiraling out of control. “It just doesn’t scale,” he sighed.
The larger your project becomes, the harder it is to plan everything in advance. The more chaotic your environment, the more likely it is that your plans will be thrown off by some unexpected event. Yet in this chaos lies opportunity.
Rather than trying to plan for every eventuality, embrace the possibilities that change brings you. This attitude is very different from facing change with clenched jaws and white knuckles. In this state of mind, we welcome surprise. We marvel at the power we have to identify and take advantage of new opportunities. The open horizon stretches before us. We know in which direction we need to travel, and we have the flexibility in our plan to choose the best way to get there. We’ll know it when we find it.
This approach may sound like it’s out of control. It would be, except for eight practices that allow you to control the chaos of endless possibility:
Vision reveals where the project is going and why it’s going there.
Release Planning provides a roadmap for reaching your destination.
The Planning Game combines the expertise of the whole team to create achievable plans.
Risk Management allows the team to make and meet long-term commitments.
Iteration Planning provides structure to the team’s daily activities.
Slack allows the team to reliably deliver results every iteration.
Estimating enables the team to predict how long its work will take.
Product Manager, Customers
We know why our work is important and how we’ll be successful.
Vision. If there’s a more derided word in the corporate vocabulary, I don’t know what it is. This word brings to mind bland corporate-speak: “Our vision is to serve customers while maximizing stakeholder value and upholding the family values of our employees.” Bleh. Content-free baloney.
Don’t worry—that’s not what you’re going to do.
Before a project is a project, someone in the company has an idea. Suppose it’s someone in the Wizzle-Frobitz company.[31] “Hey!” he says, sitting bolt upright in bed. “We could frobitz the wizzles so much better if we had some software that sorted the wizzles first!”
Maybe it’s not quite that dramatic. The point is, projects start out as ideas focused on results. Sell more hardware by bundling better software. Attract bigger customers by scaling more effectively. Open up a new market by offering a new service. The idea is so compelling that it gets funding, and the project begins.
Somewhere in the transition from idea to project, the compelling part—the vision of a better future—often gets lost. Details crowd it out. You have to hire programmers, domain experts, and interaction designers. You must create stories, schedule iterations, and report on progress. Hustle, people, hustle!
That’s a shame, because nothing matters more than delivering the vision. The goal of the entire project is to frobitz wizzles better. If the details are perfect (the wizzles are sorted with elegance and precision) but the vision is forgotten (the wizzle sorter doesn’t work with the frobitzer), then the software will probably fail. Conversely, if you ship something that helps frobitz wizzles better than anything else, does it really matter how you did it?
Sometimes the vision for a project strikes as a single, compelling idea. One person gets a bright idea, evangelizes it, and gets approval to pursue it. This person is a visionary.
More often, the vision isn’t so clear. There are multiple visionaries, each with their own unique idea of what the project should deliver.
Either way, the project needs a single vision. Someone must unify, communicate, and promote the vision to the team and to stakeholders. That someone is the product manager.
Like the children’s game of telephone, every step between the visionaries and the product manager reduces the product manager’s ability to accurately maintain and effectively promote the vision.
If you only have one visionary, the best approach is to have that visionary act as product manager. This reduces the possibility of any telephone-game confusion. As long as the vision is both worthwhile and achievable, the visionary’s day-to-day involvement as product manager greatly improves the project’s chances of delivering an impressive product.
If the visionary isn’t available to participate fully, as is often the case, someone else must be the product manager. Ask the visionary to recommend a trusted lieutenant or protégé: someone who has regular interaction with the visionary and understands how he thinks.
Frequently, a project will have multiple visionaries. This is particularly common in custom software development. If this is the case on your project, you need to help the visionaries combine their ideas into a single, cohesive vision.
Before you go too far down that road, however, ask yourself whether you actually have multiple projects. Is each vision significantly different? Can you execute them serially, one vision at a time, as separate projects built by the same team on a single codebase? If you can, that may be your best solution.
If you can’t tease apart the visions (do try!), you’re in for a tough job. In this case, the role of the product manager must change. Rather than being a visionary himself, the product manager facilitates discussion between multiple visionaries. The best person for the job is one who understands the business well, already knows each of the visionaries, and has political savvy and good facilitation skills.
It might be more accurate to call this sort of product manager a product facilitator or customer coach, but I’ll stick with product manager for consistency.
After you’ve worked with visionaries to create a cohesive vision, document it in a vision statement. It’s best to do this collaboratively, as doing so will reveal areas of disagreement and confusion. Without a vision statement, it’s all too easy to gloss over disagreements and end up with an unsatisfactory product.
Once created, the vision statement will help you maintain and promote the vision. It will act as a vehicle for discussions about the vision and a touchpoint to remind stakeholders why the project is valuable.
Don’t forget that the vision statement should be a living document: the product manager should review it on a regular basis and make improvements. However, as a fundamental statement of the project’s purpose, it may not change much.
The vision statement documents three things: what the project should accomplish, why it is valuable, and the project’s success criteria.
The vision statement can be short. I limit mine to a single page. Remember, the vision statement is a clear and simple way of describing why the project deserves to exist. It’s not a roadmap; that’s the purpose of release planning.
In the first section—what the project should accomplish—describe the problem or opportunity that the project will address, expressed as an end result. Be specific, but not prescriptive. Leave room for the team to work out the details.
Here is a real vision statement describing “Sasquatch,” a product developed by two entrepreneurs who started a new company:
Sasquatch helps teams collaborate over long distance. It enables the high-quality team dynamics that occur when teams gather around a table and use index cards to brainstorm, prioritize, and reflect.
Sasquatch’s focus is collaboration and simplicity. It is not a project management tool, a tracking tool, or a retrospectives tool. Instead, it is a free-form sandbox that can fulfill any of these purposes. Sasquatch assumes that participants are well-meaning and create their own rules. It does not incorporate mechanisms to enforce particular behaviors among participants.
Sasquatch exudes quality. Customers find it a joy to use, although they would be hard-pressed to say why. It is full of small touches that make the experience more enjoyable.
Collaboration, simplicity, and quality take precedence over breadth of features. Sasquatch development focuses on polishing existing features to a high gloss before adding new ones.
In the second section, describe why the project is valuable:
Sasquatch is valuable to our customers because long-distance collaboration is so difficult without it. Even with desktop sharing tools, one person becomes the bottleneck for all discussion. Teams used to the power of gathering around a table chafe at these restrictions. Sasquatch gives everyone an opportunity to participate. It makes long-distance collaboration effective and even enjoyable.
Sasquatch is valuable to us because it gives us an opportunity to create an entrepreneurial product. Sasquatch’s success will allow us to form our own product company and make a good living doing work that we love.
In the final section, describe the project’s success criteria: how you will know that the project has succeeded and when you will decide. Choose concrete, clear, and unambiguous targets:
We will deploy Sasquatch in multiple stages with increasing measures of success at each stage.
In the first stage, we will demonstrate a proof-of-concept at a major Agile event. We will be successful if we attract a positive response from agile experts.
In the second stage, we will make a Sasquatch beta available for free use. We will be successful if at least 10 teams use it on a regular basis for real-world projects within 6 months.
In the third stage, we will convert Sasquatch to a pay service. We will be successful if it grosses at least $1,000 in the first three months.
In the fourth stage, we will rely on Sasquatch for our income. We will be successful if it meets our minimum monthly income requirements within one year of accepting payment.
After creating the vision statement, post it prominently as part of the team’s informative workspace. Use the vision to evangelize the project to stakeholders and to explain the priority (or deprioritization) of specific stories.
Be sure to include the visionaries in product decisions. Invite them to release planning sessions. Make sure they see iteration demos, even if that means a private showing. Involve them in discussions with real customers. Solicit their feedback about progress, ask for their help in improving the plan, and give them opportunities to write stories. They can even be an invaluable resource in company politics, as successful visionaries are often senior and influential.
Including your visionaries may be difficult, but make the effort; distance between the team and its visionaries decreases the team’s understanding of the product it’s building. While the vision statement is necessary and valuable, a visionary’s personal passion and excitement for the product communicates far more clearly. If the team interacts with the visionary frequently, they’ll understand the product’s purpose better and they’ll come up with more ideas for increasing value and decreasing cost.
When I’m faced with an inaccessible visionary, I don’t assume that the problem is insurmountable. Because the participation of the visionaries is so valuable, I take extra steps to include visionaries in any way I can. I don’t take organizational structures for granted, and I push to remove barriers.
If the visionaries cannot meet with the team at all, then the product manager will have to go to them to share the plan, get feedback, and conduct private demos. This is the least effective way of involving the visionaries, and you must decide if the product manager understands the vision well enough to act in their stead. Ask your mentor for help making this decision. If you conclude that the product manager doesn’t understand the vision well, talk with your executive sponsor about the risks of continuing, and consider that your team may be better off doing something else until the visionaries are available.
Discussing the vision has led to contentious arguments. Should we stop talking about our vision?
Even if there are big disagreements about the vision, you should still pursue a unified vision. Otherwise, the final product will be just as fragmented and unsatisfactory as the vision is. You may benefit from engaging the services of a professional facilitator to help mediate the discussions.
Our organization already has a template for vision statements. Can we use it?
Certainly. Be sure you cover what, why, and success criteria. Find a way to fit those topics into the template. Keep your vision statement to a single page if you can.
Our visionary finds it very difficult to communicate a cohesive vision. What can we do when it changes?
Rapidly shifting goals tend to be common with entrepreneurial visionaries. It isn’t due to lack of vision or consistency; instead, your visionary sees a variety of opportunities and changes direction to match.
If the vision is constantly changing, this may be a sign that what you think of as the vision is just a temporary strategy in a larger, overarching vision. Take your concerns to the visionary and stakeholders and try to identify that larger vision.
If you succeed in discovering the larger vision, adaptive release planning (see Adapt Your Plans” later in this chapter) can help you keep up with your visionary. Adaptive planning’s emphasis on learning and on taking advantage of opportunities will fit in perfectly with your visionary’s entrepreneurial spirit.
Your visionary may continue to shift direction more quickly than you can implement her ideas. Wild and unpredictable shifts make it difficult to develop software effectively. The planning game helps; stick with the normal mechanism of scheduling and implementing stories. Your product manager should act as a buffer in this case, protecting the team from rapid shifts and explaining to your visionary what the team can reasonably accomplish.
Can individual iterations and releases have smaller visions?
Of course! This works particularly well with release planning—it can be a great way to help customers choose the priority of stories as they plan their next release.
I’m less fond of visions for iteration planning, just because iterations are so short and simple that the extra effort usually isn’t worth it.
When your project has a clear and compelling vision, prioritizing stories is easy. You can easily see which stories to keep and which to leave out. Programmers contribute to planning discussions by suggesting ways to maximize value while minimizing development cost. Your release plan incorporates small releases that deliver value.
When the visionary promotes the vision well, everyone understands why the project is important to the company. Team members experience higher morale, stakeholders trust the team more, and the organization supports the project.
Always pursue a unified vision for your projects, even at the risk of discovering there isn’t one. If the project isn’t worth doing, it’s better to cancel it now than after spending a lot of money.
Some project communities are so small and tightly knit that everyone knows the vision. However, even these teams can benefit from creating a one-page vision statement. The only alternative to a clear vision is a confusing one—or no vision at all.