Tag: Product Management

Deliver Valuable Solutions through Scrum (Part III)

Leveraging Impact Maps, User Story Maps, and Product Roadmaps to Align Organizational and IT Product Strategy using Scrum

This is the third and final part of a three-part blog series about aligning IT solutions/capabilities to organizational needs via an Agile-Scrum product management approach. You’ll find part one here and part two here.

In this article, I walk through how a Scrum Product Owner (PO), in collaboration with the rest of the Scrum Team and others, might bridge the “Product Management Vacuum” discussed in part II by  leveraging impact maps, User Story maps, and product roadmaps for Product Backlog refinement and release planning.

Part II Recap

In part II, I explained how the PO, as part of the Scrum Team, serves as the linchpin connecting the Scrum Team to the larger organizational product management structure.  The PO is responsible for fostering and maintaining ongoing collaboration between and among the Scrum Team(s), project/solution sponsors and stakeholders, customers, and end users to:

  • Define and maximize IT solution value in terms of expected and realized business/mission value
  • Define a product vision and strategy that aligns with organizational vision and strategy
  • Align the work performed by development teams to product vision and strategy

This product management function bridges what Ralph Jocham and Don McGreal call the “Product Management Vacuum.”   In the absence of a true product strategy, many organizations fill the vacuum with traditional project management activities that focus on managing tasks and people, rather than on defining the product/solution and improving development processes.  This typically leads to wasted effort borne out of disconnects between the Scrum Team, the sponsor organization, customers, and end users.

Finally, I introduced Jocham’s and McGreal’s “Three Vs” construct.  The “Three Vs” – Vision, Value, and Validation – sum up the product definition/management activities POs lead as part of their role.  The “Three Vs” are mutually dependent and reinforcing:

  • Vision drives the creation of value (features/functionality)
  • Value created enables validation of business assumptions behind product development choices
  • Validation informs changes to the product vision

The Official Scrum Artifacts

I am taking the time to clarify that most of the artifacts I discuss in this article are not official Scrum artifacts. The Scrum framework includes three official artifacts:  the Product Backlog, the Sprint Backlog, and the Increment.

The Product Backlog

According to the Scrum Guide, the Product Backlog:

…is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
  • The Product Backlog is the single source of requirements for a product/solution
  • Only the features and functionality compiled and ordered in the Product Backlog make it into the product
  • Helps the PO manage development scope
  • The PO owns the Product Backlog
  • Tracks product requirements evolution as the product and its environment change towards providing greater value

The Sprint Backlog

The Scrum Guide describes the Sprint Backlog as:

…the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
  • The Sprint Backlog makes visible all the work the Development Team plans to do during the Sprint
  • The highest ordered Product Backlog items become Sprint Backlog items
  • Sprint Backlog items have enough detail for the Development Team to understand what needs to be done
  • The Development Teams owns the Sprint Backlog
  • Only the Development Team can change its Sprint Backlog during a Sprint
  • The Development Team tracks progress and changes in work scope through the Sprint Backlog

The Increment

The Scrum Guide defines the Increment as:

…the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.
  • The increment is not just what the Development Team develops during the current Sprint. It includes whatever system/solution functionality the team developed in previous sprints
  • Every new Increment must be “Done” at the end of the Sprint
  • A “Done” increment meets the Scrum Team’s Definition of “Done”
  • A “Done” increment is ready for release and capable of providing usable and valuable functionality regardless of whether the PO decides to release it

Product Backlog Refinement

Product Backlog refinement is the management of product requirements by the Scrum Team.  The PO leads Product Backlog refinement in collaboration with the rest of the Scrum Team (i.e., the Development Team and Scrum Master) and with input from product/project sponsors, stakeholders, customers, and end users.  During Product Backlog refinement:

As the product evolves, higher ordered Product Backlog items become more detailed and the estimates become more precise.  With help from the PO, the Development Team defines and decomposes the highest ordered items they plan to work during the next iteration/Sprint into User Stories. The Development Team manages those stories in the Sprint Backlog.

Product Backlog refinement is an ongoing process.  The Scrum Team decides how and when to refine the Product Backlog.  However, the Scrum Guide recommends the Scrum Team expend no more than 10% of its “capacity” (i.e., the sum of productive hours across the team) on Product Backlog refinement.  Product Backlog refinement is not restricted to specific timeframes or meetings.  The PO can make changes to the backlog at any time or have others do so at his/her discretion.

A Product Management Scenario Example

In part I of this series, I discussed organizational and product visions and strategies generically.  To help visualize how all the parts fit together, I walk through a product definition and management scenario.

