This article is part of a blog series!
|1||Yes Virginia, even agile teams roadmap!|
|2||Moving from roadmaps to requirements|
|3||Deliver well: requirements to deployment|
Give context to your teams
Roadmapping has always been a dirty word in agile circles. In some ways it feels inherently waterfall to plan a 6, 12, or 18 month roadmap for the team. I’m here to tell you that roadmapping is a good thing. It gives the organization context and shared direction for where the group is going.
As team members, we’re always looking for context. What is context? You’ve probably heard one of the following questions on your team.
- How do I fit into where the organization is heading?
- How does my contribution mix with others on my team?
- How do the decisions I’m making affect other people in the organization?
- How can I anticipate changes that come from other teams?
- What types of features might we be building down the road that I need to understand to make good architecture today?
An old employee of mine gave me great advice as a manager: “it’s your job to anticipate and remove surprises so that the team doesn’t have to hit speed bumps.” Roadmapping gives the organization enough foresight into the future to anticipate and deal with speed bumps.
There’s a strong misconception that agile is all about cowboy coding. It’s actually the opposite. Agile requires strong discipline that requires authentic conversation and honest planning. Agile methodology pushes the hard decisions that happen in waterfall cycles much earlier in the development process. The team and stakeholders can manage issues and change proactively rather than reactively. At Atlassian we have a vibrant agile culture and roadmapping is a key part of our organizational alignment.
At Atlassian, we use Confluence to build lightweight roadmaps that give the team and the rest of the organization guidance. Roadmaps can be built with the Gliffy plugin or with PowerPoint and embedded into a Confluence page. Roadmapping allows us to block out chunks of time for features we’d like to deliver. We use Confluence as it allows us to have one conversation with the organization rather than stacks of PowerPoint slides littered across everyone’s email account.
What do our roadmaps look like? We focus on four key areas in our roadmaps: theme, feature, duration, and releases. Teams in Space is our fictitious example company that specializes in booking travel for teams in space. Let’s take a look at an example roadmap.
On the Jira team, product managers will often use themes to help guide the evolution of the product. Those themes often span multiple releases. For example, improving search was a key part of the Jira 5.X release cycle. In Jira 6.X, we’re focused on making the best experience for software developers.
A project manager will work with the development and design leads to scope out a high-level feature in a given theme. The team will then socialize the proposal and agree on an appropriate bucket of time to deliver that feature. Each feature team goes through the same process to understand the relative length of each feature.
The Jira leadership team then takes each of those features and places them on the roadmap. This requires agreement across the team on priorities for delivery. Since the roadmap is hosted on Confluence, everyone in the organization can easily see the product’s future direction. Roadmaps don’t hide in a project manager’s hard drive nor are they buried in everyone’s email. For roadmaps to be effective, they need to be clearly visible across the organization in a known place.
As theme teams engage on their particular features, learning always results. Some items will go more quickly than estimated while other tasks will run long. How the organization responds to learning is one of the key metrics of the cultural adoption of agile. The roadmap is not a death march. It’s an instrument of communication and decision-making for the team and stakeholders.
Having the roadmap in Confluence allows everyone on the team to see and understand change. Having that conversation in one place involving everyone makes it much easier for the organization to adopt and prosper through change. In short, do enough planning to understand where you’re going but not so much that you become emotionally attached and resist the opportunity to change and better understand your market.
In our next article, we’ll take a look at how the team plans out a feature using Confluence and transitions the work automatically into Jira.
I am curious: am I preaching to the choir or spewing hearsay? What’s your opinion on roadmapping in the context of agile teams?