- The Big Picture Explained
- Big Picture: Team Level
- Big Picture: Program Level
- Big-Picture Elements: Portfolio Level
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Big Picture: Program Level
Figure 2-3 summarizes the Program level of the Big Picture.
)
Figure 2-3 The Program level of the Big Picture
Here, we find additional organizational constructs, roles, processes, and requirements artifacts suited for building larger-scale systems, applications, products, and suites of products.
Releases and Potentially Shippable Increments
)
Although the goal of every iteration is to produce a shippable increment of software, teams (especially larger-scale enterprise teams) find that it may simply not be practical or appropriate to ship an increment at each iteration boundary. For example, during the course of a series of iterations, the team may accumulate some technical debt that needs to be addressed before shipment. Technical debt may include things such as defects to be resolved, minor code refactoring, deferred system-wide testing for performance, reliability, or standards compliance, or finalization of user documentation. Hardening iterations (indicated by an iteration with an empty backlog) are included in the Big Picture to provide the time necessary for these additional activities.
Moreover, there are legitimate business reasons why not every increment should be shipped to the customer. These include the following:
- Potential interference with a customer's licensing and service agreements
- Potential for customer overhead and business disruption for installation, user training, and so on
- Potential for disrupting customer's existing operations with minor regressions or defects
For these and other reasons, most programs aggregate a series of iterations into a potentially shippable increment, which can be released, or not, based on the then-current business context.
Vision, Features, and the Program Backlog
Within the enterprise, the product management (or possibly program management or business analyst) function is primarily responsible for maintaining the Vision of the products, systems, or application in their domain of influence.
The Vision answers the big questions for the system, application, or product, including the following.
)
- What problem does this particular solution solve?
- What features and benefits does it provide?
- For whom does it provide it?
- What performance, reliability, and so on, does it deliver?
- What platforms, standards, applications, and so on, will it support?
The Primary Content of the Vision Is a Set of Features
A Vision may be maintained in a document, in a backlog repository, or even in a simple briefing or presentation form. But no matter the form, the prime content of the Vision document is a prioritized set of features intended to deliver benefits to the users.
Nonfunctional Requirements
In addition, the Vision must also contain the various nonfunctional requirements, such as reliability, accuracy, performance, quality, compatibility standards, and so on, that are necessary for the system to meet its objectives.
Undelivered Features Fill the Program Backlog
In a manner similar to the team's backlog, which contains primarily stories, the program (or release) backlog contains the set of desired and prioritized features that have not yet been implemented. The program backlog may or may not also contain estimates for the features. However, any estimates at this scale are coarse-grained and imprecise, which prevents any temptation to over-invest in inventory of too-early feature elaboration and estimation.
Release Planning
In accordance with emerging agile enterprise practices, each release increment timebox has a kickoff release planning session that the enterprise uses to set the company context and to align the teams to common business objectives for the release. The input to the release planning session is the current Vision, along with a set of objectives and a desired, prioritized feature set for the upcoming release.
By breaking the features into stories and applying the agreed-to iteration cadence and knowledge of their velocity, the teams plan the release, typically in a group setting. During this process, the teams work out their interdependencies and design the release by laying stories into the iterations available within the PSI timebox. They also negotiate scope trade-offs with product management, using the physics of their known velocity and estimates for the new stories to determine what can and can't be done. In addition to the plan itself, another primary result of this process is a commitment to a set of release objectives, along with a prioritized feature set.
Thereafter, the teams endeavor to meet their commitment by satisfying the primary objectives of the release, even if it turns out that not every feature makes the deadline.
The Roadmap
)
The results of release planning are used to update the (product or solution) Roadmap, which provides a sense of how the enterprise hopes to deliver increasing value over time.
The Roadmap consists of a series of planned release dates, each of which has a theme, a set of objectives, and a prioritized feature set. The "next" release on the Roadmap is committed to the enterprise, based on the work done in the most recent release planning session. Releases beyond the next one are not committed, and their scope is fuzzy at best.
The Roadmap, then, represents the enterprise's current "plan of intent" for the next and future releases. However, it is subject to change—as development facts, business priorities, and customers need change—and therefore release plans beyond the next release should not generally be used to create any external commitments.
Product Management
)
In agile, there can be a challenge with the apparently overlapping responsibilities of the product manager and the product owner. For example, in Scrum, the product owner is responsible for the following:
- representing the interests of everyone with a stake in the resulting project . . . achieves initial and ongoing funding by creating the initial requirements, return on investment objectives, and release plans.5
In some smaller organizational contexts, that definition works adequately, and one or two product owners are all that are needed to define and prioritize software requirements. However, in the larger software enterprise, the set of responsibilities imbued in the Scrum product owner is more typically a much broader set of responsibilities shared between team and technology-based product owners and market or program-based product managers, who carry out their traditional responsibilities of both defining the product and presenting the solution to the marketplace.
However, we also note that the title of the person who plays this role may vary by industry segment, as shown in Table 2-1.
Table 2-1. Product Manager Role May Have Different Titles
|
Industry Segment |
Common Title for the Role |
|
Information systems/information technology (IS/IT) |
Business owner, business analyst, project or program manager |
|
Embedded systems |
Product, project, or program manager |
|
Independent software vendor |
Product manager |
Responsibilities of the Agile Product Manager in the Enterprise
No matter the title (we'll continue to use product manager generically), when an agile transition is afoot, the person playing that role must fulfill the following primary responsibilities:
- Own the Vision and program (release) backlog
- Manage release content
- Maintain the product Roadmap
- Build an effective product manager/product owner team