Over the last year, an online retailer has experienced a significant loss of market share to competitors.  The company investigated reasons for the drop in returning customers and new registrations.  The findings boiled down to customer dissatisfaction with business service functions across the value chain that negatively impacted the company’s reputation.  While the company enjoyed an early market lead for years, competitors were quickly closing the gap with more innovative customer-centric service options and better delivery performance.  The most significant problems found were:

  • Delivery problems
    • Customers receiving their orders late at a quarterly rate higher than industry average
    • Customer orders lost at a quarterly rate higher than industry average
    • Customers receiving the wrong orders at a quarterly rate higher than industry average
  • Customer service issues
    • Customer complaints about being bounced from one customer representative to another with a lack of continuity between representatives
    • Customer complaints about needing faster and more accessible help with “non-standard” issues requiring additional attention
    • Customer wish for an online customer service feedback option integrated with their ordering experience
  • Falling behind in offering new payment service options (Paypal, Google Pay, etc.)

Management shifted company strategy from a narrow focus on delivering an “outstanding” website experience to improving the entire buying experience, from online shopping to product delivery.  They revamped the company’s vision to match this new value stream-based approach to customer satisfaction and updated their business strategy to support it.

Company leadership recognized that a lack of customer focus caused the company to fall behind competitors and a subsequent decline in customer satisfaction.  To address this, the company changed how it defines its services by instituting a product management approach.  The company started looking at its website as a collection of online service offerings.  Company strategy needed to be tightly coupled to customer needs and demands, changing as the market changes.

The table below breaks out the flow down of strategic vision and business strategy to tactical product vision and strategy I explained in part I of this series.  The area highlighted in yellow is the “Product Management Vacuum” filled by organizational product management and POs in collaboration with the Scrum Team and with input from project/solution sponsors, stakeholders, customers, and end users.  I focus on the strategic goal to increase customer retention and acquisition through better customer service down to the tactical goal of improving the company’s Customer Service System.  Text of that tactical goal and its decomposed elements is colored red.

Table 1: Strategic Strategy to Product Strategy Decomposition

Defining Product Features

Armed with product goals, the PO works with the Scrum Team and others to define features they believe will help achieve them based on their current understanding of the business and market context.  The Scrum Team continually refines that understanding as the Scrum Team releases features to users.  The ultimate validation of the business assumptions behind new features is end-user validation.   New insights shape future features/capabilities and business/mission strategic and tactical strategies.

This picture depicts the interplay between organizational and product strategy validation.
Figure 1: Ongoing Organizational and Product Strategy Validation

Impact Mapping

Impact mapping is a strategic planning technique Scrum Teams can leverage to develop Product Backlog items such as Epics and User Stories as extensions to a defined product strategy. Impact maps are a great tool for visualizing alignment from product vision to coarse-grained product backlog items that Scrum Teams can order and further decompose and refine over time.

The diagram below depicts the use of an impact map to decompose the product vision and product objectives for the Customer Service System.  One or more coarse-grained Product Backlog items support each product objective.  These backlog items will collectively form the initial version of system requirements.  Over the course of Product Backlog refinement and Sprint Planning, the Scrum Team refines these items into User Stories.  Each backlog item includes of three elements:

  • Actor – The role for whom the backlog item is for.  The beneficiary of new feature functionality
  • Impact – The desired outcome from using the feature functionality
  • Deliverable – The new feature functionality that will help the actor achieve the desired impact

We avoid creating compound requirements.  In other words, each backlog item is specific to one role, one deliverable, and one impact.  These are high-level requirements, so the Scrum Team will identify, through their decomposition, different flavors of the same type of actor (e.g., administrator vs. regular user), related impacts for different flavors of actor, and related deliverables/features.  It is important to remember that these are system/solution-level items.  Too much specification now is counter-productive.

This is an impact map example.
Figure 2: Impact Map

Product Backlog

Product Backlog Recap

After defining a set of course-grained requirements, we create the initial version of the Product Backlog.  The Scrum Team writes requirements in the form of Epics and User Stories.  User Stories are backlog items the Development Team estimates will take no more than one Sprint to complete and make ready for release, while Epics are estimated to take more than one Sprint.  The Scrum Team decomposes Epics into User Stories as part of Product Backlog refinement.

At this point, we do not know how long it will take to complete each backlog item, so we do not know which items are Epics vs. User Stories.  It is likely that these coarse-grained items will be Epics but I call them User Stories and group them under “themes.”  The concept of themes is not part of the Scrum framework but they can come in handy when structuring the Product Backlog.  Scrum does recommend adding backlog attributes to group items when multiple Scrum Teams are working from the same backlog.

The Product Backlog table below maps each backlog item to the desired impacts and product objectives listed in in the impact map.  The product objectives become the value measures by which we measure whether each item’s feature delivers the expected business impact/outcome.  I highlighted the Actor and Deliverable elements in each User Story.

This table represents a Product Backlog
Table 2: Initial Product Backlog

Based on the coarse-grained User Stories listed in the table above, the Scrum Team knows enough about what it plans to build to provide the Customer Service System’s tactical plan.

Table 3: Tactical Goal Decomposition with Tactical Plans

User Story Sizing and Product Backlog Ordering

