One of the common themes that often
percolate as organizations transition to agile approaches has been the
identification of who owns the product vision. In a traditional project, often
as recommended by Project Management Institute, effective project managers
control the risk related processes as they own the project's scope. With agile thinking, this
burden of responsibility shifts to the product owner because maintaining the
product roadmap (starting with the vision) and grooming the product backlog is the product owner’s
responsibility.
But, one of the common pitfalls that I
believe is a root cause for agile’s implementation failure is the inadequate
orientation of the product owner to be available to do this role. Product backlog
grooming is no longer entry of information in a tool or grid but is a
systematic approach to handling prioritization of events that could positively
or negatively impact the features in a product backlog with an unforgiving focus on business value. When products are designed and developed in vacuum without thinking through how it will be rolled out, this intense focus on business value is no longer on the radar. Depending upon who
plays the product owner role (Business Analyst, Project Manager, Project Manager,
Functional Manager, etc.), the nature of identifying risks morphs so much that agile
projects stumble during its build (any of the releases/sprint) or as they hit the road for clients to consume. So, what are the key steps for a product owner to monitor as they maintain/groom the product backlog?
The first step to monitor the horizon for
events can derail the project. The team can give some input but the onus lies
on product owner to do the SWOT analysis and assess if the risks impact any of
the features. This assessment could actually reveal new features to the backlog even on completed features. Care must be taken not to become too granular in not getting carried
away for risks that impact user stories or tasks to be completed. For instance,
instead of focusing on resource availability in a shared environment that may
impact sprint velocity, focus should be towards eliminating risks that address training for the team to embrace agile, tools and
processes to streamline communication, etc. The hardening iteration (Iteration
0) is a good place to begin this risk assessment.
When avoidance, or withdrawing is not an
option, the second step is, to mitigate the risk. This step involves enforcing
best practice guidelines, using service level agreements, having standard
operating procedures, or leveraging feedback loops to optimize the business
processes. The sprint retrospectives are a good area for product owner that has
assumed the role but not having formal product ideation training within the specific industry. This need necessitates
that the product owner becomes available for the team to gather this information
first-hand through osmotic communication. The more the product owner becomes unreachable, the more this risk assessment
loses accountability leading to failure.
Sometimes, mitigation may not be the best
strategy because of the detailed subject matter expertise involved, or the time
commitments to deliver earlier. For example, consider the translation of voice
and email notifications in foreign languages or consolidating data centers
distributed globally that require specialized skills. In such cases, the third step is transferring the risk to another more informed party (e.g.: outsourcing, consultant, application service provider). Many
best practices from the mitigation strategy will still apply here, but the
focus shifts more on the other responsible party, similar to transferring risk
to an insurance carrier. For a product owner to get familiar with these trends,
a more conscientious awareness of domain knowledge skills and business knowledge
skills become necessary so that the product owner is able to make a case for
the return on investment of continuing to build the product.
When none of the strategies work, the
final and fourth strategy is the acceptance strategy. It is in this stage, the team
absorbs the risk. Yet, the product owner and the team negotiate on how much
velocity can be consumed in that particular iteration if the probability of
risk to materialize is higher. Perhaps that particular iteration should have more “Should do”
and “Could do” features from product backlog and not do any “Must do” features.
Similar to business continuity planning or disaster recovery planning, the
product can proactively select the right mix of user stories for the team to
implement to show progress but protect the team by managing risks.
In summary, the risk management
principles are no longer just a project manager’s toolkit and are the seeds of success for successful agile implementation. They equally extend
to a product owner because in an agile world, quality is non-negotiable as the product
is operationalized and introduced to the customers. In order to embrace change,
risk should also be equally invited and managed proactively. Having a product owner available
to ramp up to speed with the domain knowledge of the operating business and understand
the project risk management principles is inevitable for maintaining the
product backlog, without which the product cannot be sustained.