15 things a Professional Scrum Product Owner (PSPO) actually does

15 things a Professional Scrum Product Owner (PSPO) actually does

PSPO_jpeg

The Product Owners – Steve Jobs and Jeff Bezos

  1. The Professional Scrum Product Owner (PSPO) is an Entrepreneur – a value Maximizer & Optimizer
  2. The PSPO sets a solid vision to help the Scrum Team keep laser sharped focus and direction that helps with incremental progress at the end of each sprint
  3. 1 Product == 1 Product Backlog == 1 Product Owner. Having one PSPO for the product helps with the clarity & focus, ensures quick decision making, and single person accountability for the success of the product.
  4. To validate the idea the PSPO frequently releases the increment of software to market to gain real customer insights
  5. The PSPO has the final say on the order of the Product Backlog. The PSPO orders the PBIs in the product backlog by keeping the Value of the PBI, the dependencies between PBIs and the dependencies on the other products in mind.
  6. The PSPO ensures that most valuable functionality is generated all times by the Development Team.
  7. The PSPO accounts for the Return on Investment and Total Cost of Ownership before a feature is built.
  8. The PSPO ensures that all work done by the Development Team originate from the single Product Backlog – a single source of truth.
  9. To determine the value of the product being delivered the PSPO might use metrics like time to market (cycle time / lead time), percentage of the functionality in the released product used by the customers & the overall customer satisfaction
  10. The PSPO is accountable for Interacting and engaging with the Stakeholders.
  11. The PSPO comes to the Sprint planning with a clear business objective in mind and works with the Development Team to craft a sprint goal based upon the forecast
  12. During the actual Sprint the PSPO is accountable for the Product Backlog Refinement, but may delegate the work to the Development Team.
  13. The PSPO  is the only one who can abnormally terminate the Sprint in case the Sprint goal becomes obsolete.
  14. The PSPO Is just one person and not a committee
  15. The PSPO builds trust by closely working with Development Teams. He is not hesitant to delegate the work of writing user stories / Product Backlog items to the Development Team.

The various levels of Services in the 3 Scrum Roles

The 3 Scrum Roles are:

  • The Product Owner
  • The Scrum Master
  • The Development team

The various levels of services in the Scrum roles are:

  • Scrum Master serves the Development Team
  • Development Team serves the Product Owner
  • Product Owner serves the stakeholders.

The accountability of the the various roles are:

  • Product Owner is accountable for the value being delivered.
  • Scrum Master is accountable for building High performing Scrum Teams by ruthlessly removing impediments and facilitating Development Team decisions. And the best way a Scrum Master can remove impediments is to empower/teach/coach the Development Team to remove them themselves. Only if the team is stuck the Scrum Master removes the impediments himself.
  • Development Team manages itself and is accountable to build a releasable increment of software that adheres to their agreed ‘Done’ at the end of every sprint

Feedback on the Professional Scrum Foundations workshop

This video captures the feedback from the students on the Professional Scrum Foundation workshop facilitated in India. The students share their learnings on how writing granular user stories, story splitting, defining clear Scrum roles helps with agility. They talk about values and principles like self-organization, empowerment, Courage and Respect needed to embrace Agility. They also talk about the interactive and intensive, hands-on and powerpoint free facilitation of this PSF workshop.

My 10 Days of Agile| Scrum Adoption at LULU

The Agile Adoption Strategy used at LULU included Agile Readiness Assessment, The Scrum | Agile Training,  Story writing workshops, Distributed team Alignment, Re-structuring, Facilitating a Sprint, Team Building Activities, and open workshop.

Scaled Professional Scrum & Nexus – Feedback

The feedback is for the Scaled Professional Scrum workshop from Scrum.org that  I facilitated in Mumbai on January 9th and January 10th.

The feedback is given by Parag Barve, Ajay Solanki, Prasad Kamath and Syed Ali.





Interview on Distributed Agile, Lean and Transformation

Summary

In this video Hugo Messer is interviewing me on what is my understanding on ‘Agile Transformation’, The Distributed Agile Adoption, the different and varied approaches to Agile adoption, and the Remote Scrum Training I facilitated between 2 continents – Europe and Asia.

 

