I managed to read pretty quickly
Agile Project Management with Scrum, so far I've been part of three Scrum projects so it has been almost a revise process and a check if we were implementing Scrum properly or not. In these days I'm also very interested into the relationships in between the major agile processes and Scrum is the most sold (as fair as I know!).
Here my notes taken while reading the book.
Numbers
Scrum (or at least, this book) preaches few numbers quite strictly. Ken Schwaber writes:
All work is done in Sprints. Each Sprint is an iteration of 30 consecutive calendar days.
Sprint planning meetings cannot last longer than eight hours
Optimally, a team should include seven people.
The Sprint retrospective meeting is time-boxed to 3 hours.
Sprint Review Meeting four-hour, time-boxed meeting.
I agree with the number of people in the team, I'm puzzled by all these other numbers. In two projects I've experimented 15 days Sprints, with the result of a big overhead in planning and in retrospectives (at least a day spent every two weeks, it's basically the double of what Ken suggests). In an another project we were having the classic, as in book, 30 days sprint and I found (and I still think) that it's a too long lapse of time for a team to focus on the delivery, to have the perception of its own velocity.
We are humans and the week starts with the "annoying" Monday and it ends with the "finally" Friday, with in the middle the very productive Wednesday. It might be a coincidence (or a consequence of the quality of the team) but I always found the team where I worked more productive when working in weekly iterations.
All those numbers should be then adjusted, divided by four maybe, 2 hours of planning, 1.5 hours retrospective every second iteration.
However Scrum is agile and Ken writes also:
Scrum relies on empirical process control, which in turn is based on frequent inspections and adaptation.
The Team has to learn to manage itself, to constantly adjust its methods in order to optimize its chances of success.
So at the end if you find your team not focused on a 30 days Sprint you might want to try to cut down the size, but keep in mind that you should cut down the time boxed time dedicated to planning, sprint review and process improvement.
I would say,
as we let the design emerge from the code we should let the process emerge.
Scrum and Extreme Programming
I found the best definition of the differences between these two (complementary) methodologies at the end of the book:
Extreme Programming, another Agile process similar to Scrum but more engineering focused and less management focused.
True, XP is a lot about how we code, Scrum is about project management, relationships with the customer, multiple teams interactions.
To get the best of both world just use them together (Scrum alone is rare, especially given its definition of done)
Scrum, combined with Extreme Programming, includes productivity-enhancing practices that increase Team productivity by orders of magnitude.
XP provides many of the engineering practices that Scrum implements to ensure increments of potentially shippable product functionality.
Missing parts
There's no deep description in the book of how to do estimations or how to organize your team wall, actually there's no mention of the wall at all. I guess it's all left to other comprenshive books on the subject, like the Mike Cohn ones.
Funny bits
A couple of funny quotes
I believe that the last “simple” project occurred in 1969, when one person from order processing at Sears
Roebuck asked me to sort some cards and generate a report on an IBM 360/20. Since then, things have only gotten messier.
“I’ll hire a private detective to find Thomas.”
The second one is a strong example on how important is for the scrum master to remove impediments to the team (Thomas was a developer in holidays that left some undone on the project, compromizing the Sprint success)
Organization fit or Organization Transformation
Some companies are more ready to Scrum, some companies will struggle to change, another two lines from the book:
Scrum can’t be learned overnight.
To create visibility in these instances, the ScrumMaster had to adapt Scrum to the organization.
Taking a Scrum Certification after years of Waterfall process will not transform you in a Scrum Master, and sometimes some Organization Trasformation has to be performed in the company before starting the project.
Scrum is a great way to deal with Agile Managment but I'm sure that the two biggest challenges and reasons of failures of Scrum Project are really the two mentioned above.
Common Language
They needed to learn to talk to each other in a common language.
I've realized that Scrum gives to the Scrum Players ( Product Owner, Scrum Master, Team) and also to the stakeholders a common language, some wording, easy to remember that facilitates the communication in between the players. Sounds familiar with Domain Driven Design, but on a process level.
Vision
Vision is something that is quite missing on XP, and it's highly valuable.
The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why
the project is being undertaken and what the desired end state is.
Reestimations
Increasing the accuracy of estimating by comparing actual hours worked to estimated hours worked is a suboptimal measurement.
Comparing what the Team actually produces to a desired release date and release goals is a much more appropriate measurement.
I'm quite keen on this phrase, I've been asked on a couple of projects to re-estimate and I found it quite wasteful, the accuracy of the estimations will be achived Sprint by Sprint, there's no value on re-estimating during the development.
Methaphors
I often compare a ScrumMaster to a sheepdog, responsible for keeping the flock together and the wolves away.
One of the ingredients of Scrum is a practice known as sashimi. Sashimi is a Japanese delicacy consisting of thin slices of
raw fish. Each slice is complete in itself, a complete taste similar to the way every other slice tastes.
Conclusions
It's a good book, it's worth reading it, I particularly like the learn by example pattern and the appendix for those who are less familiar with Scrum.
