Meghan Kutz, Adaptavist Senior Business Consultant—AIS, and Aha! Roadmaps expert—discusses implementing Aha! Roadmaps software as part of an agile transformation and how it connects with an organisation's agile tech stack.
Listen to the interview or read it below
Implementation and customisation—sometimes, you need an expert
How has Adaptavist helped an existing customer implement Aha! Roadmaps?
We have a customer that needed Adaptavist's help with integrating Aha! Roadmaps with Jira. The problem statement was essentially: “We need good roadmaps that communicate our progress on a strategy to leadership, but we need the status and progress of the items that feed that strategy to come from Jira. And the integration is just not working for all of our teams.” They initially tried to self-implement across their dozen or so product teams and quickly found they needed help. Now on the face of it, Aha!’s integration technology is very simple, easy to implement, and highly customisable. The issue wasn't the technology itself but rather deep knowledge of two critical elements. Firstly, each of those dozen or so teams was doing something just a little bit different from their peers. The work is fairly de-centralised; process standards are in place, but the nitty-gritty can vary across teams. There wasn’t anyone from a centralised position—say, in the PMO—who knew how each of these teams was operating differently. The second critical element is a deep understanding of just how Aha!'s customisability can effectively cater to a situation like theirs. And that’s where we came in. Adaptavist conducted in-depth interviews with stakeholders and asynchronous research. We became the centralised party that identified and documented how each team works and then used our deep Aha! knowledge to design a successful approach. We needed to create that central trunk of standardised process and configuration for all teams and then configure it for the teams that needed to branch off into slight variations.
As an example:
A product manager proposes a new strategic project to leadership with the following:
- These are the following five features I'm going to build this year.
- This is the ‘why’ and the benefit they will bring to the company.
- These are the resources I need and what they will cost.
- And this is how long it's going to take.
Leadership agrees to fund the project, and now the product manager has a budget of £2m to develop these five features. This strategic project now has a budget and a timeline, so the PM moves into execution.
Those features become epics in Jira. The issue arises because the strategic project—the umbrella that the PM needs to report to leadership—isn't represented anywhere. In Jira, teams are just working at the epic level down, and Jira doesn't do so well on its own going above that epic level. Consequently, the strategic project may be in Google Docs or somewhere else unconnected to the actual work. Re-forging that connection from a reporting standpoint is where software like Aha! Roadmaps and Jira Align come in.
By bringing the strategic project into Aha! Roadmaps as a reportable record aren’t enough. Answers to the salient questions, “How far along are we?", “Are we on track?” and “Are we on a budget?” are just guesses without having the execution-level work represented in Aha! as well. Again, those epics (and their user stories) worked in Jira and should stay in Jira. So what needs to happen is that the engineering teams work in Jira. As they complete their work, their status and tracking are fed via API integration to mirror records in Aha!, which link to those strategic project records, and auto-calculate the progress of those projects. And that’s the backbone of your roadmap: knowing how far along we are on that funded initiative, how close we are to completion, and where it sits on the timeline against our other funded initiatives. Epics worked in Jira inform all the metrics but link to the strategy they support in Aha!. Product managers have quarterly and six-month check-ins with leadership, and these roadmaps help support decision making backed by accurate—and real-time—data.
How easy is it to implement Aha! Roadmaps in terms of customisation to make it fit with existing tools?
I would say that it is deceptively simple–but in a good way! Because it’s highly customisable, you really can do a lot to make it work for your organisation. The trick is to find the balance between standardisation and customisation, and this is where it can get a bit tricky. Integration with a third-party system is configured at the workspace level in Aha!. That means the individual product or portfolio teams can configure record and field mappings how they want to, which might be very different from how another team chooses to do it. But if you have too much of that de-centralised configuration, you run the risk of data mismatches in the aggregate. Your roadmaps and reports look a bit wonky once you start rolling them up, and it becomes harder to make those data-based decisions on strategy at higher levels. So there needs to be collective agreement on the key metrics and desired outcomes, and then standardise configuration as much as possible. And that begins not in the software but by bringing teams together and really getting crisp on definitions and processes. It starts on paper. I think this is where many organisations typically run into trouble with their implementation.
Link innovation and agility by giving everyone a voice
How does the ideas portal within Aha! Roadmaps help make business more agile in terms of implementation?
It is the ideas portal that really sets Aha! Roadmaps apart from its competitors. Basically, it connects the customer voice directly to product managers without friction. Teams can set up a portal to intake ideas from other business teams, outside customers, or stakeholders. Those ideas are collected and visible in the portal. Users can add a new idea or support an existing idea by adding a vote to it. Teams can then choose ideas from that pool, score them according to a customised scorecard, prioritise them, and promote them to a fully-fledged feature right in the UI. These ideas could form the basis of the five new features that the product owner needs to include in the next release to progress the product. Once an idea is promoted to a feature, you can simply add it to your backlog and include it in the next round of PI planning. Or maybe it’s a killer feature, and you want to include it in this upcoming release. You can use all the features like capacity planning, etc., that we talked about in the last blog to plan for that.
For a customer that has already started to implement Aha! Roadmaps, typically how long will it take to reconfigure their Aha! Roadmaps tool to make it work best for them?
We never really need to start from zero, but it's essential to take a reasonable amount of time to understand their processes thoroughly. Let’s say they’re running SAFe. That’s great, but it’s highly likely that just taking Aha!’s best practices for implementing Aha! to support SAFe exactly as written isn’t going to work or isn’t going to get them to the finish line. Any organisation running an agile methodology has likely adapted certain practices or methods to work for them. It’s not just SAFe that needs to be considered, but the customer’s version of SAFe–or even more typically, some combination of agile, traditional, and hybrid methods once you look across the entire portfolio.
Moreover, understanding their goals is essential. They might want to build better roadmaps, and they want the Jira integration to work for them. But what does that mean in practice? Who will be consuming those roadmaps, and what kind of business decisions will the roadmaps support? With the Jira integration, it may not be just what the Jira workflow looks like, but is the workflow working as well as it could? These are just some of the areas we dive into during discovery, and it’s not just about documenting the process but about connecting hidden dots. That’s the key to a good implementation, and it’s essential to a well-integrated tech stack.
The discovery process also takes time; there is a discovery period and implementation period, as with all consultancy projects. However, if the customer is already using Aha! Roadmaps, any changes are made live and should be done in isolation, then tested. An exact timeline is tricky to provide, especially as each project is different and varies massively depending on the complexity of the organisation. After a very hands-on 4-6 weeks discovery period, an entire configuration guide is produced. Then it is simply a case of implementing the recommendations.
Why choose Adaptavist to support the implantation of Aha! Roadmaps?
We are extremely familiar with the underlying principles that went into Aha! Roadmaps’ design. Understanding the information architecture is essential for setting up a workspace hierarchy and strong reporting. Our years of experience as a Platinum Atlassian Partner means we possess comprehensive knowledge of agile methodology; we can come in and configure Aha! Roadmaps easily because we have a deep understanding of that ecosystem. Our diverse skill set goes beyond technical expertise; we understand the kinds of solutions that business leaders need to make and the problems they are looking to solve: Adaptavist and a safe and experienced pair of hands.
If you would like to speak to an expert about how Aha! Roadmaps can form part of your agile transformation tech stack, please contact one of our experts.