Agile Roadmaps in Software Development

Artikel auf deutsch

In general, every software solution requires a roadmap, as the basis for targeted further development and so it can be adapted to users’ needs in the coming years. No matter which niche the software serves, it always represents a form of reliable standard for its users. As a result, features are rarely removed, since this is perceived as a loss and impacts user acceptance.

Normally, the product manager is responsible for planning and marketing software. This person is the product-market expert for his or her specific area. The product manager develops a product strategy, known as the roadmap. Software releases are generally implemented in the form of a project, with the help of a project manager. Project and product managers provide each other with significant support by sharing their experiences.

Product lifespan

Thus every software business plan includes a roadmap that makes it possible to market the product over the coming years. One important aspect needs to be taken into account: the product lifespan. Regardless of the ideas and customer requirements associated with a product, every product reaches its limits at some point in the further development process. In our experience, a limit is reached after about seven years, when the cost-benefit ratio no longer allows for economical further development. The reasons for this:

• The basic technology is no longer state of the art, and important new components from subcontractors are missing.
• The architecture has reached its initially established limits; in other words, the user numbers, database sizes and modularity no longer match the current requirements.
• Countless changes by architects and developers have resulted in countless compromises, since things had to be done quickly and cheaply. As a result, the source code is almost impossible to maintain.

The user’s perspective

Users want the best possible support for their current problems. In addition, they want to be courted with new features, and ideally should feel like they have chosen the best product.

Users have a limited understanding of the aspects that influence a product’s lifespan. They notice the end only gradually, as the software feels more and more staid and old-fashioned. Looking around, they may discover better alternatives, which they will eventually try out if the product manager does not work actively to improve the product’s lifespan. New features are gratefully accepted, but users are reluctant to pay for them. The market is relentless.

The Kano model

This model, named for Noriaki Kano, makes it possible to record customer requests and their effects on users. It includes three important classes of features:

• Basic features: These features are so self-evident for users that they do not specifically mention them. If they are missing, users are quickly dissatisfied.
  Example for cars: airbag
• Performance features: While these can also create dissatisfaction if they are missing, they can create satisfaction if they are provided. Competitors distinguish themselves with these features, and users make decisions based on them.
  Example for cars: acceleration or gas consumption
• Enthusiasm features: Things the customer does not expect. These unique selling points generate enthusiasm.
  Example for cars: hybrid technology

It is clear that a product cannot be exclusively based on one class of features. The right combination is important.

Software development practice

The product manager’s strategy takes the product lifecycle into account along with the users’ needs.

Let us assume that approximately two new releases are put on the market every year. In order to sell them in a targeted way, each release needs to tell a story. Ideally, this story is a healthy mixture of all three feature types.

In particular, the ease of maintenance for more complex and distributed applications is all too often forgotten or even eliminated, since its benefits are a hard sell both internally and externally. In the process, people often forget or underestimate the additional costs that will result from seven years without upgrades to the application, and the subsequent dangerous drop in user acceptance. If the software no longer appropriately supports day-to-day work, it results in additional, hard-to-calculate costs for the user due to inefficiency and a lack of productivity. In the worst case, users will decide not to stay with the application, and will change providers.

Constant upgrades to the application lay the foundation for a gentler, more cost-effective transition to a new version of the software. That prevents the “maintenance grab” that can occur when old software is not canceled and when support becomes more and more expensive as a result.

The basis for the roadmap

In our experience, the contents of a roadmap should always be based on the Kano model, and should be distributed as follows:

• Software maintainability– Maintaining productivity and performance while reducing operating and further development costs
  Costs are only paid by the customer through lease or support models
  Loosely based on Kano: Basic features
• Maintaining the existing features - Continuous improvement and reorientation of the product. Existing customers notice the model updates and remain loyal. Ideally, customers are involved as part of user groups so that they can help design the roadmap.
  Costs can only be refinanced through long-term modules that are bound to licenses on a fee basis.
  Loosely based on Kano: Performance features
• New features - Targeted access to new markets through new, innovative solutions. This approach allows you to attract new customers and excite existing customers.
  The development costs also flow back through new fee-based modules
  Loosely based on Kano: Enthusiasm features

The specific distribution chosen depends on many different aspects, and naturally it varies from one release to the next. Still, no one area should be heavily underrepresented, in other words no less than 20%.

How does a roadmap gain flexibility?

In the course of a product’s lifespan, the software constantly faces new challenges from the market. In addition to the strategic content of a roadmap, there is a need to respond flexibly to these challenges at all times.

The foundation for the roadmap’s flexibility comes from an agile approach to software development. That is the only way for the product manager to benefit from the following advantages:

• Feature changes: The contents and their sequence can both be changed.
• Release-whenever-you-want: Short iterative development cycles allow for variable release dates. It is not necessary to withhold a finished feature if it has already been developed.

Thanks to these options, customers can respond quickly to changing market demands with a new roadmap, and can gain an advantage over the competition: “time to market.” The project manager must be able to respond appropriately to these changes during the course of the project.

Summary

The product manager can only create an agile roadmap in collaboration with the project manager. The product manager relies on advice from the project manager, who lays the groundwork for possible solutions by using the entire project team’s technical expertise and an open, transparent analysis of the technical implementation requirements. Consistent reviewing and categorizing of the individual features as required, desired or optional makes it possible to break down each feature into its own roadmap.

The project management must remain focused on these useful change options for agile software development. Long-term project plans need to be flexible but controllable, without losing their focus on the required performance, deadline and cost standards. Using this approach, our project managers have had many good experiences with our customers’ product managers when it comes to setting an agile fixed price.

Tassilo Kubitz

akquinet tech@spree