One major misconception about Agile product development is that there’s no long-term planning, and that everyone just does what they think should be done in the moment.
This couldn’t be further from the truth. Successful Agile shops are ones that put a strong focus on strategy and know exactly where they want to go. Being Agile means that you outline your high-level business goals first, that you think about the six-month and twelve-month plan, that you focus on problems over solutions, and, ultimately, that you abandon timelines and allow yourself to adjust priorities as you go.
Unfortunately, this is where most executives struggle; “How can you not have a timeline? When will things get done? How will we plan?” It’s understandable that executives want to know how time and money is being spent, and timelines and Gantt charts have their place in certain kinds of businesses: see my previous post on Waterfall vs. Agile approaches. But in the world of web development, timelines equal compromise, and compromise equals failure. When you commit to the dates on a timeline, you might as well let everyone know right off the bat that you will either miss the date, or that you will compromise the product to hit the date.
But what’s the right way to do long-term planning in an Agile environment so that executives (and everyone else) feel comfortable with the plan? The answer is a road map based not on deadlines and wants, but on priorities and needs.
In Agile, you should always focus on the problems you’re working on solving. This helps you get rid of the things that you may want but don’t really need. This is about focus. A project’s “needs” should be broken down into two categories:
- Rocks: The big things, including overarching directional products — things that have to be broken down into smaller tasks and things that will take weeks to accomplish.
- Sand: The small things: product and design tweaks, tech debt, etc.
Once you know what you should be focused on, then you have to prioritize, while knowing that at any point priorities can change. There are no deadlines here.
Then it’s about conversation — there should never be surprises. Get commitments early and make sure people know what you are thinking for the short term and the long term. For instance, “We know we want to focus on advanced search first, so that’s what we are going to do. After that, we want to focus on our sign-up process, followed by a new home page, but that could change.”
Your goal as a product person is to make sure that “priority 1” really is the right thing to be focused on. Once we know what priority 1 is, we focus on that until we are satisfied that objectives have been met. Everything past priority 1 is subject to change as time goes on, and that’s OK — that’s the point! You can’t put a date on something that you aren’t working on, something that the team hasn’t sunk their teeth into yet. And you shouldn’t have to. Staying true to Agile development means maintaining focus, doing lots of quick releases, taking into account customer feedback, and performing lots of iterations. Because you’re incorporating feedback, what you end up creating is likely to be vastly different from what you thought you were going to be doing on day one. Again, that’s OK; that’s the point!
When you are done with number 1, you can move on to priority 2, or adjust your priorities based on research you were doing while working on priority 1.
And let’s not forget about the “sand.” That gets prioritized just like rocks do — on a need vs. want basis. Every now and then you find that a developer has some free time: enter the sand. Pick off the little things when you can, as long as they are the most important little things and they don’t distract from the larger effort required for rock “number 1.”
Things change, priorities change, what we do changes, and as long as we have a plan and so long as we know that the plan is subject to change, we are in a good spot to talk about priorities. Healthy conversation, getting people on board, and understanding the process outlined above is the right plan of attack.
Remember, as a product person, you need to know where you want to be in six to twelve months to understand how to get there (see my previous post on the 80/20 rule). The better you know where you want to be, the easier it is for you to communicate your vision with management. And the easier it is for you to communicate your vision and execute it, then the more management will be at ease without deadlines, timelines, Gantt charts, etc.
Being Agile is about more than just developers, product people, and designers being OK with adjusting priorities. It’s also about management being OK with these changes, and your job as a product person is to lead the way.
