Skip to main content

Plenty of Anti-Scrum messages in book recommended

Last post 01:53 pm March 8, 2016 by Eric Naiburg
3 replies
08:16 am March 2, 2016

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 I wonder how the books are chosen by 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.

09:30 am March 2, 2016

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 itself struggles with it and needs a design sprint:
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 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 ;)

09:56 am March 2, 2016

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.

01:53 pm March 8, 2016

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.