I will not go into detail about how to size and order Product Backlog items in this article.  However, I will highlight some key points that support the topics covered in this article:

  • The Scrum Guide refers to estimates rather than sizes.  However, the most popular estimation techniques in Scrum leverage the concept of “relative sizing.”  Instead of attempting to estimate how long it will take to complete a User Story, Scrum Teams use techniques like Planning Poker to estimate the story’s “size” relative to the other Product Backlog items.  Relative sizing is faster to do, more intuitive, and becomes increasingly more accurate as the Scrum Team “matures” than estimating in hours.
  • As part of the Scrum Team, the Development Team is solely responsible for all estimates.  The PO provides the business/mission context the Development Team needs to estimate the relative size of each Product Backlog item.
  • Typically, Scrum Teams estimate User Story sizes in “story points”, with “larger” stories earning higher point estimates.  Often, the point scale used is the Fibonacci Series or a modified version of it.  Story points are heuristically determined, numerical representations of User Story complexity, risk, uncertainty, and level of effort combined.
  • By tracking the number of User Story points the Scrum Team completes across multiple Sprints (at least three Sprints), the team determines its “velocity.”  Scrum Team velocity is a heuristic measure of a Scrum Team’s throughput (not productivity).  It is the rate at which a team delivers fully completed, tested, and accepted User Stories during a Sprint.
  • Scrum replaced Product Backlog “prioritization” with “ordering.”  Ordering better connotes the concept of ongoing backlog refinement.  Rather than periodically prioritizing backlog items according to vague business value categorizations, like High, Medium, and Low, and awarding multiple items the same priority, the Scrum Team continually orders backlog items based on their business value, risk, cost/size, and dependencies.
  • As User Stories rise in order, the Scrum Team fleshes out story details, provides more precise story point estimates, and decomposes larger stories into smaller stories the team can complete during a Sprint.

User Story Mapping

What are User Story Maps?

A Product Backlog is essentially an ordered queue.  As the number of User Stories grows, it becomes increasingly difficult see how all of the stories come together into a system/solution.  This is especially true for solutions that involve workflows.  A list of ordered features, written as User Stories, does not communicate how those features work together and what dependencies exist between them.

Scrum Teams can use User Story maps to organize an ordered Product Backlog across solution workflow steps, Sprints, and releases.  Scrum Teams may use User Story maps in tandem with Product Backlogs to help identify dependencies as part of backlog refinement.  It is a valuable tool to help plan releases as well.

Below is a User Story map example.  The map is a simplified workflow for coarse-grained User Stories #4 and #5 in the initial Product Backlog I discussed earlier in this article.  The User Stories read:

4. As a customer, I want the choice to provide feedback about the customer service I received so that I can communicate whether my issue was resolved to my satisfaction and why.
5. As a Customer Service Representative, I want access to customer feedback about issues I handle so that I learn how best to improve my performance.

The deliverable for User Story #4, listed in the example impact map, is a user feedback form.  However, as described in User Story #5, there is much more to the form then just a webpage to enter data.  The Scrum Team needs to develop a workflow that links multiple roles across the organization.  User Story #5 is likely an Epic in need of decomposition while User Story #4 is likely a User Story the Development Team can finish in one Sprint.  As Product Backlog refinement occurs, the scope of individual stories and of the entire workflow likely changes.

In this workflow, the Customer Service Coordinator reviews incoming feedback submittals, categorizes them, and assigns them to the appropriate part of the organization for resolution/acknowledgement.  Should the initial assignment be inappropriate or fail to yield a satisfactory outcome, the Customer Service Coordinator works across the organization to identify the right people to address the feedback.  Otherwise, the customer receives a response.

Below is a sample User Story map for this workflow.

Table 4: User Story Map Example

Let us walk through the User Story map’s elements:

Table 5: User Story Map Element Descriptions

The yellow cells in the User Story map example represent individual User Stories decomposed from the Epic directly above them in the “Walking Skeleton.”  This decomposition is not one person’s idea of how the Epic should be broken down, not even the PO’s.  It is instead the result of ongoing collaboration within the Scrum Team, informed by project sponsors and stakeholders, customers, and end users, and synthesized into a coherent product vision and strategy by the PO.

Development of a User Story map is an iterative process.  As the solution takes shape iteratively and incrementally, more users, User Stories, business activities, and business tasks emerge, requiring changes to the User Story map and the Product Backlog.  Fundamental changes in approach, predicated by insights learned during product validation, with actual customers and end users, may require changes to the product vision and strategy as well.

Product Roadmap

A product roadmap is a planning tool used to visualize when Scrum Teams estimate they will complete coarse-grained capabilities/Epics and in what order, over a given time horizon.  A product roadmap facilitates planning, not just for the Scrum Team, but also for project stakeholders outside the Scrum Team.  Common uses for product roadmaps include:

  • Communicating status and longer-term plans to organizational decision makers
  • Identifying business/mission dependencies across planned releases
  • Informs longer term business/mission planning (e.g., funding, contracting, agreements with external partners)

