Vous êtes sur la page 1sur 9

Agile Product Management:

A White Paper

Technology companies are moving toward Agile development. This is driven by the need to
improve productivity, boost product quality, and make delivery against business goals more
predictable. Product management is a crucial part of the move to Agile, calling for new skills and
new kinds of deliverables. Many product management organizations, however, do not have
experience with Agile deliverables, processes or communications styles.

This white paper briefly reviews Agile development, then identifies six levels of product
management and how Agile changes those levels. Roles, processes and deliverables are
increasingly divergent from waterfall models as we move from long-term strategy toward sprint-
level and daily activities. We will use an outside-to-inside approach to examine Agile Product
Management responsibilities for:
1. Portfolio Management
2. Roadmaps and Release Plans
3. Requirements Management and Communication
4. Customer Input and Collaboration
5. Agile Product Teams
6. Communicating Information Up, Across and Out

In reality, Agile Product Managers address these different levels simultaneously, not sequentially.
In the course of a single day, a product manager might meet with her customers, adjust
roadmaps or release dates, review backlogs work with developers, and present new financial
forecasts to executive teams. Product managers are continuously working at many levels of
detail, rapidly switching from the general to the specific and back. For clarity within this white
paper, though, we address these six levels sequentially.

We also introduce a multi-purpose "onion" diagram. This represents


the overlapping time horizons (or scopes) for various Agile activities.
Daily development and stand-ups happen many times within a
sprint, which occurs several times per release, which forms a
product roadmap, as part of a broader product portfolio and
company strategy. These activities happen simultaneously,
but at different rates and with different audiences. It is
critical for an Agile Product Manager to negotiate each level on
behalf of his product: generating support and visibility from different
parts of the organization based on each appropriate schedule.

Ultimately, Agile Product Management and development approaches


lead to measurable improvements in products, financials and
customer satisfaction. These results matter to senior executives, thus moving decisions about
Agile beyond Engineering/Development organizations.

Product Management is central to successful Agile processes, providing essential


inputs: market and customer insight, priorities and organizational communication.
Without appropriate product management, Agile development teams simply build the
wrong products faster.

Agile Product Management White Paper Page 1 May 2008


Enthiosys, Inc. | www.Enthiosys.com 650.528.4000
The Basics of Agile
The fundamentals of Agile development have been intensively covered by other authors. The
fundamentals are recapped here for clarity and consistency of terminology:
• Agile planning is a process that builds in mechanisms for frequent early feedback and rapid
re-planning. This provides a way to more effectively manage inevitable changes in the
external environment, as well as discoveries the team will make about the technology and
product that they are building.
• Agile reduces risk through continuous adjustment, early user validation and more frequent
delivery of smaller work elements.
• Development is organized around sprints, each of which is designed to deliver incremental
features that are potentially shippable from a quality perspective.
• Use cases, features and requirements are broken down into user stories, each ideally small
enough to be completed in one sprint.
• Customers review working versions throughout the development cycle, not just during beta.
• Work items are put on the backlog. Teams deliver backlog items in priority order, creating
opportunities to deliver incremental value to customers.
• Estimation of backlog items is done by the entire team during Release and Sprint Planning
meetings. This builds experience within the team estimating tasks and backlog items, taking
advantage of collective wisdom and shared experience. Over time, the team improves its
estimation skills.
• Teams are self-organizing, with brief daily stand-ups to identify roadblocks. Each team
takes responsibility for resolving problems internally, re-allocating resources to meet goals,
and quickly escalating issues. Over time, teams become more effective and more efficient.
• Agile teams do a lot of planning at the start of a project, then frequent re-planning to reflect
reality. Said another way, "Agile teams plan, and they plan to re-plan."

The balance of this paper describes six key areas where a product manager can have a
significant impact on a company’s overall success in adopting and Agile development process. It
starts with strategic portfolio issues, then moves through the different levels of iterative planning
and execution activities that are part of a typical development cycle.

1. Portfolio Management
Assuming an overall company strategy (or a divisional strategy for larger
organizations), product managers are important contributors to
portfolio-level product planning. Generally, this is divided into new
product development and ongoing management of existing products:
product managers create proposals for new products that depend heavily
on future scenarios about markets, technologies and financial forecasts.
They also evolve existing product plans based on accurate project status, a
deep understanding of customers/markets, and feedback about recent
financial results.

