free scrum book

[RMT]

Free book about scrum
http://www.pashunconsulting.co.uk/freebk/scrumintherealworldebook.html

regards,
Ritesh

[James O Coplien]

> --
> You received this message because you are subscribed to the Google Groups "ScrumNepal" group.
> To post to this group, send email to scrum...@googlegroups.com.
> To unsubscribe from this group, send email to scrumnepal+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scrumnepal?hl=en.


I find it to be more or less O.K. at the level that the author can scrape from the Scrum Guide, but it looks like it could have been written by someone who just took a few weeks to gather stuff off the web and put it together. It clearly doesn't go into the Scrum foundations but is just a surface "blue-pill" articulation of the Scrum "rules."

For example, it says that impediments are removed by the ScrumMaster. No: Kaizen is the job of everyone on the Scrum team.

It also says that the steps in a Sprint are mini-waterfall steps. No: it is like in the Takeuchi and Nonaka paper, with everyone doing everything all the time. It emphasizes the old-style principles of teams comprising domain experts rather than multitalented individuals (it's very explicit about this). It says that the PO directs the team by writing PBIs, rather than advocating the Scrum practice of face-to-face dialog between the PO and the team, using PBIs to document decisions that must be remembered. It makes the classic mistake of over-emphasizing user stories and speaks as though user stories and features were part of Scrum. Neither one is part of Scrum.

It features the Release Burndown as its first artefact. No: there is no release burndown in Scrum. There is a whole chapter on Release Planning, which is not part of Scrum.

It doesn't really tell anything about how to build the Sprint backlog, and talks about the Sprint backlog only as a subset of the Product Backlog. No: the rules for populating the Sprint backlog from the Product Backlog are very particular, and the piece misses the whole activity of design whereby the Sprint backlog is created from the Product Backlog.

The definition of Done is backwards. That the product is shippable doesn't imply "Done." "Done" implies that the product can be shipped. The book nowhere delineates what "Done" is about, and it later suggests that it is something that the team agrees to once, early on, and which is a static standard.

Kaizen is not just about improving practices, as the book says, and certainly not "scrum practices" as it also claims.

After saying that there are no roles other than the Scrum roles the book goes on to talk about the Product Manager (who plays the role of the Product Owner); of the Senior Product Manager (who ostensibly is there to tell the Product Manager what to do); of department heads (there are no department heads in Scrum); marketing managers, team mangers, and lawyers... There is no insight about what these roles do or about why the author included them. It also advocates that a traditional Project Manager play the role of ScrumMaster — something that no one who knew Scrum well would be likely to recommend. In Scrum Foundation, we explicitly recommend against this very practice.

There are many other errors. It says that the team does not commit to the Sprint Goal (it does); in release planning it makes no mention of velocity variance (this is a standard Project Manager failure); it allows "small" amounts of Product Owner interference during the Sprint (none is allowed); the Three Questions for the daily Scrum are individually focused and don't reflect the more current team-focused questions;

[Ritesh Man Tamrakar]

Thanks Cop for pointing out mistakes. We learn more through discussions :)

regards,

Ritesh

[James O Coplien]

On Nov 9, 2012, at 6:01 , Ritesh Man Tamrakar wrote:

Thanks Cope for pointing out mistakes. We learn more through discussions :)

It's much more lean to learn through extensive review prior to publication...