Agile Project Management with Scrum

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.

Product choices

Recently, on my last project we had to make some product choices (which web server, which application server, etc.).

That’s how I proceeded.

• I wrote down on an a spreadsheet all the key criteria for the product choices.
• I picked up three-four products for each product category.
• I’ve used only three levels of goodness of each product in each category: red = bad, yellow = ok, green = good. All the levels were relative to the other products choices and not absolute.
• We arranged a meeting, discussing the colours on the spreadsheet, at the meeting there was a representative of all the team roles (Scrum Master, Product Owner, some Team members, Architect)
• We cleaned up the spreadsheet and we send it to the client with more information on the suggested products.
• The process was time boxed, it took in total less than two ideal days and it was a task in the project backlog.

That’s how the spreadsheet looked like:

Planning extreme programming

This weekend I’ve managed to read Planning Extreme Programming by Kent Beck & Martin Fowler, I’ve been rather impressed by the book, the first edition is dated  October 2000 so it’s almost 10 years old now, in this post I’ll share some notes  I’ve taken during the reading, mostly related to the similarities with Scrum.

XP population

Kent and Fowler launched a survey on the XP mailing list asking which  size of an iteration was more popular, they got only 37 replies, in these days the list has around 9000 users, with hundreds of messages every week…

Practises

Stand-ups meetings, release planning, iteration planning, concept of done: all well described here.

Have a short meeting once a day so everybody knows what’s going on, and what’s not.

At the end of each iteration, the whole team would gather round and watch the developers demo the work in which each had been involved in the preceding three weeks.

A story is done when the function of that story is demonstrated to the customer and the customer agrees that the functionality substantially fulfils what is expected.

Graphs

There are no burn down or burn up charts, but few graphs are suggested (including Story Progress, does it sounds familiar?)

There’s no backlog but the stories are prioritized and the ones with lower priority put into a drawer.

Wrap future stories with a rubber band and stick
them safely in a drawer.

Pairing

Pairing is mentioned just a couple of times (I’m sure just because is implied), and the first time at half of the book.

Retrospectives

There’s even a first idea of retrospective:

If you have the ceremonial pushing of the acceptance test button
at lunch on the last Friday of the iteration, you can spend the rest of the day talking about your process.

Scrum master

There’s no scrum master, indeed, scrum wasn’t born but the tracker role sounds a lot like the SM one…

This person, the tracker, keeps an eye on which tasks are done and
how much is left on outstanding tasks.

Fine grain tracking

Last but not least there’s a mention to the pomodoro technique:

(Francesco Cirillo told us he bought a half-hour kitchen timer in the shape of a tomato, so they now refer to a “six-tomato task.”)

Conclusions

Great book, it gave me the impression that Scrum just adds some names and defines in a deeper details ideas and practises that have been written  years before.

I’ve just started to read Agile Project Management with Scrum to better understand what Scrum really adds, XP, so far, honestly seems to me more lean than Scrum.