Plenty of Anti-Scrum messages in book recommended
Here are some of the anti-scrum messages from the book "Agile Product Management" by Roman Pichler. Unfortunately, it is one of the books recommended by Scrum.org. I wonder how the books are chosen by Scrum.org for recommendations.
1. Encouraging PO to attend Daily Scrum. Experts like Ian clarified that "attend" is different from "participate". However, I don't think Roman used that nuance in describing it that way. Here is the actual excerpt from the boon on that: "As the product owner, you should attend the meeting whenever possible. It’s a great opportunity to understand the progress being made and to see if the team needs help (for instance, you might need to answer questions, review work results, or help remove impediments). You can also share information and update the team on what you have been working on and are planning to do next." It puts PO on equal footing with the team and there is no need for invite to speak
2. Treatment of Scrum Master as a lead. Roman indicates that Scrum Master is needed wherever Development Team is needed. For example, even the definition of done needs to be approved by Scrum Master and he should be present while defining it
3. The need for creation of Sprint Goal before Sprint Planning
4. Roman seems to put the Dev Team as the center of Product Creation. While that happened with Googles and Apples where technology products were developed, that is not the primary model of Product creation. While Scrum allows entire Scrum to contribute to Product Backlog, it still puts the PO as the person who needs to own Product Evolution.
5. Actively recommending to use Sprints like "Vision Sprint" where the outcome is only the documents. Scrum is very clear with each Sprint producing working increment. That is also the requirements from Agile Manifesto too.
6. Missing to indicate that it is mandatory for each PBI to have a value indicator.
7. Use of terms and definitions that are not part of Scrum anymore - release burn-down, commitment, etc.
8. Building complexity into Velocity calculation and forecasting. At one point it appears that there are 'predictive' behaviors in the his version of Scrum
Also, the depth of dealing with PO subject is not good enough.
chenny,
interesting points. I didn't read the book, however here are some thoughts on your anti-scrum messages.
1. Indeed, the PO does not "participate" (answer the 3 questions, update Sprint Backlog etc). Depending on the PO personality and availability, attending the Daily can have positive or negative impact: Positive in the sense of transparency, knowing what's going on, supporting with business insights etc. For a dislocated team the Daily Scrum might be the only opportunity to get in contact for weeks. Negative in the sense of killing self-organization or limiting openness of the Development Team.
2. The Definition of Done is updated by the Scrum Team in the Retrospective. That includes the Scrum Master, however he does not need to "approve" it.
3. The Sprint Planning is the last opportunity to define a Sprint Goal, as well as to estimate Product Backlog Items. I don't see a problem with defining Release and Sprint Goals upfront, as long as they are based on empiricism and not carved in stone. This might be helpful to set stakeholder expectations, get budget, etc.
4. Scrum has a clear separation of concerns: The PO is responsible for the vision and Product Backlog, while the Dev Team turns Product Backlog Items into a done increment. Overlap is only in the process of refining Product Backlog Items. All of these are creative processes, but I think the question who "creates" the product seems rather theoretical. The best products are created in collaboration.
5. I fully agree with you. In my experience this is the most difficult Scrum rule to implement, even Scrum.org itself struggles with it and needs a design sprint: http://www.bluecoda.com/blog/selling-scrum-to-scrum-org
6. Does he talk about value at all? This is a central word in product management - if it is with Scrum or not...
7. Commitment is actually part of Scrum - not of the rules, but of the values. However I think when you write a book of 160 pages it is legit to use more words than those mentioned in the Scrum Guide - it has only 14 pages!
8. It also appeared to me like that in a PSM training from Scrum.org that they had predictive calculations for co-location, number of teams etc. But in a recent course by Gunther Verheyen that was eliminated. Continuous Improvement ;)
I don't have the book, but I think the publication date was 2010. The advice given may have been state-of-the-art at the time, and a reasonable expression of how the framework might have been implemented. However Scrum has moved on since then and that is why the latest version of the Guide is the definitive reference.
Just to be clear, in the web project with BlueCoda, there is NOT a design sprint. Our first sprint goal is to deliver a Home Page and that does include some design activities to meet the goal. You cannot create a home page without design, but the sprint itself is NOT a design sprint.