- Scrum teams suffer when the businesses roadmap expectations are false exactly as they would suffer from false project and/or sprint expectations.
- Scrum teams have the most accurate knowledge of their own progress and availability
- When folded into the agile process, scrum masters maintain an extremely accurate roadmap plan (resource map) exactly as they manage project plans and sprint plans.
- When captured in a common database, the resource maps from any number of scrum masters can be aggregated into an enterprise-wide map suitable for reporting capitalizable labor, capacity analysis, portfolio trade-off decisions, and others. This paper presents just a few examples.
Agile development has improved the ability of development teams to deliver software predictably. Yet, for all of agile’s success at the team level, there’s been no equivalent prescription for how to instill the same predictability, reliability and transparency at the program and roadmap level.
I’ve been a project manager since 1992, delivering enterprise level projects since 1997, a scrum master since 2005, and a PMO director since 2007. Over the last four years I have pursued the challenge of mapping the core elements of agile development into roadmap management. The result has been an Agile PMO process that yields a continuously accurate roadmap and resource map suitable for making enterprise-wide trade-off decisions. This process delivered the annual roadmaps for a start-up company until its successful acquisition and has since been adopted and scaled across the billion dollar acquiring company.
Specifically, in the course of tracking project and program status, the agile PMO process yields a continuously updated resource map reflecting engineering capacity spent, committed and planned for the year, per project, down to the level of each developer per month. Surprisingly, the added effort to keep the resource map accurate is negligible because the data is updated only when it changes, and the work is broadly distributed across the many individuals who are already tracking teams’ progress at the most detailed level: the scrum masters.
The core of the agile PMO process is to empower the scrum masters, those most familiar with teams’ progress and availability, to track, update and broadcast the roadmap obligations for their teams. Each scrum master manages the resource data for his/her team only. When aggregated the data rolls up into an accurate enterprise-wide view of the enterprise roadmap.
Agile teams already engage in three levels of planning. From most to least detailed these are 1) daily scrum planning, 2) sprint planning and 3) project level (release) planning. The agile PMO adds a fourth level of planning: roadmap planning. With all levels of planning co-located inside the team there is instant awareness when a conflict occurs. For example, a project given three months of development time on the top-down roadmap may elaborate into a six month, highly detailed bottoms-up release plan. Knowing this violates their downstream roadmap obligations the team quickly surfaces the three month overdraft in the form of a trade-off decision for the business to reduce scope by an equal amount in either the current project, future roadmap projects, both, and/or secure additional resources. The team then updates their resource map/roadmap based on the business decision.
In this way the roadmap is a living document that team’s rely on to manage their delivery expectations for the year. As a by product, when aggregated, team’s resource plans provide the enterprise with the most accurate portfolio view possible. It’s important to stress that, in the agile PMO, teams rely on resource maps for their own success.
The agile PMO revolves around a very popular, economical, software development tracking tool with a customized workflow and fields able to display data in real-time across the enterprise wiki. In this way, the various meetings to scrutinize roadmap information are certain to review live data and, when making updates in a meeting, share the updates instantly across the enterprise.
The figure below shows how a single project appears on screen to the team managing it. Note the status is ‘RED’ because the team requires intervention from stakeholders. Specifically, the detailed project work breakdown has exceeded the time allocated for the project on the roadmap requiring the roadmap stakeholders to make a scope trade-off between this project and the remaining roadmap.
The data captured in the tracking ticket above shows the who, what, when and how long of the project. Filter and export fields to wiki pages for specialized meetings that focus on certain projects. For example, only projects with status yellow or red, as in the example below.
For enterprise-wide reporting, we access JIRA’s native APIs to trigger a saved query that stores its contents locally for reporting. (The fastest hack is to display the necessary data as a table on a wiki page using the ‘jiraissues’ macro, then use the ‘get external data’ function in MSExcel to fetch that table’s contents for reporting in Excel.)
Any number of reports become possible. This example uses MS Excel. The examples below show different views of the roadmap for only one department of many, composed of several teams with a total annual capacity of 294 person months. The reports that follow show different views of the departments resource map which all sum to 294 person months.