Can the Manufacturing industry (non-software) embrace Scrum?

Yes, the manufacturing industry can not only embrace scrum, but also reap all the benefits Scrum has to offer and I had the privilege to work with one of the largest Garment Manufacturers and exporters on their Agile journey.

The software development falls in complex domain and so does the garment manufacturing industry. The 3 major domains in which changes happen and that is similar to software development are

  1. Changing Requirements: It is very difficult to predict what the customer wants. the Fit, the Trims, the Fabric, the pattern & style etc.
    Source: Ralph Stacey, University of Hertfordshire

    Source: Ralph Stacey, University of Hertfordshire

  2. Technological changes: Faster and faster automated fabric cutting and sewing machines are available all the times.
  3. People: The entire garment manufacturing process is based on people and skills. It is heavily dependent on specialized skills & their availability

I was surprised by the fact that in bulk manufacturing a trouser changes 70 different hands before it’s ready to be shipped and a jacket changes over 120 different hands before it is ready to be shipped.

The organization wanted to move to scrum for following reasons:

  1. Improve communication and collaboration between different units.
  2. Improve the overall customer satisfaction and be more predictable with their shipment.
  3. Improve the overall discipline and have a standardized process across the organization.
  4. Improve time to market – across their different areas of Product Development (R&D), Pre-production and Production
  5. Improve transparency between various function, improve their team morale, work in Teams with a clear focus towards organizational vision and mission statement.
  6. Quick decision making, self-organizing, empowered and highly motivated teams

The Adoption was done in 3 stages and I am including a snippet of the video

  1. Assessment to baseline where they are. What is working for them and what are their pain points
  2. Scrum Training – educating participants on Scrum through plenty of exercises
  3. Team formation and sprinting

Culture Change – An important ingredient for organizational Agility

To imbibe Agility in an organization which is a state of high responsiveness, speed, and adaptiveness organizations should promote a new organizational culture of openness, transparency, respect for people, constant learning, improving, and constant adaptation. Even with so much of awareness, cultural change seems to be one of the major hurdles impeding organization’s success.

Culture is more about “The ideas, customs, and social behavior of a particular people or society.” When an individual behaves in a particular way, we associate that to be his nature, but when a team or an organization responds, we relate to its culture. As this is associated with people and their entrenched culture it is very difficult to change!! While it is also a very common observation that the culture within the same organization varies across various geographies. It’s not uncommon to hear statements like that’s the UK Culture, or the US Culture, or the Indian Culture, etc.

When a team/group of cross-functional individuals work together (co-exist and collaborate) for a long period of time in the same organization by respecting and following certain organizational values; they display a unique identity of that group forming their culture. And when we address the culture exhibited by all the teams in an organization it is referred to as the organization culture. If you observe carefully, culture is not the characteristic of one individual but of the team/organization as a whole.

I recollect one of my consulting experiences where I was hired as a coach in one of the organizations that had been practicing Agile for a while, but their adoption was stalled. Although from the outset they seemed to follow all the Agile best practices, they were still struggling with the deliveries and their team motivation was at a all time low. One of the first things I did was to probe the teams by facilitating Anonymous Retrospectives to generate insights. It was quite revealing to find that the organization had a “Culture of Fear”; fear of getting penalized for a decision going wrong, fear failure to meet the commitments, fear of poor quality deliverable, fear to be completely honest and transparent, fear to challenge the status-quo, fear of lack of trust and respect among people, etc. This culture of fear in the organization did not allow Agile to penetrate beyond the surface. Once these insights were shared with the organization, they embraced and acknowledged the shortcomings and worked towards corrective practices to remove the fear thereby imbibing the “Culture of Agility” in the organization.

Organization culture contributes significantly towards successful Agile adoption and therefore understanding it is the key. Management, executives, and team members should support and embrace this change. Invest in a few prominent agility attributes like the healthy team dynamics of self-organization teams, continuous improvement, frequent delivery, effective communication, adapting to the changing environment, etc. that benefits an organization and its customers. To bring culture shift, organizations must examine its existing practices with a critical eye, try new way of doing things, create new opportunities, coupled with commitment and nurturing at all levels within an organization.

