Agile Product Responsibility in the Enterprise, Part 1: Owning the Vision
- Communicating the Agile Vision
- Vision Content: A Set of Features
- Undelivered Features Fill the Release Backlog
- Critical Non-Functional Requirements
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
My article "A Contemporary Framework for Agile Product Management in the Enterprise" suggests the following set of Agile-specific responsibilities for the product manager, which differ from the activities of a pre-Agile world:
- Own the vision and release backlog
- Manage release content
- Maintain the product roadmap
- Build an effective product manager/product owner team
In this article, we'll examine the specifics of the first responsibility in the list: Owning the vision and release backlog.
Communicating the Agile Vision
Although the instantiation and delivery models for Agile development (vision/roadmap/feature set versus product requirements document) are different from those of other methodologies, taking responsibility for the vision is not a new act for the role of product manager. Rather, it's actually a logical outcome if the product manager has these qualities:
- Exhibiting a continuous, in-depth understanding of the current solution
- Staying abreast of the latest industry trends
- Understanding the changing needs of the market and the customer base
- Articulating a clear direction for addressing gaps and opportunities
In Agile systems, the traditional product requirements documents (PRD), system specification, software requirements specifications (SRS), and the like are typically eliminated. In their place, Agile enterprises take a leaner approach, better suited to the last-responsible-moment, delayed decision-making, and artifact-light development practices of the Agile enterprise.
Since the PRD and SRS documents no longer exist to specify system behavior, communicating the vision to the Agile development teams becomes even more critical. This communication is the product manager's responsibility because, no matter how empowered and energized the Agile teams may become, it's the product manager's responsibility to set strategic direction. The vision answers the big questions for the system, application, or product under development, including addressing these questions:
- Where are we headed with this thing?
- What problems does it solve?
- What features and benefits does it provide?
- Who is the recipient of these benefits and features?
- What performance, reliability, and so on does it deliver?
- What platforms, standards, applications, etc. will it support?
Agile Visions Take Many Forms
I've seen Agile teams take a variety of approaches to communicating the vision. For example:
- Draft press release. Highlights the new features and benefits of the solution.
- "Very preliminary" data sheet. Accomplishes the same thing in a concise form.
- Product vision box. Uses the product packaging box metaphor to capture similar elements.
- RUP-like vision document. This standardized template defines users, features, system qualities, and the like. (One very Agile team once told me, somewhat defensively, about why they still loved their RUP-derived vision template: "We write to make sure that management understands what we are about to build.")
Each of these forms has proven its worth in a variety of Agile projects, but it doesn't even have to be very well structured. In one release-planning session I facilitated, the four product managers had no opportunity to collaborate prior to the release-planning session. Even if time had allowed for such collaboration, it's doubtful that they could have come up with a harmonized, force-ranked feature set. (What self-respecting product manager would want his or her number-one feature to be placed fourth on the release backlog?) Instead, we gave each product manager approximately 45 minutes on stage. Each presented a briefing deck, including a list with descriptions of the top 10 new features he or she proposed for the solution component. Based on this context, the teams then went into the detailed planning session.
Clearly, this wasn't the ideal forced-rank prioritization we like to see in Agile planning, and it was left up to the teams to decide what to do about the fact that four product managers had separate priorities. But, like everything else in life, software can be a little messy. Most importantly, this model seemed to work really well, because the product managers were part of the process. By the end of the session, they all had visibility into what the teams could and could not achieve in the time box.