Executives want to see credible market research and business plans before they green-light new
initiatives. Therefore, product managers need to be truly expert about market segments,
business opportunities, technical risks and high-level requirements when presenting major new
efforts.

To understand these issues, product managers use a variety of data-gathering tools including
secondary research, surveys and customer visits. They may focus customer input with
prototypes, wireframes and story boards. Once product managers understand customer needs

Agile Product Management White Paper Page 2 May 2008


Enthiosys, Inc. | www.Enthiosys.com 650.528.4000
and preferences, they combine that information with detailed cost and revenue models to build a
credible business case. If approved, the product portfolio is adapted to add a new product or
shift resources so that existing products can address new opportunities.

For the most part, portfolio planning and new product proposals happen separately from day-to-
day product development processes. Portfolio decisions are slower, more deliberate, and viewed
as more costly than product-level decisions. Product managers are an important part of this
process, however, since they generally have more product information (and expertise) than other
actors at the portfolio level – and Agile Product Managers tend to have fresher and more detailed
customer intelligence at hand.

2. Roadmaps and Release Planning


Agile Product Managers need good product roadmaps. To create
good roadmaps, they must collaborate effectively with all
stakeholders and gather a broad set of inputs. The, they use
roadmaps as an essential tool for communicating how tactical
development and release plans support the company’s product
strategy.

Roadmaps are central part of the Agile Product Managers toolkit - used to
identify release windows, build consensus, prioritize features and
communicate with the broader organization. Agile Product Managers use a
highly collaborative roadmapping process to drive planning sessions with architects,
engineers, marketers and other stakeholders.

Because Agile Product Managers have such a demanding (and repetitive) communication
challenge, we’ve found that a solid roadmap is needed to tell the whole product story. It should
include information such as:
• The market segments to be addressed over the coming 6-24 months and (at a very high
level) how the product will meet that segment’s needs.
• A “Features and Benefits” portion
Markets
indicating the top 3-4 features that will
truly move the market.
• An “Events and Rhythms” portion to
identify time-based outside influences
Features & Events &
(such as a trade shows, regulatory Benefits Release Window Rhythms
changes and competitive events) that
drive feature delivery dates.
• An "architecture" portion where technical
members identify items underlying Architecture

architectural items needed to deliver the


releases. (Technical architecture is
typically dropped from purely marketing-driven maps, which makes early identification of
feasibility and resource constraints very difficult.) Product managers want their entire teams
raising technical issues early in the planning process, since that help identify alternatives
when the cost of change is lowest.

Agile roadmaps are built iteratively and reviewed often by the core team (not just the product
manager). This builds accountability, since representatives of all core functions are in the room
when the map is built or updated. Most importantly, Agile teams expect and plan for
their roadmaps to change.

Agile Product Management White Paper Page 3 May 2008


Enthiosys, Inc. | www.Enthiosys.com 650.528.4000
Roadmaps provide the basis for decisions about backlog, release planning and outbound
marketing efforts. As shorthand for product strategy, roadmaps often stay posted on executive
office walls, or are assigned their own conference rooms for immediate access.

Once an ideal release window is identified and the high level plan is validated by all stakeholders,
teams are ready to do release planning. Release planning is an intense 2-3 day collaborative
working session where the entire team provides estimates about the effort required to deliver the
entire backlog of work for a given release. This can be very challenging – the team must paint
high level goals, features and value proposition for release, then refine and divide requirements
into use cases, features and ultimately user stories to a level of detail that the development team
can effectively estimate. Still, Agile teams quickly become acculturated with release planning.

Updates to roadmaps can occur during the release cycle. For example changes to the company
strategy, information from voice-of-the-customer programs, and ongoing development status can
be factored back into the roadmap. This gives product managers a versatile tool for the
continuous planning that occurs within an Agile development environment, incorporating and
representing information coming top-down, bottom-up or outside-in.

3. Requirements Management and Communication


Agile teams consume requirements and user stories "just in time" as relevant backlog
items are reached. Agile Product Managers, therefore, must learn to provide just the
right data at just the right time to just the right people – at the right technical depth
and in the appropriate format. This means that Agile Product Managers must be able to
"play in the technical weeds" one minute, then handle strategic issues the next.

Defining market needs and expressing them appropriately for development


teams is one of the most important responsibilities of a product manager.
One of the more celebrated documents used for this purpose is the Market
Requirements Document, or “MRD”. Unfortunately, traditional MRDs are a
poor fit for the needs of an Agile product team.

