Says who? Last year we captured key success factors from hundreds of organizations wanting to create High Performing DevOps Teams. These success factors came from teams who participated in the Phoenix Project simulation as part of their DevOps journey.
Some of these organizations were starting up and used the simulation to explore what DevOps is and what it would mean to their organizations. Others used the simulation to support their DevOps courseware offerings, helping to translate theory into practice.
The majority of the simulations were used to help create ‘Effective Communication and Collaboration skills,’ and to foster a culture of ‘Continual Learning and Improvement.’ Throughout the year we produced many articles revealing success factors regarding communication, collaboration, culture, and leadership.
However, creating truly High Performing DevOps Teams starts with active Product Ownership. My blog focuses on the role of the Product Owner. Why this focus? Many organizations say ‘We already have Product Owners,’ yet at the DevOps Enterprise Summit in Las Vegas in 2018, the Product Owner role was one of the named ‘challenges’ of delegates. Industry experts also stressed the need to shift from a ‘feature’ focus to an ‘outcome’ focus, as well the need to develop an end-to-end value stream comprising of Biz+Dev+Ops, not just a narrow Dev+Ops focus.
In this blog, I will describe some key learning points and takeaways from hundreds of teams, including many Product Owners, and relate these learning points to the ‘DASA DevOps Product Owner’ (DDPO) certification program for improving the role of the Product Owner.
Envisioning the Product
One of the Syllabus areas in the DDPO program is ‘Envisioning the Product’ which includes ‘Use Business Value and ROI to Make Strategic Decisions.’ That relates to an important discovery by teams in the simulation workshop. What is Business value? I will use the Value Flow Framework from TaskTop to identify the items that flow through the DevOps value stream. Defined as ‘Features,’ “Defects,’ ‘Risks’ and ‘Debts.’ These items either ‘create value,’ such as a feature to ‘Increase Productivity,’ or can cause ‘value leakage’ such as a defect that can ‘Damage Reputation and Customer Loyalty.’ An important responsibility for a High Performing Team is effective prioritization around ‘Business Value Optimization,’ which is one of the Knowledge areas in the DASA Team Competence Model.
Prioritizing work is a common issue for teams in the simulation, one that teams struggle with in reality. Balancing scarce resources and work-in-progress limits, between features, defects, technical debt as well as risks is a challenge. Often Product Owner KPI’s are focused around ‘features,’ while operations KPI’s are focused around minimizing incidents and outages caused by ‘defects,’ meanwhile, security officers are concerned about ‘risks’ associated with compliance, privacy issues, and data leakage. Architects are concerned about another aspect of ‘debt’ such as legacy solutions and tightly coupled systems. As if this isn’t enough to give the Product Owner a headache there is another type of ‘debt’ – Improvement work – or ‘impediments’ (improving the way of working, improving automation, improving testing, removing waste, removing barriers and constraints). This type of improvement work also needs to be made visible and included in the backlog and the decisions on prioritizing work.
The product owner insisting on ‘Features’
Is the Product owner able to balance all these conflicting Stakeholder demands and make the call? As several Product Owners admitted to me “my budget is for ‘new features” not resolving incidents, that budget comes from Operations”! – Which means that some Product Owners do not see defects nor the impact on end-user experience and satisfaction as a priority. Many Product Owners do not see this balance as their responsibility. Often there is role confusion between the Product Owner, the Scrum Master, the Service Delivery Manager.
“The Product Owner is the Sole Person Responsible for Managing the Product Backlog.”
However, the “DASA DevOps Product Owner whitepaper” (DDPO) clearly states the Product Owner is not just responsible for prioritizing the development backlog anymore. All of a sudden, incidents and managing the performance of the product in production get added to the mix. The Product Owner does not just need to understand the market well, he or she also need to continuously engage with users to know if the product is performing well. This is indeed a mindset shift for many Product Owners we encounter in our simulation workshops.
This need to ‘continuously engage with users’ underpins another significant trend driving Digital Transformation – ‘Customer experience.’ This trend has also prompted new experiments and initiatives such as ‘Experience Level Agreements’ or XLA’s to enhance or perhaps even replace traditional SLA’s. Customer experience must factor into our equations for ‘Business Value Optimization.’
Maximizing Value
As can be seen above there are many stakeholders involved in the value side of ‘High Performing DevOps Teams.’ The DDPO Syllabus area ‘Maximize Value’ looks at ‘Engaging Stakeholders’ and ‘Influencing Stakeholders.’
“The Phoenix Project Simulation provides an ideal way to both engage and influence stakeholders from the end-to-end value stream, and to also have them understand and respect the role and mandate of the Product Owner.”
To maximize value, Product Owners need to help teams understand the ‘Impact of defects,’ sometimes ITSM processes such as Incident and problem management can identify the impact (regarding the volume of incidents, reduction in Customer Satisfaction (CSAT) caused by disruptions and defects, loss of end-user productivity and availability). Unfortunately, this information is not always included in retrospectives or stand-ups when prioritization of work takes place. However, an even more worrying situation is the fact that often Product Owners are not aware of the real downstream impact concerning ‘Customer experience’ nor the actual business impact of defects, risks, and debt because it not seen as part of their responsibility!
Regarding “Influencing Stakeholders,” it is interesting to see what happens whenever we deploy a ‘stand-up’ or ‘retrospective’ in the simulation. What level of “authority” is claimed or given to the Product Owner? Is the Product Owner part of the team or kept on the periphery? Does the Product Owner “throw a new feature onto the backlog” and wait until it has been delivered or does the Product Owner help prioritize the full spectrum of items on the backlog, relying on feedback from operations and other stakeholders?” It is also interesting to see how the various stakeholders prioritize work. Are they focused on maximizing value or simply focusing on their own individual KPI’s? “Just like reality” declared one delegate “Prioritization by whoever shouts the loudest, as opposed to maximizing business value.”
When a Product Owner is not responsible for managing the whole backlog, concerning strategic goals, then this means that decision making can be ineffective, based upon individual preferences and assumptions, causing a sub-optimization of value! Which could perhaps partly explain why the results of a survey released in January 2017 by F5 of approximately 2,200 IT Executives and Industry Professionals found “that only one in five surveyed thought DevOps had a strategic impact on their organization despite the rise in usage”.
Translating Value
When value is fully understood a High Performing DevOps Team must then be able to translate the value into their work items. “Translating Value” is the Syllabus area that looks at the ‘Product Backlog’ which includes ‘Technical Debt’ and the ‘Impediments List.’
This Syllabus area also looks at ‘Creating the Sprint Backlog’ and the ‘Definition of Done.’ An interesting discussion always occurs around the question of “when is work is done“?
Is work done when the feature has been coded and committed (code to commit)? When the code and the infrastructure has been deployed and accepted by users (in live production)? Or when the original business case value has been realized (Idea to value)? The majority of teams conclude “code to commit” (or ‘code to cloud’) or “in production.” This concept represents one of the biggest challenges signaled at the 2018 DevOps Enterprise Summit. A need to shift from “features” to “outcomes” to an end-to-end value stream of “idea to value.”
Defining value up-front as part of the “Business Analysis” is critical to ensure this value flows through the complete value stream and ensuring that the end consumers get the intended value. Another important discovery is the need to shift testing left, to help ensure that ‘quality is built in’ to reduce the risk of downstream value leakage, which raises the need for Testers to work closely with Product Owners on ‘Test Driven Development’ or as some organizations are exploring ‘Behavior Driven Development’ to maximize value.
Delivering Value
Ultimately the definition of any High Performing DevOps Team must be its ability to deliver value. In the DASA DevOps PO Syllabus section on “Delivering Value,” it looks at ways to manage the work and to ensure that the right work is being done to deliver value, covering items such as “Kanban Boards”, “Team backlog” and “Calculating the velocity of the team.”
Another critical discovery and takeaway from the simulation. When Product Owners realize the need to focus prioritization of scarce resources between Features, Defects, Risks and Debts and the need to manage value delivery they recognize a need to gain “situational awareness” in order to make effective decisions. “What are the items that are on the backlog”? “What is the team working on”? “How do these map back to strategic goals”? ‘If there are resource conflicts, which has the highest priority based on “value creation versus value leakage”? It’s when the complete end-to-end team discovers the importance of a Visual Management System (VMS) such as a KanBan board, and how it helps them to understand work-in-progress, how to limit this, and how to use the board to identify and remove constraints to improve the velocity of the team. Bringing us back to where we started “Use Business Value and ROI to Make Strategic Decisions.”
DASA DevOps Product Owner
As we have seen above a High Performing DevOps team relies upon the role of the Product Owner and the way this role is functions. The “DASA DevOps Product Owner” certification program supports the competence development of Product Owners. The DASA DevOps Professional Development certification (Specify and Verify) can fortify the DASA DevOps PO because it builds the capabilities to become proficient in the following four DASA Knowledge Areas: Business Value Optimization, Business Analysis, Architecture & Design, and Test Specification. These areas are focused on ensuring that the requirements of the customers are fully understood and translated into the team and integrated into the IT service.
The area of Business Value Optimization is an area that was a key challenge named by delegates at the DevOps Enterprise Summit and the subject of a DASA Whitepaper “The Business Value of DevOps”.
As I described earlier, the Phoenix Project Simulation exercise is an excellent way of exploring together with end-to-end stakeholders the role of the Product Owner is helping create High Performing DevOps Team capabilities.
DASA DevOps Product Owner
Help realise maximum business value, engage with stakeholders, and deal with future requirements as well as operational challenges.