A product roadmap is not a schedule.  It is a snapshot of current planning, not a set of fixed milestone delivery dates.  Short-term release timelines (no more than three Sprints ahead) are based on User Story sizing and ordering (done as part of Product Backlog refinement) as well as demonstrated Scrum Team velocity.  The PO bases longer-term release timelines on the rank order of lower-ordered Product Backlog items and current knowledge of dependencies between those items. 

Like everything else in Agile and Scrum, product roadmaps are always subject to change.  As the solution emerges and new learning happens, plans change.  Agile planning is adaptive planning. Rather than creating detailed plans that span months or years, Scrum Teams wait until “the last responsible moment” to plan only the highest-ordered Product Backlog items in detail.

The recommended time horizon for Scrum Team planning is no more than the next Sprint and two Sprints beyond that.  Based on the recommended two to four-week Sprint length, that is no more than 12 weeks.  The amount of implementation detail behind a User Story increases the closer that story comes to being implemented by the Scrum Team.  User Stories planned for the next Sprint are much more detailed, and their estimates are better informed, than lower ordered User Stories tentatively scheduled for later Sprints.  Therefore, plans to implement solution functionality beyond the next three Sprints are highly imprecise and likely to change.

The sample Product Roadmap below maps the product strategy components I discuss throughout this article into a quarterly based plan for the year.

Table 6: Product Roadmap

Release Strategy

Depending on the size of the sponsor organization/company, the PO either contributes to an organizationally agreed-upon release strategy or collaborates with the Scrum Team, project sponsors and stakeholders, customers, and end users in developing one.  A product release strategy dictates:

  • Release Frequency – How often Scrum Team(s) release functionality: the more frequently, the better.  In Waterfall projects, there may only be only one a major release at the end of development. Release frequency for Agile/Scrum Teams ranges from releasing once at the end of each Sprint, to releasing multiple times throughout each Sprint, to achieving a steady flow of “done” functionality released on “demand” (Releasing functionality when customers/end users are ready to accept it)
  • Validation Frequency – How often customers and end users validate newly released functionality.  Obviously, the more often Scrum Teams release functionality, the more opportunities for validation exist

Market/mission demands drive release strategy. The sponsor organization must train, equip, and empower Development Teams and operations staff so they may deliver at a speed and cadence that matches demand. This is where DevOps plays a huge role.

In our company example, the company’s release strategy is to release at the end of every four-week Sprint.  Scrum Teams monitor usage and performance metrics for the capabilities they release and the organization monitors customer feedback.

Table 7: Tactical Goal Decomposition with Release Strategy

Release Planning

The product roadmap provides a high-level, “broad strokes” view of how planned releases fit together over an extended period of time.  The Scrum Team plans releases at a greater level of detail and across much shorter timeframes (no more than three Sprints).  A PO develops a release plan, which aligns with the operative release strategy, in collaboration with the rest of the Scrum Team, project sponsors and stakeholders, customers, and end users.  A release plan takes into account the following considerations:

  • The Scrum Team’s capacity to develop “done” capability at a sustainable pace
  • Technical and business/mission dependencies on or arising from planned functionality
  • The ability and willingness of customers and end users to “absorb” or accept planned changes
  • Alignment with business/mission strategy and product strategy

Just like a product roadmap, the release plan is subject to change.  Certainty over what a Development Team will develop and release over the next three Sprints is greatest for the next Sprint and becomes progressively less certain for the next two. However, since the release plan’s time horizon is so short and immediate, the frequency and magnitude of the changes should be significantly less than for a product roadmap. 

Below is an example of a release plan for the Customer Feedback Workflow capability based on the User Story map discussed earlier:

Table 8: Release Plan

Conclusion

Scrum is a framework and as such avoids over-prescribing practices and artifacts. The expectation is that practitioners will adhere to its rules and tailor existing processes to align with the framework, not the other way around. The concepts and tools presented in this series are meant to be used as enablers for aligning organizational vision and business strategy with product vision and strategy using Scrum.

Scrum has an inherent product management bias that is a definite departure from the traditional project management mentality that has reigned over organizational IT for decades. A product management approach to organizational IT shifts project-centric, internally-focused sponsor organizations towards putting the customer first and focusing on achieving outcomes, rather than executing plans.



Deliver Valuable Solutions through Scrum (Part II)

Product Owners are responsible for top-down and bottom-up alignment of IT solution business value

This is the second of a three-part blog series about aligning IT solutions/capabilities to organizational needs via an Agile-Scrum product management approach. You’ll find the first part here.

In part I of this three-part series, I asserted that Scrum bridges the common disconnect between solutions delivered by organizational IT management and the needs and expectations of sponsors, stakeholders, customers, and end-users. I provided a sense of the magnitude of the problem by referencing analysis from the 2015 Standish Group CHAOS Report which found that less than half of all IT projects deliver business value. I then explained how Scrum’s product management mindset differs from that of traditional project management. Finally, I explained how a product management approach aligns IT product/solution vision and strategy with organizational vision and strategy based on the concept of delivering business/mission value.