Writing a good MRD is challenging because it suffers from several well-


known problems:
• Difficult to write at the appropriate level of detail. If the product
manager writes too little, readers complain that they don’t have the information they need.
If the product manager writes too much, the document becomes unwieldy and less likely to
be read. Sadly, the product manager usually ends up doing both.
• Must serve many audiences. Each consumer of a traditional MRD must determine which
portions to ignore. Finance, sales, executives, and development each need parts of the MRD
but rarely all of it.
• Poorly maintained. The contents of an MRD change at different speeds. For example,
high-level market requirements should be relatively stable while detailed feature
specifications need more frequent editing.
• Created, not consumed. Typically, the creation of an MRD is a phase requirement for new
projects, but thorough review and resolution of issues is not. Product managers must “check
the MRD box” knowing that large portions of their work will not be read or used.

The Agile Product Manager’s approach to describing a market, its requirements, and solutions is
based on three principles:

Agile Product Management White Paper Page 4 May 2008


Enthiosys, Inc. | www.Enthiosys.com 650.528.4000
• Organizing information according to the time horizon it influences, optimized for the needs of
those consuming it;
• Formally documenting the smallest amount of information required to enable action, and use
collaboration when more detail information is needed;
• Managing frequently changing information differently from more stable information.

Consider overlaying these concepts with our "onion" diagram. The higher levels are focused on
big picture issues, while the lower levels have more intensive and collaborative conversations
with core/extended product teams.

Given these challenges, rather than using one document to accomplish the wide variety of
communication and collaboration activities, Agile Product Managers use five key artifacts:
o Business Plan: This is not an MRD, but instead briefly summarizes the product vision, goals
and how it supports the strategy. The plan also contains market research results, financial
summary information, go-to-market and operational issues as needed.
o Financial Model: Describes how the product will perform financially given a set of
assumptions about sales performance, pricing and costs over time.
o Roadmap: Visually describes how the product will evolve over time to address the target
markets as described in the business plan.
o Release Plans: This communicates generally what capabilities and features are being
delivered and when.
o Backlog: This tracks the product’s entire known set of big ideas, use cases, features, user
stories, architectural work, etc. that could possibly be considered for the product over its
entire lifecycle.

While the backlog lists all of the work that needs to be done, these items often need additional
elaboration during release and sprint planning. The development team is ready to ask detailed
questions about what is has been requested. Agile Product Managers must be prepared to
provide significant detail about user stories that have been scheduled for upcoming sprints. In
addition, product managers must collaborate with the development team to define acceptance
criteria for each user story.

Agile Product Managers therefore adopt a wide range of artifacts and communication tools
matched to their audiences, uses and longevity. This often leads to the creating of Lo-Fi
prototypes, sketches, flow-charts, wikis, or collections of PostIt® notes on whiteboards.

4. Customer Input and Collaboration


Agile Product Managers must involve customers throughout the development cycle to
ensure that their products are evolving as expected and will meet customer
expectations. The Agile Product Manager gathers input through a variety of
mechanisms, involves the whole team, and uses many different
communications vehicles to share rich customer information.

We noted above that market research and voice of the customer input are
a critical part of green lighting new products and making major changes in
product strategy. In addition, market research and customer
conversations are happening continuously in many organizations as
Marketing, Sales, Customer Service, Field Services and others interact with
customers. Agile Product Managers must harvest information from these
sources.

Agile Product Management White Paper Page 5 May 2008


Enthiosys, Inc. | www.Enthiosys.com 650.528.4000
Beyond this broad interaction, however, the Agile Product Manager must collaborate directly
with customers to ensure that their products stay “on course” throughout the development
cycle. She needs a plan for creating and managing those customer collaboration opportunities
over the course of the release.

Ideal sources of initial collaboration are naturally occurring customer gatherings such as user
groups, training sessions and technical briefings. Agile Product Manager often “steal some time”
in front of customers to communicate the vision and goals for an upcoming release.
Alternatively, they may meet individually with lead customers. Either way, certain artifacts are
especially helpful to communicate futures: a description of the release goals; wire frames or story
boards of new features; and a prioritized backlog of use cases, features, enhancements and bug
fixes. By sharing this information with customers Agile Product Managers can get clear feedback
and verify that they are on the right track.