Organizations which have traversed through the Agile adoption culture change journey exhibit some of these characters:

  • Team members demonstrate values like Trust, Respect, Courage, Openness, Confidence, Synergy, Unity, Affiliation,and Commitment.
  • Creativity, Collaboration, Emergence, Rhythm, Empiricism, and Discovery are encouraged organization-wide.
  • Embracing Transparency, Inspection, and Adaptation as part of everyday routine.

Embedding cultural shift involves a lot of patience, a full top-down support, constant learning, and a bottom-up intelligence. While an organization may follow all the bookish guidelines and yet fail in this journey if they cannot identify this subtle/invisible ingredient of “culture” which plays a substantial role. Focusing on the correct culture, eventually leads an organization towards success in this transformation path!!

A scaled scrum tactic – Team of Teams, A real life example

A program team of over 40 people decided to move to Agile from their traditional development practices. The program was old and had been in existence for over 6 years. In these 6 years they had released multiple versions of their software product to their customers. In the rush to satisfy the customers they had ignored the basic hygiene of following the good engineering best practices. So, along with their move to Agile they had also inherited a considerably poorly maintained legacy code. There was tight coupling between the various software components in the entire system; The majority of  the code files had 10000+ lines of code with plenty of code duplication; there was poor technical documentation on how the overall system interacted; the entire testing effort was manual. There were certain components which when modified, in most instances, introduced regressions in the existing system.  Even though the teams spent significant time testing the entire end-to-end system, the overall confidence on the quality of the deliverable was considerably low.

The program formed 4 cross-functional Scrum Teams and started sprinting. The dysfunctions from the poorly maintained legacy code started surfacing and becoming more evident.The teams struggled to meet their planned sprint forecast. The development team’s time spent testing the new features was exponentially higher than it took to build those features. In addition, most of the times the development teams kept busy fixing unplanned production defects to maintain the business continuity. The deliveries of new business features were at an all time low which made the sponsors very anxious. The scrum teams collaborated, brainstormed and came to a common conclusion that to accelerate product delivery, one of the first steps was to reduce the manual test effort spent by the development teams. They decided to write end-to-end automated service level tests to cut down the time teams spent on manual testing as well as to gain enough confidence in their deliveries. The product owner helped by ordering the PBIs for the service level automated tests higher in the product backlog. The skill-sets required to develop the service level tests were spread across multiple scrum teams. Something different had to be thought of to overcome the above challenge without having a major impact on the business continuity. A new scaled scrum tactic of “Team of Teams” was introduced: “Team of Teams” is a concept where members with the right skill-set from the existing scrum teams participate to form a new Scrum team for a short duration of a sprint or 2 to solve a very focused problem. The 4 Scrum Teams self-organized and quickly identified 2 development engineers from each team with the correct skill-set to participate in the new “Team of Teams”.

One of the Scrum Masters from the existing teams volunteered to help with Scrum Master duties for the newly formed Scrum team. The new “Team of Teams” decided to operate in “Boot Camp” mode and they co-located themselves in a conference room to allow maximum collaboration. In the first few days of the sprint, the team carved out a homegrown test framework and added a couple of end-to-end tests to validate the framework. A quick review of the framework with the original 4 scrum teams and the Product owner validated their hypothesis. The newly formed team of teams worked through their sprint backlog and carved out 17 rich test scenarios in that sprint. The “Team of Teams” had accomplished their mission of writing sufficient automated test scenarios to reduce the manual testing effort thereby accelerating the product delivery. The team members from the newly formed team of teams then returned back to their original scrum team where they continued to build additional test scenarios. Having led many Agile adoptions across multiple organizations, I have found scaling tactic like “team of teams” to be very helpful when a very focused problem has to be addressed.  The “Team of Teams” tactic has also been explored for strategizing the product vision and the product backlog refinement with multiple scrum teams and overall the outcome has been quite rewarding. I would be happy to hear some scaling tactics you have used and learn from your experiences.

1 2 3 4 6
×
×