Avoid these Product Owner pitfalls to achieve greater product clarity and better team execution.
Table of Contents
The product owner is one of the three roles defined in Scrum: Product Owner (PO), Scrum Master, and the Development Team. The three combine to form the Scrum Team.
The PO synthesizes the needs of product sponsors, stakeholders, customers, and end users (which I refer to as the Stakeholder Community), with input from the Development Team, into a coherent, viable, and executable product vision. The product vision guides Scrum Team decision making.
POs fill the “The Product Management Vacuum” between company/organizational vision and strategy and the work performed by development teams. Effective POs lead conversations about which digital capabilities to develop and why.
Ineffective POs typically exemplify these four characteristics:
Lack understanding of the target business/mission/market
Lack a product vision
Struggle making tough choices
Are not empowered to make decisions
Ineffective Product Ownership
Lack Understanding of the Business / Mission / Market
The PO is “the voice of the customer” for the Scrum Team. This means POs advocate for the needs, expectations, and desires of customers in the product’s business, mission, or market segment. They define and communicate requirements from the perspective of customers and end users. They can only do so if they posses a deep understanding of the relevant business, mission, or market. In a choice between deep business, mission, or market understanding and technical knowledge, the former trumps the latter.
Ineffective POs lack intimate business, mission or market knowledge. Thus, they often fall into a proxy role between Stakeholder Community members and the Scrum Team. Rather than driving product vision definition in collaboration with the Stakeholder Community and the Scrum Team, they merely document requested features. They struggle to explain the value of requested features or guide Scrum Teams as they learn the business, mission, or market domain.
Lack a Product Vision
A product vision communicates the desired end state of a product in business or mission terms. Possessing a deep understanding of market, customer, and end-user needs is crucial but not enough. The PO must leverage that understanding to develop and evolve a product vision. An ineffective PO either does not see the value of developing a product vision or does not have the skills to do so.
Struggle Making Tough Choices
Making choices about the product is difficult without a clear product vision. Having one enables the following decisions:
Prioritization the Stakeholder Community needs, expectations, and desires
Definition of features likely to address Stakeholder Community needs, expectations, and desires
Prioritization of features into valuable deployable capabilities
Determining which capabilities fit within product scope (when to say no)
A product cannot be all things to all people. Tough decisions about what to include in a product offering are sometimes necessary. Competing priorities and different levels of power or influence among Stakeholder Community members can make this difficult. An effective PO fosters a collaborative atmosphere of give and take while holding firm to a carefully-crafted and evolving product vision. This responsibility goes well beyond inventorying potential features.
Not Empowered to Make Decisions
The most glaring characteristic of ineffective POs is that they are often not empowered to make product decisions. This goes back to the earlier point about POs playing a proxy role. In this case, the proxy role is between the actual decision maker(s) and the Scrum Team.
If the PO does not “own” the product vision, someone else does. Often, organizations cede ownership of the product vision to development teams. This is a dangerous situation in any Scrum project because Scrum/Agile projects are primarily scope driven. Without guidance, development teams implement what they think is important and necessary in ways that are most obvious and straightforward to them. This leads to disconnects between what teams implement and the needs of the Stakeholder Community. It also makes it difficult to determine the business or mission value of released capabilities and when capabilities are complete.
Conclusion
The PO brings together people, technology, and processes to develop valuable software capabilities. A product is far more than a collection of related features.
In Scrum, the product is the result of continual verification, validation, and evaluation of increments of capability delivered iteratively. The product evolves cross increments and iterations/sprints based on an evolving product vision informed by input from the Stakeholder Community, development teams, and real-life results/outcomes attained.
Effective POs are empowered to lead product direction, possess enough business/mission knowledge to guide the Stakeholder Community and Development Team, and have the “soft skills” necessary to foster collaborative discussions about needs and negotiations over product features.
System integration software projects require formal risk management. Here’s how to do it agilely.
Table of Contents
If you work in system integration projects, you have likely wondered how to manage project risks within your organization’s chosen Agile approach. This is a topic seldom discussed in certification courses for Agile-based approaches such as Scrum. The two major reasons for this are:
Most of these courses focus exclusively on team-level Agile. In other words, how does a small team of individual contributors work together under the Agile approach? Individual small teams tend to work on smaller efforts that require much less coordination. In most of these situations, formalized risk management is overkill.
Managing risk is baked into Agile because Agile is an inherently empirical way of working. Since Agile development is iterative and incremental, teams narrow the scope of what they build to fit within short time frames. This enables them to, quickly and frequently, build, test, fix, deploy, evaluate and change what they build, and how. Every iteration of value delivery brings multiple opportunities to address risk “in real time.” In other words, Agile spreads risk management across the entire development effort.
However, system integration projects are typically large and complex, with multiple teams working across organizations while managing multiple dependencies. The larger the project, the more risk project sponsors and stakeholders assume. A formalized approach to risk management becomes a priority.
So, what does a formalized Agile risk management approach look like? It looks a lot like a traditional risk management approach with three main differences:
Agile risk management is more adaptive than predictive
Agile projects perform risk management activities more frequently and faster than traditional projects
Risk management activities in Agile projects are much more coupled to project execution than in traditional projects
Before describing a formalized Agile risk management approach, let’s level set understanding about project risk management. Along with the short background provided here, I highly recommend reading this article from pmi.org about risk analysis and management.
Risks, Opportunities, and Issues
The third edition of the Project Management Body of Knowledge (PMBOK Guide) defines risk as:
An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.
Project Management Body of Knowledge (PMBOK Guide), Third Edition
By that definition, risks are not just harbingers of negative outcomes. They may also be opportunitiesto affect positive outcomes. Once a negative risk becomes reality, it becomes an issue.
Risk Categories
Categorizing project risks is helpful. Doing so facilitates risk tracking across the entire project scope. It also communicates that risk management is everyone’s job, not just that of project management. Table 1 lists a typical set of project risk categories and their associated extended categories[1]:
Table 1: Typical Project Risk Categories
Risks belonging to the external, organizational, and project management categories are typically:
Closely aligned to high-level project concerns outside the control of development teams
Less dynamic and fluid than technical risks
Almost exclusively in the realm of project and program management and/or product management
Much of Agile literature and training narrowly focus on technical risks. This aligns with their focus on Agile execution by small teams. However, external, organizational, and project management risks often impact projects far more.
The Risk Management Cycle
Figure 1: The Risk Management Cycle
Both traditional and Agile projects execute the activities of the Risk Management Cycle depicted in Figure 1. Table 2 lists and describes each activity of the cycle[2]:
Traditional project management tries to account for all project tasks and milestones upfront. Agile planning breaks up the planning horizon into increments. These increments facilitate changing plans when circumstances change. To be effective, a project’s risk management approach must align to the chosen project management approach.
While all projects, whether they adopt a predictive or adaptive planning approach, perform every activity of the Risk Management Cycle, they emphasize different activities.
A predictive risk management approach emphasizes risk forecasting (prediction) and analysis. Risk analysis entails determining the probability of occurrence and expected project impact of individual risks. The rationale is that the earlier project managers identify and prioritize project risks, the sooner they can address them before they become issues.
An adaptive risk management approach emphasizes keeping risks small by defining, developing, and delivering system functionality iteratively and incrementally. This allows teams to handle risks while their potential for project impact is small and to continually monitor risks as solutions evolve and grow.
Traditional vs. Agile Risk Management Characteristics
I’ll now discuss the key differences between how traditional and Agile projects manage risk.
Traditional Risk Identification and Evaluation
Traditional projects develop and execute detailed plans that span the entire project timeline. Project management often breaks up larger projects into planning packages as part of “rolling wave planning”, but each of those planning packages are themselves detailed plans. Project plans are based on the resources needed to complete the entire scope of deliverables at a certain cost (The Iron Triangle).
Project plans start with requirements definition. The entire set of approved requirements defines project scope. Changes to requirements mean changes to project scope, which translate into schedule and cost changes.
Similarly, traditional risk management tries to identify and evaluate project risks and opportunities prior to or at the start of projects. While risk management is supposed to happen throughout a project’s timeline, traditional projects tend to perform the bulk of Risk Identification and Evaluation upfront.
The problem with this arrangement is that people cannot predict the future. The larger and more complex the project, the more likely project requirements and risks will change.
Traditional project management develops and executes plans assuming requirements, and the design approaches that implement them, are inherently correct and will not change. This opens projects to the greatest risk of all: building the wrong thing.
Risk Identification and Evaluation activities in traditional projects often cannot keep up with the accelerated pace of modern software development. In many organizations, risk management is relegated to weekly or monthly risk management boards. By the time a board adjudicates a risk it may already be an issue.
Agile Risk Identification and Evaluation
While some degree of upfront Risk identification and Evaluation happens in Agile projects, the planning horizon is typically far shorter than that of traditional projects. Also, most Risk Identification and Evaluation of technical risks happen as part of development, rather than resulting from a separate risk management process.
Traditional Risk Handling and Controlling
Traditional (Waterfall) projects typically get one pass through the Software Development Lifecycle (SCLC). That pass is strictly constrained by schedule, resources, and cost. As a result, there is often little room to add risk management activities to the schedule.
Project managers and developers are incentivized to deliver according to plan. This puts pressure on them to ignore risks until they become issues. They also forgo opportunities in favor of “flying the plan.”
Agile Risk Handling and Controlling
The Agile SDLC is fast moving and iterative. Every feature software development teams deliver goes through its own “mini-SDLC”. Agile planning coupled with DevOps automation support this:
Agile provides frequent opportunities to evaluate what development teams build and how
Adaptive planning allows sponsors, stakeholders, and development teams to change requirements, plans, and approaches
Teams add risks to their work backlogs and prioritize them, thus integrating Risk Handling actions into team workflows
Shorter development timeframes with frequent deliveries / releases provide: 1) More frequent and earlier warning of emerging risks; 2) More feedback from which to gauge the effectiveness of risk management efforts
Recommended Approach
The Agile SDLC improves management of technical risks. However, as stated earlier, external, organizational, and project management risks often impact projects far more than technical risks. Agile teams have the flexibility to manage technical scope. They have far less control over funding and major project milestones.
External, organizational, and project management risks influence the overall business or mission context within which teams develop solutions. Project leadership must actively manage these risks before they impact the work of development teams.
Agile projects should leverage traditional risk management tools and techniques to manage more strategic, slower-moving risks. Project leaders would then work with development teams to translate such risks into actionable work items and prioritize them. All project members should have access to risk management reporting and the ability to submit risk candidates as part of their work.
Conclusion
Too often, risk management gets short shrift, especially in Agile projects. Risk management is an integral part of project planning, regardless of the software development approach employed. Combining Agile requirements definition and planning, with DevOps automation, and a robust risk management process helps teams deliver valuable software capabilities, cost-effectively, and in time to be valuable.
[1,2] Lavanya, N., Malarvizhi, T., “Risk Analysis and Management,” Project Management Institute, 3 March 2008, https://www.pmi.org/learning/library/risk-analysis-project-management-7070
Software developers are “creatives.” Most don’t fit the stereotypes of artists, designers, authors, etc. However, even those who typify the hyper-analytical “software engineer” persona crave opportunities to work on projects where they can express their creativity by building great solutions.
Many imagine (and often start) “green field” projects that allow them to do just that. They want to avoid integrating their work with previous (legacy) implementations and accommodating technical and project management constraints. They long for autonomy in deciding what to develop, how, and with what.
Most often, however, this drive for autonomy clashes with the realities of creating successful products and services. Success entails more than writing code. Also, developers, like practically everyone else, expect compensation for their work. Unless the effort is altruistic or some sort of hobby, the needs of sponsors, stakeholders, customers, and users influence what the solution becomes, its development, and the mix of technologies and tools employed.
Every software development project, regardless of the chosen development or project management approach, must address the phases of the software development lifecycle (SDLC) and the constraints of the “Iron Triangle”: Cost, Schedule, and Scope. There is no free lunch.
Figure 1: The Software Development Lifecycle (SDLC)
Balancing Team Autonomy and Project Control
Striking the right balance between development team autonomy and project management control involves aligning software development and project management approaches to deliver the greatest value possible. That balance is different for every organization and project.
Before Agile, the need to subordinate software development practice to the needs of project management was an unquestioned assumption. Documentation and processes that supported project planning masqueraded as engineering or technical artifacts. It did not matter that those detailed requirements, design documents, and development plans became obsolete doorstops soon after development started. What mattered was that they provided information with which to create management plans, schedules, and budgets.
Two major factors opened the door to experimentation with iterative and incremental software development and delivery. The first was the decades-long track record of failure amassed by traditional software projects in delivering complete solutions on time, within budget, and at expected levels of quality. The second was the impact of technological advances that flipped the cost differential between computer memory and employees (i.e., employees became more expensive than computing resources).
Differences between Software Development Approaches
We now have multiple software development approaches to choose from. Each balances team autonomy vs. management control differently based primarily on how they address the following priorities:
Adaptive vs. Predictive Planning
Tactical vs. Strategic Focus
Innovation, Flexibility, and Speed vs. Control and Risk Avoidance
Iterative and Incremental Delivery vs. “Big Bang” Delivery
Figure 2: Spectrum of Software Development Approaches
Adaptive vs. Predictive Planning
Figure 2 above depicts some of the most common software development approaches on a spectrum, from most adaptive on the left side to most predictive on the right side. On the adaptive extreme (cowboy coding):
Little to no planning occurs prior to or during the project
Developers execute project activities in an ad hoc fashion, based on their own judgement and project needs, rather than following a deliberate plan
They have a free hand in choosing what they develop, design approaches, technologies, tools, etc.
As we move from left to right on Figure 2, software development and program management process overhead increase. So does the amount of planning done prior to software development.
As Figure 2 depicts, planners have latitude in tailoring and implementing software development approaches. Different choices yield different amounts of process burden and upfront planning. Ultimately, project and technical constraints and circumstances shape the implementation of all software development approaches.
On the predictive extreme, project activities are tightly coordinated and sequenced based on plans that encompass the entire development project, from requirements definition to release.
Rather than performing most project planning during the Planning and Analysis phases of the SDLC, Agile spreads planning across its entirety. Agile software development executes SDLC activities as one integrated flow of work that grows and evolves solutions iteratively and incrementally.
Tactical vs. Strategic Focus
As we move across the software development approaches, from left to right, solution alignment with organizational strategic aims increases. This is because predictive software development approaches are typically top-down in nature. Adaptive development projects are more closely aligned with short-term tactical goals and deliver capabilities in smaller increments than predictive development projects.
Alignment between strategic and tactical imperatives is possible and necessary for both predictive and adaptive approaches. However, the inherent top-down vs. bottom-up nature of predictive vs. adaptive planning results in very different ways of achieving strategic and tactical alignment.
Innovation, Flexibility, and Speed vs. Control and Risk Avoidance
Choosing the right software development approach also depends on project sponsor and stakeholder priorities. Projects best suited for an adaptive development approach prize innovation, flexibility, and speed. Predictive software development approaches are most appropriate in organizations seeking to enforce top-down control and avoid risk.
The nature of a project’s technology and business/mission domains also influences choices between software development approaches. Projects best suited for a predictive approaches:
Have stable and well-understood technology and business domains
Standard and routine solution approaches
Project staff experienced in delivering systems of similar size and scope
An adaptive software development approach is best for innovative (non-routine) technical projects and for projects that require ongoing refinement and experimentation to arrive at the most optimal solution.
Some software projects in regulated industries or government may require predictive software development approaches. Regulatory oversight increases the need for program management control and risk avoidance. Most software system development projects do not require that level of oversight and control, thus making them likely candidates for adaptive software development approaches.
Iterative and Incremental Delivery vs. “Big Bang” Delivery
Another defining feature of software development approaches is whether they deliver capabilities iteratively and incrementally or as monolithic “Big Bang” releases. While most organizations deliver software solutions incrementally across multiple releases, many develop large increments of capability over months or years. Such release increments are essentially Spiral or serial Waterfall projects.
Iterative and incremental SDLC approaches, like Agile, increase the frequency of releases and shorten the time between them considerably. For example, software teams that employ Agile approaches such as Extreme Programming (XP) and Scrum develop release candidates every two to four weeks. Smaller, more frequent releases lower risk and provide more opportunities to align solutions to current business/mission, organizational, and technical circumstances.
Conclusion
Control is a vital element of agility. Accelerating the pace of software delivery requires some degree of control and flexibility. Overemphasizing control slows software development and decreases flexibility. Underemphasizing control can turn flexibility into chaos, robbing software development teams of both planning and process stability, thereby slowing progress.
The term “Cowboy Coder” is a pejorative for a reason. Developing functionality without disciplined technical and project management processes leads to low-quality implementations and project failure. It also makes it harder to align solutions to market, business, mission, and oversight requirements.
The opposite extreme is ill suited for most software development efforts. Most software development efforts do not need the amount of process and documentation overhead Waterfall software development brings. In fact, the predictive planning necessary to carry out Waterfall process and documentation runs counter to the way modern software systems are developed.
Software development teams must not ignore project and technical constraints. Nor should they try to address every constraint and risk prior to development. Instead, they should leverage them to create better solutions through inspection and adaptation, iterative and incremental development and release, and adaptive planning.
Agile Cheetah just added a YouTube channel to our list of platforms. This is another way for us to share knowledge about Agile, DevOps, and organizational agility.
You can subscribe to the channel directly from the watermark link in lower right-hand corner of the video below. Visit the channel and don’t forget to like the video and click on the notification bell to ensure you don’t miss future videos!