In addition, Agile Product Manager should consider engaging more intensively with a small
number of customers for continuous feedback. This provides a forum for end-of-sprint feature
showcases, explicit backlog prioritization, and presentation of incremental progress. Regular
customer participation also provides the development teams opportunities for direct end user
access, so that the entire team can deepen its appreciation for requirements and use cases.
Development team often take these customer-facing opportunities to pitch unique technical ideas
– that they would normally reject as inappropriate – since they can safely propose ideas in
person to selected customers.

Because Agile Product Managers take advantage of the flexibility that Agile gives them to more
frequently re-prioritize, they strongly favor customer input and collaboration techniques that
provide fast, qualitative, directionally correct information to support rapid decision-making.
For example, Agile Product Managers may solicit opinions on narrow mid-sprint issues during
visits to regularly scheduled customer gatherings. By using rapid qualitative techniques, Agile
Product Managers can deliver "just in time" input with better and more current information.

Furthermore because Agile Product Managers understand that they have many release vehicles
to deliver incremental value to customers over time, they have more options for how and when
to meet specific customer needs. Traditionally, product managers turned away even tiny feature
requests from huge customers, because overburdened release trains were almost certain to ship
late. When faced with demands for new features, Agile Product Managers can now "price out"
one enhancement in terms of deferring other features, and can negotiate crisply with customers
or sales teams. Agile Product Managers see roadmaps with multiple releases as an opportunity
to have an infinite relationship with their customers, slotting and re-slotting features into
upcoming releases where they deliver the most value.

Agile Product Managers need to balance these frequent customer input and collaboration cycles
with the longer term, strategic information and knowledge about the market to help avoid wild
swings in priorities or release goals. They are also listening for the occasional patterns and big
ideas that sometimes emerge from frequent customer interactions.

Agile Product Management White Paper Page 6 May 2008


Enthiosys, Inc. | www.Enthiosys.com 650.528.4000
5. Agile Product Teams
Agile Product Managers are deeply involved with their development teams. They also
engage with the rest of the company at appropriate times. This creates a
dramatically increased work load for Agile Product Managers. To succeed, Agile
Product Management groups need more resources. Additionally, Agile Product
Managers need to expand collaborative partnerships to supply
complimentary skills.

Agile Product Managers have several new responsibilities that add more
hours each week; continuously elaborating and clarifying requirements,
creating user interfaces, managing backlogs, preparing for and
participating in release and iteration planning, updating and communicating
roadmaps; collaborating with customers, and removing development
roadblocks.

With these new responsibilities Agile Product Managers also may need new
skills. Being able to negotiate the detailed trade-offs of a specific user story while maintaining
the context of the larger system and the customer’s goals demands a fine-grained understanding
of both the system and the market. This means they also need the ability to make good financial
choices that ensures that the product will satisfy the market without costing a fortune or creating
technical challenges for future releases. For many product managers, more frequent calls for UI
design input or the need to clarify requirements through the use of quick sketches and notes can
be challenging.

Rather than expecting Agile Product Managers to be able to successfully do everything


themselves, a more successful model is to create product “duos” or “trios”. This expands the
core product team to include full-time program management and part or full-time business
requirements analysts, letting individual Agile Product Mangers scale and accomplish their
goals. These new core product teams must execute their respective tasks while representing
each other as needed - without causing confusion. Thus, they develop tight working
relationships such that each can represent the team’s strategy, priorities and product goals.

Executives should know that a significant part of Agile’s demonstrated success comes from better
and more intense Agile Product Management inputs. This success translates into faster product
cycles, earlier market entry, improved customer satisfaction, and more top-line revenue.
Expanding the Agile Product Managers role - supplementing it with program managers and
business analysts – is a small cost when compared to improvements in developer efficiency and
effectiveness. Alternatively, Agile teams starved for product management fail to deliver on the
promises of Agile, therefore, adequate staffing, changes to organizational design and the
patience to let core product teams gel, is a prerequisite for success.

6. Communicating Information Up, Across and Out


Product managers must continually communicate the status of their releases, and the rationale
for their products. They often struggle to answer the organization's two urgently repeated
questions: "When will our product (or release) ship, and what features will it contain?"
A disciplined Agile Product Manager who is part of a functioning Agile team can deliver crisp,
clear and accurate answers to these two questions.

As noted above, Agile teams start with project-long estimates and staffing plans before work
begins. They use a release planning process to get these estimates/plans 85% complete. Then,

