Wednesday, July 31, 2013
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.