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.
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 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:
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
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 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.
An interesting 2017 conference white paper is circulating in Agile forums. It addresses the question, “Which Scrum role should project managers assume on an Agile-Scrum project?” The white paper, entitled “A Study of the Scrum Master’s Role,”[1] argues that it should be the Product Owner role.
Before delving into the white paper’s findings, I am
providing a little background on Agile and Scrum.
Agile and Scrum
Agile is a software development approach in which software
development teams:
Self-organize – Team members collectively define
and manage their work and processes
Deliver increments of software functionality
that are tested and ready to be deployed and used
Delivery increments over the course of multiple
short-term iterations/Sprints
Are guided by direct interaction with product stakeholders
and end-users
Scrum is one of many approaches to Agile software
development. Other examples are Extreme Programming (XP) and Feature-Driven
Development (FDD).
The Scrum Team
The Scrum Team is the basic unit of organization for Scrum. Scrum Teams are small, consisting of three to
nine members each. Small teams are more
agile because their size lowers complexity.
Communication between members is immediate and having fewer members
minimizes the number of dependencies between them. Scrum enables small development teams to
punch well above their weight.
By constraining the scope of releases into smaller “Lego
blocks” of functionality that build on each other, small Scrum Teams are able
to deliver more useful functionality, at higher levels of quality, faster. Smaller releases, delivered more frequently,
provide more opportunities for evaluating and adapting both the product and how
it is developed.
When project scope and schedule constraints make adding more
technical contributors necessary, they organize into multiple Scrum Teams. Scrum Teams identify and address mutual
dependencies and ensure that the collective product aligns with the needs and
desires of stakeholders and customers.
The Three Scrum Team Roles
As described in the Scrum Guide, Scrum specifies three
formal roles within a Scrum Team: Product Owner, Scrum Master, and Development
Team. The Scrum Team collectively shares
responsibility for the following activities:
Defining product (system, application, etc.) features
Prioritizing features
Estimating level of effort for developing each
feature
Planning incremental releases of features
Iteratively shaping the product throughout
development based on user and stakeholder feedback
While the Scrum Team performs the activities above collectively, each role has a distinct set of responsibilities:
Descriptions of Scrum Team Roles
You may ask, “What about other roles typically performed in software
development projects? How do they contribute to Agile projects?” In the case of Scrum, those roles lend
support to the work of the Scrum Teams.
Examples:
Enterprise architects and development teams work
together to define the longer-term technical direction of the product
Testers become Development Team members and
automate as much of the testing effort as possible within and across Scrum
Teams
Business analysts facilitate discussions between
Scrum Teams and end users to ensure the product ultimately serves business
needs
The key to placing project managers in Scrum projects is to place
them in a role that allows them to use their skills and experience in ways that
naturally align with Scrum Team self-organization.
Should Project Managers Work Agile Projects?
Since Agile teams self-organize, many argue that project
managers have no role in Agile. The
thinking is that traditional project management is a command-and-control,
top-down approach focused on managing people and tasks and ensuring strict
adherence to a predetermined plan. In
contrast, Agile is a bottom-up, decentralized approach to software development focused on managing the
development of the product itself rather than people and tasks.
Despite conventional wisdom against it, the authors found
that it is quite common for project managers to work in Agile software development
projects as project managers:
Yet, in a recent survey that looked into whether project
managers still exist in Agile development teams, Shashtri and Hoda were
surprised to learn that 67% of organizations surveyed reported that they still
had the Project Manager role.
This may be a sign of the fact that Agile adoption can be
difficult and takes time. According to
the white paper:
While the vast
majority of organizations are moving towards [some] form of agile development,
for most of these organizations, more than half of their teams are still following
traditional, plan-driven methods.
When the bulk of an organization operates under traditional
project management, it is easy to understand a preference for including project
managers across all project types, including Scrum. Project managers are already working Scrum
projects, so the debate over whether they should do so is irrelevant and
unproductive. Instead, the focus should
be on how to better utilize them in support of Agile and Scrum.
Project Managers as Scrum Masters
According to the white paper, project managers often participate
in Scrum projects is as Scrum Masters.
At first blush, this seems like the best way to leverage project managers’
people and task management experience. Many
managers are dual-hatted as project managers and Scrum Masters.
However, it is often difficult for project managers to
assume the role of Scrum Master because the two roles are fundamentally
different and, to a significant degree, incompatible. Combining the two roles in one person is
unfair to the project manager and to the Scrum Team. I compare the two roles below:
Project Manager vs. Scrum Master Roles
Confusion Over the Scrum Master Role
There appears to be a shift in Agile literature that is
adapting, conflating, and, in some cases, corrupting the original Scrum Team
roles. The authors conducted a “systemic
review” of Agile literature. They found
that, along with the traditional Scrum Master activities of “process
facilitation, ceremony facilitation, and impediment removal,” many sources ascribe
to Scrum Masters project management activities or activities belonging to the
other Scrum Team roles.
The authors opine that this documented shift in what activities
are characterized as Scrum Master responsibilities comes from a corruption of
the Scrum Master role. This corruption
typically occurs in organizations rooted in traditional project management as
they transition to Scrum. As stated
earlier, such organizations often appoint project managers to serve as Scrum
Masters. Those organizations also tend
to contort Agile practices to fit their existing command-and-control management
culture with project managers leading the way as Scrum Masters.
Product Owners Own Scrum Project Management Activities
The white paper references fifteen papers that characterize a
number of activities outside the scope of the original Scrum Master role as Scrum
Master responsibilities. The authors
contrast that list with five project management activities required in Scrum:
Five Scrum Project Management Activities
Of the five project management activities, three belong to
the Product Owner. The one overlap
between the project manager and Scrum Master roles is the process management
category which, while important, does not require a project manager to perform.
Conclusion
The best way for traditional project managers to contribute
to Scrum software development projects is by becoming Product Owners. There is significant overlap between the two
roles, thus the transition should be easier and more in line with the valuable skills,
talents, and experience project managers bring to the job.
Successfully achieving this transition requires training,
coaching, and meaningful organizational support. No amount of training and coaching will help
a new Product Owner perform in a traditional project management culture. In essence, the decision to adopt Agile
software development affects the entire organization, not just technical
contributors. The organizations that
reap the full benefits of Agile adoption embrace Agile as a cultural
transformation, not just as a different way to develop products.
[1] Noll, John & Razzak, Mohammad Abdur & Bass, Julian & Beecham, Sarah. (2017). A Study of the Scrum Master’s Role. 307-323. 10.1007/978-3-319-69926-4_22. https://arxiv.org/pdf/1712.01177.pdf
Agile team velocity is an often misunderstood concept that is prone to misapplication. This article sets the record straight.
Agile software development is theway we build software now. The general consensus on management of software development projects is that predictive planning approaches (e.g., Waterfall) are ill suited for the job. However, almost two decades after the release of the Agile Manifesto and the rise of Scrum as the most popular Agile framework, team velocity is still a point of confusion.
Some organizations are under the mistaken idea that they can “buy” Agile-Scrum software development services à la carte based on team velocities. Under this contracting model, service vendors offer prepackaged teams rated at some velocity. Based on that velocity, the organization could then pay for a certain amount of that team’s time to complete predefined tasks. This arrangement treats Scrum teams as plug-and-play units of development capability. This mentality is evidence of a fundamental misunderstanding of Agile and Scrum, of what teams require to be effective, and of the concept of team velocity itself.
What is Team Velocity?
The concept of team velocity is not officially part of the Scrum framework. It is a best practice for estimating Development Team throughput. More specifically, it is the rate at which the Development Team, in collaboration with the other members of the Scrum Team (i.e., the Product Owner and ScrumMaster), delivers discrete items of functionality that are finished, tested, and accepted during an iteration/Sprint. The Scrum Team documents requirements for those items as User Stories and tracks and orders User Stories in the Product Backlog.
Rather than simply counting the number of completed stories at the end of a Sprint, the Scrum Team determines its velocity by adding together story points from every story completed during the Sprint. Story points form the basis for determining team velocity. Calculating team velocity allows Development Teams to estimate the amount of capability (value) they can deliver at a sustainable pace during a Sprint.
Σ Story Points of Completed User Stories During a Sprint = Velocity
It is important to view team velocity results as data points along a trend, rather than as definitive stand-alone measures. In other words, to understand how much value a Development Team is capable of delivering, we need to look at velocity results from the previous two or three Sprints to get a sense of whether the latest result is part of a trend or an anomaly. Such anomalies often indicate issues requiring attention.
Like the concept of team velocity, story points are not part of the Scrum framework. The Development Team assigns story points to Product Backlog items (i.e., Epics and User Stories). Story points are heuristically-determined, numerical proxies representing the combination of perceived or estimated:
User Story complexity, risk, and uncertainty
Level of effort required to complete the User Story
This combination is often referred to as the “bigness” or “size” of a User Story. The Development Team estimates User Story points by “sizing” User Stories relative to each other. More complex User Stories typically require more time and effort to complete, thus earning more story points than less complex stories.
Story point estimation is not restricted to specific timeframes or meetings. It is part of a continual refinement of Product Backlog items by the Scrum Team that includes:
1. Only the Development Team estimates story points with input from the Product Owner and other relevant stakeholders. They are not determined by a chief engineer or some other senior authority as an estimation exercise prior to the establishment of Development Teams and the appointment of Product Owners.
2. Team velocity is specific to the team. Velocity cannot be used as a point of comparison between teams. Team X is not necessarily faster or able to attain a higher throughput than Team Y because they earned a higher number of story points during a Sprint. The story points upon which team velocity is based are specific to the relative sizing performed by the team on their particular backlog of User Stories.
3. A team’s velocity is the end result of many factors, including:
Individual team member productivity across the team
Team cohesion, collaboration, and effectiveness
Team skill set and experience mix
Level of programmatic support (i.e., the factors that fall under the purview of program management)
Empowerment and level of engagement of Product Owners
The team’s familiarity with the business domain, technology mix, and enterprise architecture
The amount of automation leveraged in building, testing, and deploying code
Thus, the makeup of the Scrum Teams and the environment or ecosystem within which they operate determine velocity. Team velocity is ultimately a proxy for the overall health of the software development program and organization. When team velocity stagnates or drops, the search for potential causes must be systemicas opposed to a hunt for individual culpability.
4. It is normal for team velocity to fluctuate. What should concern us are large fluctuations or downward trends in velocity. Changes in personnel, technology, organizational structure, etc. will affect development teams in different ways and to varying degrees.
5. Improving team velocity is not the goal! Improving team capabilities, practices, tools, and program support improves team velocity. Focusing on improving velocity results in attempts to game the system rather than systemic improvement.
Conclusion
Scrum Development Teams are composed of people. People are not machines calibrated to deliver a predetermined rate of output. Teams need time and stability to gel into highly effective teams. Helicoptering Scrum Teams, even experienced ones, in and out of tasks significantly degrades velocity except perhaps for the most mundane and menial tasks (In which case, why employ Agile/Scrum at all?). Decades of reducing people to resources allocated across Gantt charts has led many to also think of Scrum Teams as abstract productivity units. Scrum requires much more of us.
