XPday 2006 – An Introduction to Scrum – Joseph Pelrine

What follows are my notes on the XP Day talk given by Joseph Pelrine, on Tuesday 28th November 2006.

Scrum is nothing to do with software, it is to do with managing work.

In any project, requirements, technology & people are all changeable, all come with uncertainty. Scrum can manage and prioritise this complex domain. Joseph pointed to several non-software projects he had managed with Scrum, including his wedding (which was indeed delivered on time and within budget).

The waterfall method assumes requirements do not change during the project, encouraging a tendency to stuff in everything in one go, all at top priority. Scrum looks to not wait for all the requirements, but instead to look to deliver with what is known now.

Waterfall can actually work in manufacturing, you do know your end product, you know what is an acceptable level of waste (although if you look at the Toyota Method of Production you may well see this is not necessarily the best way). When you can’t can’t define things enough so that they run unattended and produce acceptable output, then control is through constant inspection and adjustment. The comparison Joseph made of these two ways was that of the flightplan made by an aircraft, compared to the way in which a large flock of migrating birds move. Apply, inspect, adapt.

Building the Scrum process

Start with a product planning meeting. Plan just enough to drive the first developer sprint to deliver product increment that provides business value. Requirements will emerge as the customer sees product increments. Refactoring of the design and product will cause the system and product architecture to emerge.

Scrum Master

They are responsible for establishing Scrum Practices. They act as a gobetween for management and the development team, and also a coach. A Scrum Master is the agile equivalent of an IT Project Manager. They should be outside of the team, although if the team is too small, the pragmatic approach is to adapt the role to suit.

Daily Scrum Meeting

This ideally should be no more than 15 minutes long, taking place in the same location every day. The aim is that everyone attending answers 3 questions:

What did you do since the last scrum?
What will you do before the next scrum?
Is there anything in your way which will help you achieve what you want to do before the next?

It is the Scrum master’s job to note and then sort any of the impediments raised in the meeting.

Scrum Teams

They are self-organised, with no roles. Responsible for committing to work, and with the authority to do whatever is needed to meet commitment. Almost like the “total footballers” of development. The ideal size is reckoned to be 5-9 people, not too big, not too small.

Product Backlog

This is a list of functionality and technology issues, maintained by the product owner. If there are multiple teams, there should still be only one list. Anyone can contribute to it, be it is the product owner who is responsible for defining what is going to be done, and when. Their decisions in terms of timing come down to their defining if it will be in this sprint, if it may be in the next, or is to be considered further down the line. The combination of the product backlog and the product owner that drives the scrum process.

The Sprint

A 30 day calendar iteration of development. The development team builds functionality that includes the product backlog, and meets the sprint goal. If the sprint should lose meaning along the way, it should be abandoned and restarted with a restated goal. 5-10% of the sprint should be spent researching ahead for the knowledge and information that will be needed to complete it, or further sprints.
The Sprint Planning Meeting

This should consider the following:

Items Processing Action

Product backlog
Team capabilities Review
Business capabilities Consider Implement
Technology stability Organise
Executable product increment

Sprint Burndown

This is a method of charting the progress of the sprint. It is designed to measure results rather than effort, and shows how much of the sprint is left to do each day. Each developer must devote a few minutes each day to updating the burndown.

End of Sprint Review

This is fairly self-explanatory, review the product backlog, and set the next sprint goal in the light of what was achieved in the previous sprint.

So what did I think?

I enjoyed it, very well-presented session. I think that compared to what I have seen of Agile and XP, it is a slightly more formal, heavyweight system. Obviously it has influenced some of the thinking behind both of them as well. It could be easier for a team entrenched in the Waterfall method of development to transition to this way of working, than say jumping across to XP.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.