11
Managing the Agile Roadmap
Why do we continue to produce multiyear roadmaps at the feature level when they're never accurate? Roadmaps are a necessary evil because customers want to see how their products will evolve. Nobody wants to get stuck with an unsupported product. Sales wants the roadmap to see what they will be selling so they can establish sales quotas. Finance wants the roadmap so they can forecast revenue, income, R&D expenses, and software capitalization for the business plan.
Traditionally, roadmaps have been published periodically at the release and feature‐levels. More recently, roadmap applications that share roadmaps online have become available. In either case, roadmap changes frequently occur because of estimate changes, added work, or staffing changes. This is especially true when companies impose Waterfall planning on Agile.
Roadmap changes are not welcomed by product stakeholders who have built their plans around the roadmap. Most product and project managers avoid updating the roadmap until all hope of delivering roadmap commitments is lost. Project management still hopes the pressure of the fixed schedule and content will somehow motivate engineering to pull it off. This results in roadmap surprises for product stakeholders after it is too late to do anything.
Agile Investment roadmaps are at the Investment level instead of feature level. Timeboxing of Investments increases schedule and financial predictability. The Investment team can vary feature content and functionality as long as the Investment stays on schedule and meets the cost and income targets. Features and functionality necessary to achieve the Investment targets are within the control of the team so they don't have to commit to specific feature dates in most cases.
Of course, product stakeholders often have an interest in feature content, and in some cases, they will insist on specific features. An Agile roadmap maintains feature status in terms of “In,” “Target,” and “Out.” As discussed in Chapter 3, specific features can be committed before development starts if there is enough feature and functionality flexibility to account for software estimation variance.
An Agile roadmap relational database can provide a baseline where financial and schedule impacts can be assessed before changes are accepted. It can be used to set and maintain product stakeholder expectations.
Section 11.2.2 shows how a technology roadmap can be integrated with the Agile roadmap. Engineers are included on the Investment team to contribute solutions enabled by new technologies. Companies are always looking for new technologies that will allow them to leap ahead of their competition. This involves careful monitoring and planning of technology acquisition that must be synchronized with the Investment roadmap. The short Investment cycles of Agile development provide agility to quickly adopt new technologies with effective planning.
11.1 The Agile Roadmap Management Database
The Agile roadmap can be implemented with any relational database and presented with numerous data analytics tools available today. Tableau is used in this example. Your IT organization can probably create a simple relational database for you based on the many options available, including open‐source solutions. Tableau has connectors for most popular databases, including Excel. This example will use a flat file defined in Excel, which can be created with Comma Separated Value (CSV) exports from most relational databases if a Tableau connector is unavailable.
We'll use AccuWiz as an example. AccuWiz has planned the following Investments with timeboxed start and finish dates (Table 11.1).
The relational database used by AccuWiz Investment teams relates features to Investments. Table 11.2 shows a flat‐file representation.
Note that the database includes internal and external features. Microservices, for example, provide the infrastructure for software developers to access application data without requiring knowledge of the data structure. This supports layering, an architectural best practice to shield developers from complexity. The Visibility field can be used by the AccuWiz data analytics tool to filter internal data for views exposed to sales or customers, with the complete list limited to Investment teams and product management.
Table 11.1 AccuWiz Investment backlog.
| Investment | Start | Finish |
|---|---|---|
| Mobile Application | 10/1 | 12/31 |
| European Version | 11/1 | 3/1 |
| Audit Report Generation | 2/15 | 6/30 |
| Data Analytics Connectors | 5/1 | 7/31 |
Table 11.2 AccuWiz Investment features.
| Investment | Feature | Visibility | Status |
|---|---|---|---|
| Mobile Application | Secure Login | Internal | In |
| Mobile Application | Dashboard | External | In |
| Mobile Application | Purchase Order Approval | External | In |
| Mobile Application | Invoice Approval | External | Out |
| Mobile Application | Expense Reporting | External | Out |
| European Version | VAT Calculation | External | In |
| European Version | UK Regulatory | External | In |
| European Version | Germany Regulatory | External | Target |
| European Version | Italy Regulatory | External | Target |
| Audit Report Generation | Microservices | Internal | In |
| Audit Report Generation | Sarbanes–Oxley Report | External | In |
| Audit Report Generation | Accounting Exception Report | External | In |
| Audit Report Generation | Purchase Order Reconciliation | External | Target |
| Audit Report Generation | Expense Report Violation Report | External | Target |
| Audit Report Generation | Invoice Reconciliation | External | Target |
| Data Analytics Connectors | Microservices | Internal | In |
| Data Analytics Connectors | Basic Export Capability | Internal | In |
| Data Analytics Connectors | Invoice Data | External | In |
| Data Analytics Connectors | Purchase Order Data | External | Target |
| Data Analytics Connectors | Expense Report Data | External | Target |
Figure 11.1 is an example of an Agile roadmap generated by Tableau from the flat file.
The status of each feature is represented by the legend in the right‐hand pane. The filters change the view.
Note that the feature bars on the Gannt chart have the same lengths as the parent Investment. This representation is intended to show feature status, not the schedules of individual features. As described in Chapter 9, the Investment teams and product management have control over the Investment feature set and feature schedules.
It may be possible to represent the roadmap in a roadmap management application that you currently use with the addition of the filter fields shown. Either way, you need to provide access to a living roadmap that represents the latest development plan to maintain expectations of your roadmap stakeholders.
Figure 11.1 AccuWiz Tableau roadmap.
11.2 The Agile Technology Roadmap
Market leaders can rapidly capitalize on technologies at the point they become practical. It doesn't matter who develops the technology. The winner is the one that turns it into money and market leadership.
Apple is a good example. They bet on the availability of faster processors with reduced power consumption as well as inexpensive touch screens. They caught the technology curve at just the right time, leaving competitors in the dust. There are software examples. Lotus timed the spreadsheet with the availability of low‐cost personal computers that were just being adopted in business at the time. Companies should follow new software technologies to determine when they might be integrated into Investments.
There are examples of big technological leaps in software development, such as the relational database, object‐oriented development, and service‐based architectures. However, there are also opportunities to leverage smaller increments of technological advancement.
Microsoft SharePoint was a key technology that enabled my clinical trial software management company to leap ahead of established competitors like Oracle Life Sciences. SharePoint was just being widely adopted in life sciences companies at the time, but its use was hampered by stringent regulatory data requirements, such as audit trails. Experimentation with SharePoint led us to a solution that synchronized SharePoint with the regulated data in our clinical trial management system to allow life sciences companies to build their own portals and integrate managed data with their Microsoft Office applications. It was all about timing. We differentiated ourselves through technology.
In many cases, hardware technologies enable new capabilities that can be delivered in software. The faster and more energy efficient processors used in iPhones is an example. Modern examples include voice recognition, higher mobile Internet speeds, and radio‐frequency identification chips (RFID). A software company needs to continuously monitor both hardware and software technologies that can possibly be leveraged.
The Investment model enables organizations to quickly pivot to leverage new technologies at the right time. The challenge is the ability to implement a new technology at the right time.
11.2.1 Stages of Technology Acquisition
Based on my experience, several steps are necessary to get to the point where technology can be applied:
- Awareness
- Proof of concept
- Pilot
- Rollout
11.2.1.1 Awareness
The Agile organization should follow the progress of technologies that might be leveraged by an Investment. I saw a successful model for monitoring promising technologies in my telecommunications career. It was called the “Key Technology Program (KTP).” Many organizations depend on fundamental research groups for new technologies. However, researchers are often far removed from stakeholder value and the current internal technologies. The idea of the KTP was to involve senior developers in tracking internal and external technologies that might be applied.
Management of the program was quite simple. It consisted of a monthly meeting with the R&D VP and his directors where volunteers could present status on technologies of interest and speculate about when and how they could be applied. It was a positive experience for the presenters. Many were passionate about their technologies and loved to evangelize them.
The volunteers were called Key Technology Owners. They retained their development roles, so they maintained current product knowledge. There was no problem getting volunteers. It was a respected role that enabled engineers to move to the highest positions on our technical ladder.
11.2.1.2 Proof of Concept
Many technologies don't deliver on their promises. I learned not to trust their claims. As discussed earlier, my clinical trial management software company broke into the life sciences market with a novel solution for synchronization of regulated data with SharePoint. We had become a Microsoft managed partner, so we always looked for ways to leverage their technology. Since our customers could now access and build SharePoint portals, I had the bright idea to bundle Microsoft's InfoPath graphical form designer with our application.
Our system architect said we should do a proof of concept. Although this meant a delay, I had learned to listen to senior engineers. I found that their warnings almost always came true. The proof of concept showed that InfoPath conflicted with our workflow implementation. It would have caused major problems. We dropped the idea.
The message is not to trust the advertised capabilities of technologies. Make sure time is allowed for a proof of concept.
11.2.1.3 Pilot
This is an application of the new technology in a low‐risk project. Development practices often need to be created to utilize a new technology after it passes proof of concept. For example, introduction of RFID into your product requires that a developer understand its range of capabilities and limitations. An Application Programming Interface (API) needs to be developed and tested.
11.2.1.4 Rollout
This is the rollout of the new technology for application by any developer. It involves documentation and training necessary to enable developers to utilize the technology.
11.2.2 Investment Technology Roadmaps
The rollout period must end before the start of development of the Investment in which the technology will first be deployed. In the AccuWiz scenario, a Key Technology Owner is following the latest advances in smartphones with foldable screens. Based on price drops and adoption rates, they recommended that the technology be used to provide a better interactive experience with their application, getting a jump on competition. The technology must be ready for inclusion in the Mobile Application Investment.
Figure 11.2 is a Tableau view of technology that needs to be available by the end of October.
In the spirit of Agile, this is a dynamic roadmap that can change at any time based on new information.
Figure 11.2 Technology roadmap view.
11.3 Summary
- The Agile roadmap is expected to change and should be implemented in a relational database.
- Frequent changes in Agile development increase the importance of rapid communication with roadmap stakeholders.
- A simple relational database and common data analytics tools can be used to implement the Agile roadmap.
- Net Cost of Delay can communicate financial impact of proposed roadmap changes before they are accepted.
- The short development cycles of the Investment model enable rapid infusion of new technologies.
- It's not about inventing the technology; it's about getting the timing right to adopt new technologies.
- A Key Technology Program is an effective way to transition technologies into production at the right time.
- Specific adoption stages need to be planned to align with the start of Investment development.
- Technology stages can be included in the Agile roadmap.