In part II, I discuss how the Scrum Product Owner (PO) defines product value and maintains alignment between his/her product vision and strategy and organizational vision and strategy.

The Product Owner as Value Maximizer

In Scrum, the PO is the linchpin that connects the Scrum Team to the larger organizational product management structure.  Scrum defines the PO as one of the three official roles of a Scrum Team. The PO represents the Voice of the Customer for a product/solution.  The PO is responsible for fusing the various needs, wants, and perspectives of product or project stakeholders into one complete, coherent, and cohesive vision. The Development Team looks to the PO as the primary (but not necessarily the only) source of business knowledge and understanding.  That understanding informs development of IT capabilities that provide maximum value to the organization and users.

In large organizations, POs may work within a product management organizational structure that coordinates product management activities across the organization.  Working closely with program management offices (PMOs), product management focuses on making the right things while program management focuses on managing schedule, budget , and resource constraints.

While aligning product strategy with organizational strategy is inherently a top-down activity, both strategies must be informed by bottom-up input/feedback from development teams, customers, and end users. Product management organizations and the POs who collaborate within them are responsible for fostering and maintaining ongoing collaboration in both directions.

The Product Management Vacuum

In their book, “The Professional Product Owner: Leveraging Scrum as a Competitive Advantage,” Ralph Jocham and Don McGreal make the case that most organizations do a poor job of linking product vision and strategy to business strategy and the work performed by development teams.  They call this deficiency the “Product Management Vacuum.”

The Product Management Vacuum

The authors explain that the vacuum is typically filled by traditional project management activities. Those activities lead to wasted effort and disconnect development teams from the larger organization as well as from customers and end users. By focusing on managing tasks and people, rather than on defining the product and improving development processes, traditional project managers and the development teams they manage lose sight of product value.  Resulting solutions are largely disconnected from organizational vision and strategy and from customer and end-user needs.

The Product Owner Fills the Vacuum

In Scrum, the PO fills the Product Management Vacuum:

  • Product Vision – The PO is responsible for formulating and socializing the product vision among the Scrum Team, stakeholders, customers, and end users
  • Product Strategy – The PO is responsible for identifying and driving development of IT capabilities that support business goals and objectives as well as satisfy customer and end-user needs and desires
  • Release Management – The PO coordinates product release strategy with relevant organizational stakeholders

The PO does not carry out these responsibilities alone. The PO collaborates with the development team, sponsors, stakeholders, customers, and users but is primarily responsible for outcomes.

The Three Vs

Through their construct of “The Three Vs: Vision, Value, and Validation” Jocham and McGreal explain how Scrum maintains alignment between product vision and business value. The Product Owner leads and is ultimately responsible for the activities performed in support of the Three Vs.

Activities and Responsibilities under “The Three Vs”

The interplay between product vision, value, and validation can be summed up as:

Interplay between Product Vision, Product Value, and Product Validation

  • Vision drives the creation of value (features/functionality)
  • Value created enables validation of business assumptions behind product development choices
  • Validation informs changes to the product vision

On the Next Installment…

In the third and final part of this series, I will explain how POs define and manage The Three Vs by managing the Product Backlog. As part of my explanation, I will showcase three artifacts: Impact Maps, User Story Maps, and Product Roadmaps.

Conclusion

POs play a central role in aligning the IT solutions they shepherd through product management and development activities with organizational vision and strategy. To achieve that alignment, product management and organizational strategies require ongoing feedback and collaboration with customers and end users. The Scrum framework is optimal for achieving this top-down and bottom-up alignment for IT solutions.



Deliver Valuable Solutions through Scrum (Part I)

Building the right thing is as important as building things right. Scrum aligns organizational strategy and IT via a product management mindset.

This is the first of a three-part blog series about aligning IT solutions/capabilities to organizational needs via an Agile-Scrum product management approach.

Information Technology (IT) management is about leveraging technology investments to address business/mission needs. IT management is responsible for ensuring that budgets spent on IT solutions result in the implementation and ongoing support of effective and economical systems and processes. Effectiveness is the degree to which such investments help the organization achieve business goals and objectives. Economy translates into the total cost of ownership (TCO) incurred from adopting a solution as well as efficiencies gained through its use. Effectiveness and economy are actually signifiers for the many elements that make up business value. Ultimately, the success or failure of any IT implementation is judged by the value it delivers.

IT’s (Poor) Record at Delivering Value

Unfortunately, IT management’s track record for delivering value is lack luster.  According to the 2015 Standish Group CHAOS Report:

  • Only 29%
    of IT projects are successful    . 
    Successful projects are delivered within estimated time (OnTime), within
    budget (OnBudget), and satisfactorily (Satisfactory).  The Standish Group defined satisfaction as
    the level of customer and user satisfaction achieved, regardless of how much of
    the original project scope was delivered.
  • 52% of IT
    projects are challenged    .  Challenged
    projects are delivered but miss the mark on at least one of the three criteria
    above.
  • 19% of IT
    project fail    .  Failed projects fail
    to deliver any capability.

