Upon hearing about the short cycles of agile processes, some people are afraid that long-term planning never happens. They fear that teams could paint themselves into corners. That’s a risk: some teams do get fixated on each upcoming delivery, never sparing a thought for the future. But that’s not necessary, and below I tell you how to avoid it.
One of the secrets of agile processes is that they don’t tell you precisely what to do. Agile methods create contexts where people learn to do the right thing naturally.
For example, leaving loose ends is bad. You could make rules about exactly what constitutes a loose end and how to get rid of them. Many try.
Instead, you could start each week with a new set of work that you expect to fill the week. Then you release at the end of every week. That leaves no time for last week’s loose ends, which will turn up again as this week’s urgent bug fixes. In that context, teams have a strong incentive to learn how to tidy up all the loose ends that matter.
The secret, applied
So how do we create a context where your team will naturally spend the right amount of time doing long-term planning?
Step 1: Create a strong need for regular short-term plans. The best way to take care of this is through regular, frequent releases. If you are releasing something every week, then you are never more than 7 days from needing to have something to ship.
Step 2: Make a home for the long-term plan. There are always more good ideas than time to do them in. Instead of just throwing away the excess, you should keep them in a backlog. When you get enough of them that you need to organize them, make sure you do: that’s how the plan’s structure will emerge. For maximum effect, your backlog should be publicly visible, easy to update, and visually interesting. I usually use index cards and a rack or board. Do what works best for you, but if your plan becomes stale or gets ignored, try something more obvious and easier for everybody change.
Step 3: Establish feedback loops. It isn’t enough to release. You have to pay attention to what happens when you release. The right way depends on your environment. But observing what happens is the only way you can separate your good notions from your bad ones. The more often you do that, the better you’ll get.
Step 4: Frequently go over the plan. People with varied backgrounds should often walk through the plan together. Regular meetings are one way. But every question that starts with “why” is an opportunity to take a fresh look. As is the arrival of new data from customer feedback, user testing, market analysis, or economic forecasts.
Step 5: Be accountable to each other. A good team is in it to win, and win together. Mutual accountability helps a lot with that. Developers, for example, are responsible for building things that work for the long term, and the whole team should hold them to account for that. Equally, those managing the product are accountable to the team for the decisions they make.
Step 6: Be accountable externally. Almost every team has executives or investors that they are responsible to. On a regular basis (e.g., quarterly) tell them what you will do, what you have done, and how that compares to what you said you’d do. If they don’t ask good questions, get better advisors, even informal ones. As Doug Carlston, founder of Broderbund, has said, “The number one reason for bad software is too much money.” A lack of accountability is a big part of that.
Step 7: Keep time free for idle thought. There are many reasons to avoid being habitually overcommitted. But I think the biggest one is that tired or panicky people underinvest in the long term. We’ve all seen people come back from vacation filled with thoughtful observations and new ideas. Having good ideas once a year isn’t enough!
Some readers may feel like I’ve cheated them a bit. I haven’t told you how to break a project down into features. Or how to calculate value for units of work. There’s nothing about how to prioritize, estimate, organize, evaluate, or execute features. There’s nothing on market penetration or customer satisfaction or pleasing early adopters. Nothing on revenue models or organizational politics.
But that’s ok. I trust that given thoughtful practice, your team will figure all that out. The important thing is to start your practice right away.