Agile Product Management White Paper Page 7 May 2008


Enthiosys, Inc. | www.Enthiosys.com 650.528.4000
during actual development, the teams apply "time-boxing" daily and end-of-sprint retrospectives
to tune their estimation process.

Agile teams collaborate with their Agile Product Managers to ensure that each backlog item can
be completed within a single sprint. This dramatically simplifies status reporting since each work
product on the backlog can be unambiguously in only one of three states: “not started”, “in
progress”, or “done”. This is a very powerful change for management, since task completion is
no longer based on individual judgment or optimism. Either the work is “done” or not, based on
the acceptance criteria established at the beginning of the sprint.

Also, as Agile teams become skilled at refining requirements into sprint-sized chunks of work,
they increase their ability to accurately estimate larger items of work. This secondary effect,
learned from consistently estimating smaller items of work, enables the product manager and
executive team to anticipate larger deliverables. Over time, the Agile Product Manager will be
able to apply each team's "velocity" information to current backlog items and factor it into the
current roadmap.

Agile’s focus on full completion of sprint-sized work items eliminates much of the fuzziness
in project reporting. Combined with teams improving their estimation from sprint to sprint,
we find that status reports are clearer, more actionable, and identify problems much earlier
in a project's lifetime.

Product Managers must also communicate subsets of this information – especially high-
level status and repetition of product objectives – within the broader organization. This
may involve a rich set of communications artifacts including wire frames or prototypes,
roadmaps, financial summaries, detailed user stories, market segmentation data, etc. We
know that every product needs a tireless champion, obsessively reminding the larger
organization why this product was approved and how it contributes to the company
strategy. Agile Product Managers are better able to handle this challenge, since their
projects are less likely to be wildly off schedule and their status information is
unambiguous.

Eventually, the team must commit to a specific date with a specific set of features, capabilities
and architectural elements. At some reasonable point in the release cycle, the team holds a
commitment meeting to ensure that everyone is on board with getting the software shipped -
and that what’s being shipped will meet market needs. This is the point when the rest of the
organization can lock down their plans and finalize whatever work remains to be ready to go to
market. Additionally, executives and sales teams should be confident about communicating
what’s coming and when by updating presentations and external roadmaps, signing up interested
customers to early trials and generally getting the word out.

As Agile Product Managers hone their skills at being able to roll this information back up into their
higher level planning artifacts (release plans and roadmap) they’ll be able to deliver crisp and
accurate communication about the product, market, customers and team into the portfolio
planning sessions. Eventually, portfolio managers will come to realize that the Agile Product
Manager is really the most informed person who can really help the company make good
financial decision.

Once companies transition all of their teams to Agile, all with experienced Agile Product
managers, they can expect to be able to re-balance their portfolios more frequently, based on
the richer factual information generated by the Agile process. More frequent rebalancing
combined with higher quality information leads to improved allocation of a technology company's
scarce resources to its highest-value opportunities.

Agile Product Management White Paper Page 8 May 2008


Enthiosys, Inc. | www.Enthiosys.com 650.528.4000
Conclusion
Technology companies are moving to Agile because they can deliver software more quickly, but
also because their products are better aligned with customer requirements. The move to Agile
forces changes throughout the company, well beyond the Engineering organization.

Product Managers are a critical driver of Agile and a strong determinant of its success, with Agile
Product Managers needing to do their jobs differently. They are in constant, tight
communications with their teams, elaborating requirements and user stories into smaller chunks
timed just as development needs it. Agile Product Managers manage active backlogs, interact
often with customers throughout the product cycle, keep projects aligned with roadmaps, and
provide intensive market-focused leadership.

This means that Agile Product Managers have more to do and new skills to develop. They need
to work at many organizational levels, communicating internally and externally, and be
comfortable zooming from deep technical details to customer benefits and back. This presents a
training and staffing challenge to companies. A partial solution to this challenge is to supplement
Agile Product Managers with program managers and requirements analysts.

Agile companies have more predictable software development, bring better products to market
faster, and build increasing trust across organizations. They see reporting become clearer and
more correct. Their product portfolios can be adjusted more often.

Executives who want these advantages need to understand and support their Product
Management teams as well as their Development teams.

Agile Product Management White Paper Page 9 May 2008


Enthiosys, Inc. | www.Enthiosys.com 650.528.4000

Vous aimerez peut-être aussi