Along with the three measures listed above, the Standish Group also measures how valuable the implementation is deemed to be (Valuable) and how clearly defined the business objectives were for the project (OnGoal):

  • 59% of IT projects are considered valuable
  • 62% of IT projects align to clearly-defined business objectives

So, based on the polling, of the 81% of projects that deliver some level of capability, 59% are considered valuable.  This translates into less than half of all IT projects delivering value.

Scrum’s Product Management Mindset

A major difference between Scrum and traditional IT project management is Scrum’s product development/management mindset.  Agile in general and Scrum in particular have deep roots in product management and Lean.  Two fundamental principles of both Agile and Scrum exemplify their alignment with modern product management:

  • Focus on delivering value and evaluate progress based on actual value delivered rather than tracking progress on planned activities
  • Team Self-Organization –  Development teams manage their work, determine technical approaches, estimate their work, report their progress, and help define the product

A good way to illustrate the differences between product management vs. project management mindsets is to compare the core functions performed by product managers and project managers.  While their work often overlaps, their primary responsibilities compare as follows:

Product management is about managing what the product will be and how the product is created. Project management is about managing people, schedule, and resources.
Product Management vs. Project Management

It is important to note that the scope of what constitutes product management is much bigger than Scrum. Scrum is a way of developing products, including software, that dovetails nicely with the philosophy and practice of modern product development and product management..

The Product Management Approach to Value

The predominant trend across software development companies is a shift away from traditional project management to Agile. Companies are making the shift to:

  • Accelerate time-to-market performance
  • Address rising expectations of demanding customers
  • Compete in fast-changing markets

Fundamentally, this is a shift away from predictive project planning to adaptive product management.

Product Management for Organizational IT

However, IT management and portfolio management are firmly in the sphere of organizational IT. Development of organizational IT solutions is different from for that of product solutions for the following reasons:

  • Most organizational IT initiatives are system integration efforts
  • System integration efforts are driven by sponsor organizations
  • Sponsor organizations decide which capabilities to develop or acquire, how much budget to allocate, and when new IT capabilities are due. Unlike products, these decisions are not shaped primarily by market demand
  • Most IT solutions are highly customized implementations tailored to the needs of the sponsor organization, rather than designed to compete in a generalized market
  • IT solutions integrated into enterprise environments are typically much more constrained technically and organizationally than green-field product development efforts

Thus, system integration efforts are, by nature, service engagements, not product development efforts .

So if product and system integration efforts are so different, does product management apply to organizational IT?  Whether an organization is a business, a government entity, or a non-profit, product management activities occur to some extent as part of deciding what IT capabilities to develop or acquire. The term “product” can refer to any technical product/solution, business process, or a combination of the two.

Defining Value

Equating the value of a technology solution or service to its cost is a mistake.  The world is littered with all kinds of expensive solutions that yield little to no value for their owners or users.  How we define value is at the heart of how we link IT investments to organizational needs because the value of any particular solution is inextricably tied to the value provided by the organization.

A solution is valuable when it benefits those who acquire it and use it (customers) and those who create it (producers).  Benefits to customers boil down to what they care about or makes them happy.  Benefits to profit-driven producers map to outcomes necessary for sustaining and growing the business: revenue, profit, cost savings, increased market share, customer loyalty, etc.  Benefits for non-profit producers (e.g., government agencies, charities) align with mission execution and accomplishment: protecting lives, promoting health, caring for the needy, etc.

These categories of value are not isolated.  A business that focuses on providing excellent
value for its customers, gains a following, and experiences increased revenue
and profit.  A charity that fails to
raise money or mismanages its budget is soon in no position to provide aid to
anyone.  Organizations that focus on
pleasing customers at the expense of the wellbeing of their employees
eventually suffer morale problems and employee turnover that cripple their
effectiveness.

Organizations can experience negative value.  Negative
value occurs when:

  • Organizational or technical problems diminish the value provided or achieved
  • Actualized outcomes do not align with expected/preferred outcomes

Examples of negative value accrual:

  • A website that stores customer credit card
    information is hacked
  • A charity spends significantly more on operating
    expenses and salaries than on providing services to people in need

Organizational Vision

The value an organization attains or provides by acquiring or developing IT solutions must align with that organization’s vision.  The organizational vision serves as the organization’s North Star as it navigates decisions towards an envisioned future state.  The vision answers, clearly and concisely:

  • What is the organization’s reason for
    existence?  What contribution or impact
    does it intend to make and to what end (purpose)?
  • What is the organization working towards
    becoming?  What will set it apart from
    competitors or alternatives in its market or mission space?

The organizational vision should inspire and motivate people.  A vision that fails to connect with people emotionally will fail to muster the enthusiasm and perseverance needed to overcome difficulties and achieve challenging goals.

Business Strategy

