ITWales.com
Agile Project Management with Scrum
By Dafydd Rees
What is Scrum?
Scrum is a project management technique based on the principles of agile development. In this context,
agile
means responding to change - both technological change and changes in requirements perhaps due to customer demand and market opportunities. Traditional software project management
techniques have tended to concentrate on "command and control" methods, where an elaborate plan is created and fixed during the inception of the project. In reality this elaborate plan won't survive
first contact with the customer or the first week of programming. A "command and control" approach makes the implicit assumption that the relationship between the inputs and outputs of a software
development process are stable and predictable and that the schedule of outputs will still be relevant by the time they appear. Scrum accepts the fact that things are going to change and takes an
empirical approach.
An introduction to another agile method can be found in the IT Wales feature "Extreme Programming Demystified". Although Scrum and Extreme Programming ("XP" ) are both loosely termed "agile
methods" XP is concerned with the technical details of programming whereas Scrum is about the management of product development teams. For example, XP requires programmers to do "test-first"
development and work in pairs on all production code. On the other hand, Scrum doesn't mandate actual programming practices. As a management technique, it's far more concerned with team
organisation, division of responsibility between the parties involved and planning of work.
In Scrum work is delivered in monthly "sprints". Each sprint delivers a single, usable piece of work called the "product increment". This product increment is immediately available for evaluation and
use by the customer at the end of a sprint. Projects managed in a "command and control" style often have an infrequent release schedule. This can result in a gulf between customer expectations and
reality. Scrum requires these predictable, frequent releases to ground customer expectations on demonstrated, working code rather than the false comfort of forecasts and reports. Short of an
emergency, stakeholders aren't allowed to approach developers formally or informally with requests to do additional work during a sprint. This gives the development team enough stability to be able to
complete a product increment without being distracted by the noise of external disruptions.
Scrum requires that all feature requests be held by a single "product owner". This person is responsible for maintaining the list of features requiring work. This list is called the "product backlog". For
diplomatic reasons, the product owner can't refuse to add new requests to the product backlog. The product backlog is prioritised by the stakeholders, so very low-value items can be postponed
indefinitely, or until the business terminates the project because the estimated return on the remaining backlog items is less than the cost of the next sprint.
Scrum in practice
The product backlog needs to be prioritised. This prioritisation takes into consideration cost estimates. Each backlog item will have a cost estimate assigned by the development team. Cost estimates
are written in notional units of effort. At Wireless Data Services Ltd, we call these "craft units", and they correspond to one small, check-in of working code. We work roughly on the assumption that
there are eight small check-ins per day. Our internal customers are required to state the business value of each product backlog item in pounds sterling. The combination of a sales value and an
estimated cost allows the business to prioritise backlog items.
Sprint planning meetings establish the backlog items to be delivered by the next sprint. The developers, the product owner and the stakeholders attend the sprint planning meeting. The development
team attend to estimate and to agree on an achievable team commitment for the sprint. This meeting is also often used to demonstrate the product increment from the last sprint.
After the sprint planning meeting, the development team must break the sprint backlog items down into a series of tasks. Individual tasks are typically between one and sixteen craft units. (Very
roughly, that's between about an eighth of a working day and two days.) This work is done in a meeting following the planning meeting with the stakeholders. This is high-level design work performed
collectively by the whole team. Scrum project managers are called "Scrum masters" and adopt a different role in the process. Although project managers may well be present at this meeting, in scrum
they influence and facilitate rather than command development. In this meeting they may be present to ensure the scrum rules are being followed and to encourage self-organisation by the team. In
some cases, Scrum masters have been known to sit in a room with the developers in silence until they realise that no one's going to tell them what to do, and that they have to work it out for
themselves.
Given a sprint backlog of work to be done in the month and a detailed, costed list of tasks to be done the team can start work. Rather than measuring work done, scrum accepts the fact that new
tasks may be uncovered after the work has commenced. This is one of the reasons that sprints are monitored in terms of
work remaining
rather than
work done
. Each day a spreadsheet is updated with the current work remaining. Scrum uses "burn-down" charts to monitor progress during a sprint. In a burn-down chart, remaining work is plotted on the Y axis,
and time proceeds along the X axis. As tasks are completed, the line slopes down. Revelation of new work appears as a slope upwards. Burn down charts provide an intuitive feel for the progress of a
sprint. The most common burn down chart "signature" is a steady decline, followed by a sharp rise as more work is found, and then a slope down towards the sprint completion date as scope has been
renegotiated with the stakeholders.
Here we can see a burn down chart where increased work was found on day 7 and 8, and the stakeholders agreed to cut scope on day 12 to meet the sprint completion date. (No work was done on
day 15 as it was a public holiday.) Using this chart allowed the developers and the stakeholders to judge whether the sprint would deliver the product increment on time based on the downward
gradient of the line. After the new work discovery, stakeholders chose to reduce scope to meet the deadline rather than extending the sprint to bring in all the work in the sprint commitment.
Chickens, Pigs and Developers
Every day, the entire team must meet at the same time in the same place to attend a "stand-up meeting". This meeting is intended to be short and action-oriented. It should last no longer than fifteen
minutes. The developers all stand in a circle and in turn say what they did yesterday, what the impediments were and what they plan to do today. This meeting ensures that everyone on the team
knows what's happening, encourages collaboration on similar tasks and knowledge sharing. Sometimes in large teams, the "daily scrum" can become a real scrum with many developers interruping
each other. One way to fix this is to introduce a "dimbleby". A dimbleby is a token that's passed around the group. Possession of the token signifies that it's the developer's turn to report back.
Anyone may attend a daily scrum but only those committed to deliver the sprint (the developers) may speak. The analogy used is that management are "chickens" and the developers are "pigs". The
chicken can provide food by laying eggs whereas the pig has to die to provide bacon. This means that the pig is committed, whereas the chicken is merely involved. Management are allowed to turn
up to hear about progress but aren't allowed to interfere.
The Scrum master has full authority for removing impediments raised. Some Scrum masters have bought new development servers on expenses to circumvent company bureaucracy. At work, I've seen
one scrum master remove impediments by moving the desk of a distant collaborator into the same room as the developers over lunch.
Closing Remarks
Scrum is a management technique for small, multidisciplinary teams working on product-centric projects. Although much of the work with scrum has come about as a result of software projects, scrum
has been applied in other kinds of projects such as hardware design and for managing exhibitions at a museum.
Although Scrum can be applied in a number of quite different contexts the basics are the same. Calendar month sized "sprints", made up of prioritised work drawn from a product backlog that's kept by
a single person called the "product owner". Having once worked on a project that had more managers than developers I can appreciate the need to give responsibility for the list of requirements to a
single person.
Although estimation is a considerable amount of work, a numerical approach to prioritisation based on cost estimates, and revenue forcasts can help remove a significant amount of corporate politics
from the planning process.
Perhaps the most important thing to remember about Scrum is that it's an empirical process, based on estimation, prioritising, doing, and reflecting on the results. The greatest mistake people make here
is to read about Scrum, and try to implement a modification of it without having first tried to use straight Scrum. At XPDay 2, Ken Schwaber (one of the Scrum pioneers) said that it's important to use agile
methods like Scrum in pure form for a while so that you have a proper baseline from which to improve.
References
Ken Schwaber and Mike Beedle,
Agile Software Development with Scrum
, Prentice Hall, 2001
Ken Schwaber's Scrum Training Website:
http://www.controlchaos.com
About the Author
Dafydd is a software developer specialising in object technology. He welcomes feedback at
http://www.dafydd.net
Home, Services, Events, Features, Interviews, Profiles, Reviews, News, Resources, Press