Agile Project Management with ScrumBy 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 wont 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 doesnt mandate actual programming practices. As a management technique, its 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 arent 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 cant 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 practiceThe 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, thats 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 ones 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 DevelopersEvery 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 whats 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 thats passed around the group. Possession of the token signifies that its the developers 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 arent 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, Ive seen one scrum master remove impediments by moving the desk of a distant collaborator into the same room as the developers over lunch.
Closing RemarksScrum 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 thats 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 its 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 its important to use agile methods like Scrum in pure form for a while so that you have a proper baseline from which to improve.
ReferencesKen Schwaber and Mike Beedle, Agile Software Development with Scrum , Prentice Hall, 2001
Ken Schwabers Scrum Training Website: http://www.controlchaos.com