The organizational vision informs business/mission strategy.  The strategy is a roadmap of actionable objectives that culminate into achievable goals.  Goals are the desired long-term business results or outcomes that incorporate the vision.  Achieving them lets us know we reached the destination described in the organizational vision.  Objectives are measurable milestone achievements necessary to attain organizational goals.  The work and resources needed to achieve the objectives inform strategic and tactical plans implemented across the organization.  Objectives are decomposed and flow down from the strategic level to the tactical level.  Objectives at different levels of the organization spur the development of plans to achieve them.

Strategic vision decomposes to business strategy. Business strategy decomposes to strategic and tactical plans.
Strategic Vision and Strategy Decomposition

IT solution implementations may be strategic initiatives,
tactical-level initiatives, or both. 
Regardless of the organizational level they directly support, the value
provided by IT solutions must support business strategy and, by extension, the
organizational vision.

Defining IT Solutions

Similar to the organizations they support, well-planned IT solution implementations (products) follow from a well-defined product vision and product strategy.  An organization may develop products for external and internal users. 

Product Vision

The product vision communicates the desired end state for the product in business or mission terms.  The product vision clearly and concisely answers:

  • Who is/are the target audience/customer(s) for
    the product?
  • What is the product’s most important benefit or
    value proposition?
  • How does the product differ from existing
    alternatives?
  • What sets the product apart?  What is the product’s competitive advantage?

The product vision may link to business strategy as a goal, an objective, or as an activity defined as part of a strategic or tactical plan.  For example, a company selling products and services online, as its primary delivery channel, may set a goal to be the first to offer a new online service.  Since it is an online company, it is conceivable that the new online service offering may rise to the level of a goal that directly supports the company’s vision.  In other cases, an IT implementation may be an objective towards a strategic goal or an activity necessary for accomplishing a strategic or tactical objective.

Product Strategy

The product strategy is the roadmap towards realizing the
product vision.  Considerations addressed
by a product strategy include:

  • What will the product be?  What characteristics must the product incorporate to address customer and producer needs?
  • What product features would best deliver value to customers/users?  How will the product differentiate itself from competitors or alternatives?
  • How is quality defined for the product?  What characteristics and/or behavior must the product embody/demonstrate to be a quality product?
  • How will the product be branded or introduced to users?  Which product characteristics would support the organization’s brand image, reputation, or culture?
  • How will a commercial product be positioned in the market? How will organizational IT solutions be acquired (contract types, source selection, budgets, etc.)?

Product Value

Returning to the topic of value, we now focus on the value the product provides.  As stated earlier, value provided by IT solutions must align with the organization’s vision and business strategy.  Also important to consider is the alignment of product strategy with the work performed by Agile development teams. 

How do we characterize product value and, once alignment with product strategy is achieved, how do we maintain it? I will address these topics in part two of this blog series.

Conclusion

Building the right thing is every bit as important as building things right. Often, organizations hyper-focus on defining and building or acquiring technical capabilities while losing sight of whether the resulting solutions solve the right problems and address the right needs. The current pace of organizational and technological change requires that organizations adopt an IT management approach that incorporates the product management mindset championed by Scrum. Doing so helps ensure that IT investments further organizational vision and goals by creating real, measurable value for both the organization and its customers.



Putting the Federal Government in the Agile Driver’s Seat

The definition of system features and scope in federal Agile and SAFe development efforts is an inherently governmental responsibility.

Recently, I came across a job posting for a Scaled Agile Framework (SAFe) product owner (PO) position with a federal government contracting firm. As someone interested in implementing SAFe within the Federal Government, I reviewed it. I wanted to get a sense for whether the job description adhered to the role as described in SAFe and, perhaps, glean the agency’s level of commitment to implementing the framework. Indeed, the duties described were the same as those prescribed by SAFe, however, my initial excitement at seeing yet another example of SAFe adoption within the Federal Government quickly turned into disappointment. The agency was handing over the definition of features and overall work scope to a contractor. This is a fundamental mistake rooted in traditional federal acquisition biases.

The Lead System Integrator Model

The Federal Government tends to outsource the overwhelming majority of its information technology (IT) and digital systems work to contracting firms. This includes the full life-cycle development and operation & maintenance (O&M) of digital systems as well as most of the program management of those activities. The Department of Defense (DoD) often designates contracting firms as Lead Systems Integrators (LSIs) to manage the integration of large-scale, complex, multi-year, digital systems-of-systems (SoS) implementations. Section 805 of the FY2006 National Defense Authorization Act defines two types of LSIs:

  • LSIs “with system responsibility” – Prime contractors responsible for the technical coordination and managerial execution of a systems development program at the system level. They do not perform technical implementation work at either the system or sub-system levels.
  • LSIs “without system responsibility” – Contractors who perform acquisition functions closely associated with inherently governmental functions.

