Much has been written about how to increase and maintain the velocity of development, especially in an Agile context. But relatively less is said about business velocity - the ability of the product owner or business team to produce sufficiently refined requirements (e.g. user stories) to keep up with the pace of development. Lean thinking tells us to optimize the entire value creation process - if we focus exclusively on optimizing development, we risk starving the development team of stories to work on.
To make this worse, I believe there are a number of inherent factors that lead to the decline in business velocity over time. Unless managed and mitigated, these factors will result in the product owner being unable to maintain a constant volume of stories flowing to development. Just like developers need to adopt practices such as test automation and refactoring to maintain their pace of change, so to do product owners and the supporting organization need to take deliberate action to counteract these forces.
As an application matures, and especially when it is developed using an agile highest-value-first approach, the incremental value of each new story tends to decline over time. Unless there is a change to the business or new discoveries that drive higher value application changes, the justification of new features and enhancements thus becomes correspondingly more difficult over time. Increased analysis or debate happens concerning the expected benefits or costs in order to ensure a positive return on investment. This may also lead to more time being spent justifying continued funding for development.
This seems to be an inherent aspect to all software development - most strongly seen, I believe, in enterprise software but also true for commercial software. One mitigation to deal with this is increasing the level of innovation and creative thinking in order to discover new, high value features. Otherwise, the only other 'solution' I can think of is a variant of the idea of the pivot from The Lean Startup by Eric Ries. If the value is drying up for one particular business domain, then pick a different business problem or different customer opportunity to work on. This means typically starting a new, different application.
As features are added to an application the analysis of each new feature must take into account interactions and conflicts with the pre-existing set of features. In addition later additions to features tend to add additional complexities or special cases beyond the simple happy path that was first constructed. In combination this leads to an increased burden of analysis. On some teams, this may be left to the development team and manifest as a reduction in development velocity. But following the principles espoused in Jeff Sutherland's paper on being Ready Ready to be Done Done means this analysis should be done by the product owner (supported by subject matter experts and members of the development team) prior to development starting. So as this analysis gets more complex, the flow of stories ready for development tends to decrease.
The best mitigation is a strong focus on simplicity: say no as much as possible to extra complexity and marginal-value features. Ironically, while this helps deal with business complexity, it will actually exasperate the issue of dropping value. Another mitigation is to expand the business team. You still should have a single product owner with the decision-making authority - the idea is to support them with subject matter experts or business analysts.
These supporting people can come from the development team as a part-time role, which has the nice feature that they can be shifted from development work - reducing the development velocity - to analysis work - increasing the business velocity - in order to keep an even flow to the overall process.
For enterprise software the number of internal or external organizational stakeholders seems to have a tendency to increase over time. There are a number of ways this can happen:
- The application is rolled out to more business units / external customers over time, increasing the volume of feedback / demands / concern over changes expressed to the product owner.
- The application integrates (upstream or downstream) with an increasing number of services which requires more coordination / assessment of change.
- Application data is used for operational or management reporting, consumed by the corporate data warehouse, or fed into analytic tools. Data dependencies now have to be considered when analyzing new features.
- As the application becomes more successful / more widely used, more senior management or more managers take an active interest in the application. The decision-making authority of the product owner may weaken, or they may end up spending more time dealing with this management involvement.
The general mitigation is strong governance whose specific form will depend on the nature of the additional stakeholders. Increased services integration requires strong SOA governance. An increasing customer base requires more sophisticated customer relationship management. The organization must be prepared to support the product owner by providing the necessary people, processes, and tools to implement the required governance.
Once the application goes live there are any number of operational issues that can arise and potentially distract the product owner.
- End user administration, such as registering and granting access to new users.
- Operational business processes such as monitoring user activity, handling customer issues, or monthly reporting to management
- Organizational change management to drive the adoption of the software or implement associated business process changes. This can also include providing training.
- Writing end user documentation such as web site copy, frequently asked questions, or user manuals.
- Application defects or performance issues are discovered which add to the backlog of work for the product owner to evaluate. Critical issues often need to be dealt with immediately and are disruptive to people and plans.
Going to production and having actual users using the application and deriving value from it is a good problem to have, so get to production as soon as you reasonably can. The sooner you start experiencing operational issues, the longer you have to learn how to effectively manage them. A soft launch or limited production rollout is also very beneficial in keeping the initial volume of operational issues low, providing time to put tooling, people, or process into place to deal with them.
A common mitigation to deal with operational issues is to create a separate business operations team. They focus on supporting the production application and dealing with business-related operational issues while the product owner focuses on the product roadmap and the prioritized backlog of enhancements. The danger of this approach is that the product owner can become out of touch with the experiences of real users, so they need to receive regular communication and feedback from the business operations team.
If you find this article helpful, please make a donation.