Build a project roadmap without killing your agile process

Originally published September 24, 2020

Project roadmaps are hard to trust. It's especially tricky for Agile teams that are laser-focused on short iterations and nimble innovation — Agile methods are with the long-term planning of leadership teams, who need to think in terms of quarters or years.

In general, organizations try to estimate project timelines either by:

• Self-reported progress from the teams themselves, or

• Tracking project stats or analyzing project data to make numbers-based projections

Both strategies have significant flaws. They tend to paper over problems, hiding delays and complications for way too long, until — surprise! A whole avalanche of issues bursts forth and scrambles everyone's plans.

It's useful to consider why these methods so often fall short. Understanding the flaws in either basic type of planning can help you construct a strategy that plays off their strengths and mitigates their weaknesses.

Method #1: Self-reporting project updates

Trying to judge how long a task will take isn't solely a practical question — it's an emotional one. When a project manager asks for progress reports, teams are motivated to put an optimistic spin on their updates.

They may have fallen behind slightly, but they expect they can make up the lost time next week. Or, they may have discovered a complication in their tasks but don't want to make a big fuss about it just yet, in case they come across as overly negative, or even worse, incapable of handling their own problems. This is extremely common, and most people do it because of the intrinsically moral nature of these questions.

"Are you on track?" is another way of saying "Have you succeeded or failed?"

"When can you get this done?" is another way of asking, "How skilled and productive are you?"

In other words: "Are you good at what you do, or not?"

Nobody wants to admit that they've fallen behind; everybody wants to impress coworkers and superiors with their skill and competence. So they tend to overpromise, sometimes without even realizing it. This is true of individuals and team leaders, and in product development projects it compounds over time. Delays accumulate; teams put off uncomfortable truths until it's too late.

Conversations on progress reports between managers and teams or team leads do have value, but they are severely flawed until you can get some distance from the moral component of these questions. Turning to a more objective, numbers-based process seems like the best solution — until, of course, you try to actually do it.

Method #2: Analytical project management

Companies try to overcome these pitfalls by turning the product development process into a series of metrics. They quantify each stage of the process, seeking to apply the principles of business analytics to product development. As another potential benefit, they also use this data to spot efficiency lags and make improvements to the process. This is often where the basic "stoplight" visuals come in, with a red, yellow, or green color to provide a broad view of status.

In other words, they adopt the mindset of a manufacturer looking to optimize efficiency on an assembly line. With product development, though, it's just not possible.

Development is a creative art. Production is not quantifiable in the same way as manufacturing. This is not the same as working with rivets; writing code, for example, requires emotional commitment and is often affected by whatever mental state your engineer happens to be in that day or week.

So asking engineers to enter their hours as a planning tool for tickets — for example — is doomed to create stats that are way off the mark. They can't predict their timeframe, and crunching these made-up numbers is a waste of time for everyone. You're going to get lost in the math and wind up even further away than if you'd just stuck with the subjective conversations.

In creative work, you can't track everything. You don't need to, and you shouldn't want to. Systems that are too focused on objective, assembly-line measurements present nice-looking dashboards that kill projects.

Merging Jira data with the human element

Creative organizations need to merge the subjective and the objective. If you lack either, you're going to pay for it.

How to start? Here's our suggestion: First, use hard numbers and data to form a baseline prediction for a project. The best source of stats is within Jira, in your own past projects. If you want to figure out how much effort and resources a project will entail — in other words, the scope of a project — you can analyze that historical data to get a sense for how your teams have worked in the past, and quantify the scope necessary to deliver on a project going forward.

Then, take a step back and have some honest (and yes, subjective) conversations about whether those numbers-based predictions are reasonable. What other factors are in play with this new project? Maybe you have more engineers now — how will that affect your timeline? Maybe you're going through a company reorganization — will that slow things down?

The main point here is that your teams have an objective framework to guide conversations, and in turn, that framework can be influenced by subjective inputs.

One important point: Have this foundational conversation before the project even truly begins, so you can have those conversations without getting bogged down in the moral baggage that accumulates as teams work through their tasks. This conversation provides space for teams to be more honest about how a project might work, so you set yourselves up for a better process.

But this is not a single conversation. It takes constant attention to maintain. Put the systems in place to prompt conversations about progress every day. Agile teams learn as they go; projects that are not demanding many changes while in progress are likely not connected to reality. You should reassess the impact of these changes as soon as possible.

Clicking refresh on a dashboard is not good project governance. Neither is pestering teams for updates on their projects. But your objective numbers, tempered with subjective conversations, will keep you grounded. This helps you stay connected to the endpoint of your project. It's not an easy system to put in place, but no roadmap or forecast will be truly useful until you can strike this balance.

For more information on managing projects, read "Defuse Battles Between Leadership and Agile Teams" and stay tuned for my next article, where I'll explain the concept of "value cadence" — a better way to measure team capacity by using historical Jira data.