Federal agencies turned to the LSI model in the late 1990s to compensate for a lack of in-house, technical and project management expertise caused by reductions in force of the federal acquisition workforce (by more than 50 percent between 1994 and 2005) and the rapidly increasing complexity of system solutions. By the mid-2000s, however, issues concerning LSI conflicts of interest (e.g., shaping integrations to promote LSI products), lack of effective governmental oversight over LSIs, lack of government visibility into sub-contractor activities, and the difficulty of replacing entrenched LSIs led to legislative and policy reforms and less affinity for the LSI model within the federal acquisitions community.

Today, many agencies are increasingly assuming the LSI role and instituting modular contracting policies to narrow the scope of large acquisition programs into smaller, more manageable programs and projects that do not necessitate a large LSI role. However, in many parts of the Federal Government, there is still a bias towards limited government involvement in the day-to-day management of contractor activities and capability definition. Typically, this bias exists because of a lack of expertise and/or resources. However, this bias sometimes bleeds into activities that can/are considered inherently governmental. I posit that the product management work performed by SAFe POs and Product Managers (PMs) is inherently governmental.

The Role of Product Owner in Agile

The PO is a member of an Agile software development team. They represent the “face of the customer” who will be using the functionality developed by the team. They bring to the team a deep understanding of customer needs and the business domain/market environment the solution will serve. The PO is primarily responsible for:

  • Defining solution capabilities and features through the development of Agile epics and user stories and their prioritization within the team’s product and iteration backlogs

Backlogs include technical work that supports the development and implementation of new business/mission capabilities and features.   Such technical work mostly revolves around the implementation of physical and software infrastructure (“enablers” in SAFe).  While POs are not expected to understand the technical details, they must be able to take into account the scope of these enablers and collaborate with technical contributors in prioritizing the work.

  • Planning upcoming sprints/iterations
  • Elaborating/amplifying user stories before an iteration, during iteration planning, and during iterations. They provide additional information necessary to implement stories.
  • Supporting user story acceptance testing by participating in the development of user story acceptance criteria and formally accepting user stories when they meet the criteria
  • Participating in team demos and retrospectives

All of these activities are informed by input from project stakeholders, customers, product management, program/project management, and the Agile team itself.

Product Management in SAFe

As a framework founded on Agile principles and Scrum practices, SAFe includes the PO role but goes further by including the concept of a product management team function across every configuration of the Framework: Full, Portfolio, Large Solution, and Essential SAFe. SAFe POs collaborate with their development teams in defining team backlogs and help formulate and articulate a program vision and program roadmap. The program vision and program roadmap inform/guide the development of program features and team user stories. The program vision and program roadmap are themselves shaped by solution and portfolio-level concerns (depending on the SAFe configuration implemented). POs in SAFe are at the most tactical end of a strategic product management regime.

Breaking the Iron Triangle

The most fundamental way Agile and SAFe achieve agility is by breaking the Iron Triangle. Instead of attempting to fix schedule, budget, and scope upfront, we fix schedule (timebox) and budget while letting scope “float.” However, both Agile and SAFe prevent project/work scope from floating too far because POs are empowered to define, prioritize, and approve scope.  Moreover, in SAFe, POs and PMs across the SAFe hierarchy enforce scope discipline by:

  • Communicating with development teams regularly and often
  • Defining and articulating SAFe Agile requirements (epics, capabilities, features, user stories, and enablers)
  • Prioritizing SAFe Agile requirements
  • Actively participating as the acceptance authorities of developed functionality vis-à-vis SAFe Agile requirements
  • Working with teams to plan sprints/iterations, releases, and program increments (PI) – Breaking up scope across timeboxes

Agile and SAFe promote and enforce transparency at all levels. Decisions are made in the open with the input and concurrence of all pertinent stakeholders. In properly run Agile teams, there are no surprises: teams commit to a known set of work; the work is tested as it is developed and integrated and test results are made known; and release candidates are demonstrated to work at the end of each iteration and PI. Issues and impediments that jeopardize delivery are exposed every day through Scrums, automated testing, and frequent integration.

Breaking the Iron Triangle is a big departure from the way federal acquisitions currently works. Federal program management oversight culture and practices must change so that government program managers and project stakeholders can begin to take a much more active role in the definition of functional requirements alongside Agile teams. This will take changes in acquisition policy and law, training across government acquisition and functional communities, and leadership committed to championing new approaches to old, recurring problems. Progress in this direction is being made (e.g., 18F, Digital Services, the TechFar, Modular Contracting and a slowly growing willingness to acquire Agile services under Time & Materials (T&M) and Level of Effort (LOE) contracts).

Conclusion

Appointing contractors to act as SAFe POs and PMs is an indicator that the SAFe implementation/adoption is subverted (an anti-pattern). It is a throwback to the lack of oversight and control experienced under earlier programs run by LSIs. To ensure that real value is created for every taxpayer dollar spent on federal systems development, the Federal Government must be in the driver’s seat. SAFe enables the creation of an ecosystem where technical and management expertise from the private sector works to fulfill requirements continuously defined and prioritized by government stakeholders. This “just in time” approach to scope and requirements definition is the key to achieving agility, lowering costs, and achieving faster, more frequent releases, while improving quality.