Chapter 5. The Product Owner

Transcription

1 Chapter 5 The Product Owner

2 ScrumMaster responsibilities Removes barriers between the development team and the Product Owner you want customers to drive the development Shows the Product Owner how to use Scrum to maximize project return on investment (ROI) and meet the project objectives But The customer knows from experience how unlikely it is that the team will deliver a system, much less a system that meets customers (users) needs

3 But also, The team knows from experience that the customer is fickle, always changing his or her mind just when the Team thinks it knows what to build The team and the Product Owner should be constantly collaborating, scheming together about how to get the most value for the business from the selected technologies.

4 Waterfall and the gathering requirements dilemma Developers and manager want assurance Do these req ts that we ve gathered and the models that demonstrate them constitute a full and accurate representation of what you want? Because once you say yes, it will be increasingly expensive for you to change your mind! With contracts what s the need for collaboration?

5 Sashimi ( thin slices of raw fish) Scrum uses the sashimi technique to require that every slice of functionality created by the developers be complete All the req ts gathering and analysis, design work, coding, testing, and documentation that constitute a complete product are required to be completed in every Sprint and demonstrated Models, req ts, internal artifacts might be useful to the developers, but why would you even consider showing they to stakeholders.

6 Sprint Planning & Sprint Review The bookends that initiate and fulfill customer/client/user expectations Sprint Review of the Sprint goal and Product Backlog that was selected Demonstration Review of what had gone right and what had gone wrong Lessons Learned: Face-to-face communication allowed the team to use the Sprint review as a reporting mechanism

7 Key Scrum tactic Sprint Review & next Sprint Planning The process: The team presents the product as it had been recently enhanced The customer/client presents they most pressing needs The team presents its enhancement plans The two groups see whether there is common ground Then ask whether the list represented everyone s most urgent needs and What could be done in during the next Sprint

8 Lessons learned the art of the possible Achieved through direct collaboration between the internal customers and the engineering teams. When people don t get together, face to face, and talk to each other, they often project their problems onto each other.

9 Daily Scrums When team members are not talking to each other They got stuck on problems that someone else could have helped them with By getting team members helping each other on a daily basis the ScrumMaster facilitates the collaboration and consequently the intended quality of the work done.

10 Conclusions The value and need to bring the Product Owner and the Team together to collaborate The result the team and the Product Owner learned to understand each other and not just talk at each other The Product Owner talks in terms of business req ts and objectives and the Team had talks in terms of technology The Product Owner (as well as users) do not (and should not be expected to) talk in terms of the technology An essential ScrumMaster role in teaching the team to talk in terms of business needs and objectives

11 More conclusions and advice ScrumMasters must understand the depths of the language divide that separates customers and developers. Bridging the gap is critical! If both sides cannot speak the same language, collaboration is impossible The Product Owner has no interest in bridging the gap (and shouldn t) and does not have the background to do so Hence, the ScrumMaster must facilitate the team need to bridge the gap