If you are leading a major digital transformation initiative, how do you get your organization from where you are to where you want to go? You make a plan – also called a Roadmap – to structure big change with incremental steps across several programs.
But how do you build and structure your Roadmap? And how do you balance many initiatives across teams?
As a part of our series on how to build and use Roadmaps, we sat down for a conversation with Chris Johnson, Founder and CEO of iTrellis, a technology management and software engineering firm based in Seattle, Washington. iTrellis is a Microsoft Silver Partner with a MS partner agreement (MPA) in MS Partner Network (MPN), Microsoft Partner Network Certified Supplier in Azure Enterprise Services, and CSPs in AppDev and Application Services with certifications in Azure DevOps (ADO).
Chris has 30 years of experience assisting 100s of companies, including support for large programs at Accenture and KPMG Consulting (BearingPoint), and small/mid-market clients through his own companies. Leveraging the iTrellis ADO extension Portfolio++ , Chris helps leadership teams build strategic Roadmaps and facilitate organizational change.
Let’s dig in to Chris’ approach with some questions from Bilyana Tokmakchieva of the Seabeck Systems team.
(Chris’s remarks have been lightly edited for brevity and readability. All Roadmap and Backlog management terms used in this article are based on Azure Boards, but these concepts can be applied to Atlassian Jira and other Backlog / Task management tools. Words that are capitalized distinguishes key terminology used in Scaled Agile principles.)
BT: What are the steps you take when building a Roadmap for a client? Is there a framework that you use?
CJ: Leaders want to understand the scope and context of the Roadmap. It starts with gaining an understanding of the organization, which is easy enough to get. Most of the time I just ask for a copy of the executive organization chart and the teams for which they are responsible.
As a first step, these things help define the scope of the portfolio, i.e. the business domains and business owners whose teams will be managed by these Backlogs. Then you need to consider assignments at all levels of the Backlog down to the individuals.
Once I know the scope, context, organizational structure, teams, and work, I have what I need to put together a Roadmap. Now the key to this is that we have the people who will do the work participate in the definition of the work, which creates natural buy-in.
As a guide, we adhere to Scaled Agile Principles, and our favorite is a lightweight implementation of the Essentials and Portfolio Track of the Scaled Agile Framework (SAFe) by Dean Leffingwell. It has a well-established vocabulary – people understand what a Sprint is, they understand Scrum, they understand basic Agile principles.
That’s what we stick with, because as a consulting organization the faster we can get on the same page with respect to our communication with our clients, the better.
BT: That’s interesting that so many of your clients already understand Agile terminology. What industries do your clients work in? IT?
CJ: We work across a variety of industries ranging from agricultural crop insurance to mechanical engineering. Some of our clients include Mercedes-Benz Research and Development North America (Daimler), and we work with a company as a white label in collaboration with research institutions like NASA.
For the basics, like Scrum, people get it. I don’t think there’s a question of “How do we help people cross the chasm?” The real question is, “How do we get these Scrum teams (at mid-size to enterprise companies) coordinated so they can work independently and autonomously, and plan the priority of the work within the context of the larger program?”
That’s where the real value of a Roadmap comes in, in my mind. Most teams can manage themselves. Managing themselves in the context of the other teams, and what the other teams are doing where dependencies are concerned, is a little bit more challenging. So, the tool we created for the marketplace is Portfolio++, which provides Portfolio Management Planning as a complement to Azure Boards used for individual team work management streams.
BT: So, you created Portfolio ++ specifically to fill this gap that you saw when working with clients?
CJ: Specifically working with teams that want to do Gantt chart-style Roadmaps across multiple teams that are iterating using Scrum and Kanban, i.e., Scrum-ban.
BT: Bringing us back to the Roadmap, what are the biggest challenges when building a Roadmap with a new client?
CJ: Initially, getting agreement at the top-level of the Portfolio structure using Epics and Features to describe business value streams. We see four patterns for definition, depending on the type of work:
This approach to Portfolio Management naturally lends itself to a Roadmap. Defining your business’s Portfolio structure of work using these patterns enables the construction of Backlog views by team that align to the business, and in turn, allow for the creation of meaningful Roadmaps.
Once you have defined your Portfolio structure of work, getting the executive team to agree to the structures in their area isn’t hard, as the organization Backlogs reflect their organization management structure.
Once the executive team agrees, then we talk with them about ownership of an area, delegation, and what their responsibilities are. Once you can convince them there’s value in being the owner of an area, and when we understand who’s responsible for what area, and what teams are involved in each of those areas, the building the Roadmap is pretty straight forward and simple.
BT: Do you include deadlines in a Roadmap? How do you make sure the team will hit each deadline?
CJ: All projects whether large (multiple teams) or small (one team) have deadlines. A large-scale example is launching a spacecraft. There are hundreds if not thousands of teams and people that need to come together to build this singular marvel that’s going to launch into space and ideally bring people back. Teams depend on each other to get work done on a cadence, and so we want to define those deadlines, dependencies, and milestones to set expectations across the Roadmap’s program.
Deadlines and milestones help people to understand the context of the work they’re doing, where it fits in, and when it needs to be done. I’m a big believer in putting in dependencies and milestones or other programming increments into a plan, so that everybody can see: that’s the goal.
Where you run into problems with deadlines, is when work from one team won’t satisfy a dependency for another team in time. Some people have used this as an excuse to say, “There is no point to planning, as all plans change.” Sure, plans change. However, this is why we practice Agile principles. We rigorously adhere to Scrum ceremonies, like Sprints, and watch our Backlog Story Point “drift” very closely, so when we see a problem coming up in the plan, we have time to adjust for it. In this way, we can prioritize whether date or scope is more important, and if both are equally important, we can make a compelling case for additional resources.
On Sprints, I like the rapid feedback cycle of daily Standups to manage Backlog drift. I prefer Sprint Planning meetings every week or two, no more than four (ideally two). Sprint Planning provides a natural time to review the work being undertaken in the Sprint, showing the context of the Sprint’s work in the larger program Roadmap, and reminding the team why they are doing the work they are doing.
The metrics that come out of these rituals (e.g., work items that are done/note done), provide leaders early indicators when the team feels a deadline is at risk, and gives the leadership team time to adjust – such as bring more resources, adjust the launch date, or work with the team to creatively engineer a new approach. Using deadlines to help people be aware of what is expected of them is a good start. Meeting with people every day creates a manageable sense of urgency without turning into anxiety.
A Roadmap that can express team metrics, rolled up to a 1-page plan, and updated automatically, on-demand (real-time), provides the insight and the context that executives through development staff need to make informed decisions. The executive may look at aggregate metrics to release, while the developer may look at individual Tasks and dependencies to do work.
This isn’t just theory. Tools like Portfolio++, which roll up input from Azure Boards, do this automatically to ensure that all Roadmap users are taking decisions from a single source of truth. Just take a look at these reviews in the Visual Studio Marketplace.
BT: How do you ensure buy-in? How do you involve engineers and other team members?
CJ: At iTrellis, we find there are two types of people in this world: definers, and doers. Our job is to get the people responsible for the requirements in the room with the people who are going to do the work as early as possible, so they can jointly sketch out the work breakdown structure for their teams.
We then sort that work by area, team, and priority, and do a deep dive on the top priority items with all of the team members who will be directly involved. The T-model works well: our analysts go wide to get a complete picture of the scope required (Epics, major Features), while our engineers go deep to define the technology solution architecture (producing a Feature, and its User Stories and Tasks). Then we chunk up the program’s scope into manageable program increments / releases.
After a couple iterations (1-3 Sprints) building solutions on the proposed architecture, a team velocity evolves, which should confirm whether the scope as defined can reasonably be delivered within the expected deadline.
What we have found is that the more people participate, the more bought-in they are. So we want them participating early, and often.
BT: What are some of the key problems that could derail a Roadmap?
CJ: The biggest problem is typically a lack of leadership support. We need the executive team to endorse and encourage a minimal level of compliance. Therefore, we need the bare minimum of process guidelines for Backlog development, and those guidelines need to be really simple. We recommend seven simple suggestions for multi-team Backlog development in Azure Boards. You can find them here. (Scroll down and click Learn More to view the seven simple suggestions in the PDF.)
We often have project managers and business analysts who are used to doing things “their own way,” and reject the change management and training that is required for them to fit into what we are calling an Agile PMO. We have found a balance between executive Portfolio Planning and team-based Scrum, and it only works if the majority of team members involved work in a similar fashion. We want people to show up every day, talk to other people, and be accountable; when we have a similar process, vocabulary, and cadence, it helps.
If we can get over this hurdle through lightweight training, followed by practice and repetition, this approach allows for autonomy, creativity, innovation, and predictable forecasts with successful, timely deliveries.
BT: What Roadmap tools can help teams and leaders balance their approach and still get the results they want?
CJ: I’d like to give a shout out to Microsoft for Azure Boards, on which Portfolio++ is built. The people at Microsoft have been building software to help with this challenge of business and development team alignment for a very long time, starting with TFS, then Visual Studio, and then Azure DevOps Services and Azure Services in the cloud. With each iteration, the user experience has gotten better. We think Azure Boards and Portfolio++ work great for individual teams as well as enterprise organizations with deep team hierarchies.
Portfolio++ gives leaders an almost immediate benefit of transparency and visibility across their teams, which in this example enables them to identify areas of imbalance quickly and smooth out the work.
BT: What would be your recommendation for someone who is building their company’s digital transformation Roadmap, but they don’t currently have access to Boards, or haven’t used Azure Boards before? Where should they look?
CJ: I would recommend that they call a Microsoft DevOps certified consultant, like the people at iTrellis, who can come in and help them lay the foundation for that digital transformation using Azure cloud services.
BT: How do you help prepare a leader to speak about the Roadmap, and present it as their own?
CJ: Prepping the executive for that meeting is pretty simple using our techniques. First, we don’t want anyone to be surprised when it is presented, and second, we want the executive to be confident that their people will “buy the plan.”
To ensure this, we take a structured approach to Roadmap construction. First, we map out the desired organization structure, then we identify leadership and teams by area, and then we have quick-hit discussions about what each leader is working on at the Epic and Feature level, i.e., “what are they building?”.
Then we go through another round of discussions about the context of each group’s work within each of the aforementioned identified areas. After a few iterations, we usually get a Roadmap “fleshed out” that’s directionally correct, comprehensive, and that everybody has seen prior to the executive briefing. This helps to ensure that the executive team is confirming everyone’s belief in their work and direction, rather than surprising them.
BT: How do you help prepare a leader to refine and improve the Roadmap over time, and react to changes?
CJ: First, we convince the leader that Roadmaps evolve. Things happen, and Roadmaps need to be changed to reflect changing conditions. Helping the leader understand that the Roadmap needs to be reviewed frequently, helps them see the impact of changing conditions over time. They can see the change to completion dates (pulled in, or pushed out), and they understand why. As far as the Roadmap review frequency is concerned, it depends on the volatility of the organization and the industry in which the organization operates.
Let’s look at an example. For leaders who establish a cadence (e.g. daily standups and two-week Sprints), whenever the team identifies a problem that won’t go away, then inside of a two-week window leaders have visibility and can take action. The leadership has to be part of the solution and deal with that problem. They can’t hold people to a plan that doesn’t change when circumstances do.
This approach can also lead to a better relationship between the leadership team and the development team, because they work together to solve problems. Working together, and creatively coming up with a contingency plans and workarounds to mitigate risks as they arise, builds rapport and trust. It isn’t one side holding the other hostage, and treating the Roadmap as an immutable contract.
Leaders need to lead by example. Leaders need to demonstrate collaboration to get collaboration. Roadmaps provide context for these discussions, which leads to better understanding, and in turn better delivery.
BT: Can you build different scenarios, so teams have contingencies to fall back on?
CJ: Yes, we do. However, at some point leadership needs to decide which scenario (or the maximum number of scenarios) should be pursued. These scenarios that rise to the top are the ones we break down into Epics, Features, User Stories, and Tasks.
In the case of split team decisions, we have a couple approaches depending on where we are in the conversation. Early in a program, we might create two different value stream maps (VSMs) to show the flow of the work. That usually prompts enough discussion to make a decision. Later on, after development has occurred, we might create two different sequence diagrams to show exactly how the APIs should support the requirements. This is usually a very precise exercise that results in one sequence diagram with a lot less work than the other, and engineers usually choose the road less difficult.
If “talking it out” doesn’t yield an obvious winner, then we vote iteratively using the Fist of Five technique to help get to consensus. While the Fist of Five is fun, this public voting technique helps to reveal where people really stand in a conversation.
BT: How do you coach team leads who are not familiar with roadmapping and strategic planning, to help them be more successful?
CJ: Training and repetition. We train people what they need to know, as they need to know it.
We start with the basics. For example, Scrum. If they learn Scrum, then they understand an iteration path. Then, they can pull User Stories into the path. Presto, they have a Roadmap. We do this across each team, and teach the same process. This creates common vocabulary across the program. Depending on people’s roles, we offer point-specific training. For example, analysts need to know how to work with a Backlog in order to define requirements, while developers need to know how to work with a Backlog so they can read requirements.
Once we have common process and cadence, we can usually start the strategic planning process across teams to produce Roadmaps.
BT: How do you make sure people don’t get stuck in a rut? How do you approach Retrospectives?
CJ: We approach Retrospectives like many leading recovery programs, i.e., the first stage is acceptance. People or teams need to acknowledge problems and discuss them with honesty and integrity in order to participate in healing, or getting to “better.” Not all teams are prepared to do this.
We find that in organizations with routine performance management, that these discussions tend to go well. In this case, we might start with Retrospectives right away. In organizations that do not do routine performance management, these discussions often go wrong quickly if introduced to soon in the change process.
In either case, Retrospectives are very important, because they allow people an opportunity to talk to their peers about how the work gets done, and how it impacts them. More often than not, Retrospectives help to improve attitudes, simply because people feel heard. Speaking for myself, I have found that attitude is as important as aptitude on development teams, and Retrospectives offer a break from routine to talk about being “better.”
And when you feel good, you don’t feel like you’re in a rut anymore.
To learn more about Portfolio++ and dynamic portfolio management and planning, contact Chris Johnson at iTrellis.
