Adaptive Project Management Using Scrum
Craig Murphy, www.craigmurphy.com
Scrum is a lightweight process that can manage and control software and product development: it is a project management process. However, instead of promoting the traditional analysis, design, code, test, deploy "waterfall" approach, Scrum embraces iterative and incremental practices. Similarly, instead of being "artifact-driven", whereby large requirements documents, analysis specifications, design documents, etc. are created, Scrum requires very few artifacts. It concentrates on what’s important: managing a project or writing software that produces business value.
What is Scrum?
The first question that you’ll probably want answered is: is Scrum an acronym for something? You would not be alone in thinking this; most other project management processes and techniques are acronyms. Scrum however is just a name, it’s not an acronym. Similarly, it has very little to do with rugby either, although there is a "daily meeting" that might be compared to a traditional rugby scrum.
Scrum borrows from the "agile" world through its promotion of iterative and incremental practices. It has a simple implementation that is designed to increase productivity and reduce the time it takes to benefit from a software/product development. Importantly, it embraces adaptive and empirical systems development.
That last paragraph introduced two of Scrum’s key facets: adaptive and empirical. The majority of project management methods and techniques are very prescriptive; they tie us down to a fixed sequence of events and offer little in the way of flexibility. Similarly, newer, less mature methods often claim to be a panacea, yet they lack any definitive proof or track history. Fortunately, Scrum is mature; it has a track record going back as far as 1995 and earlier. Similarly, it is scaleable: Scrum can be used on projects of any size. Whilst I will not be discussing it in this article, "Scrum teams" allow Scrum to be used to manage enterprise-level projects.
Scrum also promotes and lends itself to managing eXtreme Programming (XP) based projects. XP uses "customer on site" as a means of ensuring that the development team’s questions are answered but also to ensure that what the development team is producing what the customer actually wants.
The Opposite of Waterfall
Traditionally, we followed a cycle involving requirements gathering, analysis, design, develop, test, deploy with each stage being completed before moving on. This was known as the waterfall approach. Whilst there is a place for the waterfall approach, it has been the subject of a torrent of abuse in recent years. Most notably, the waterfall approach promotes the creation of up-front documentation before any real business value is created. This is confounded by the fact that product development is started downstream, or much later in the project’s expected timeframe. This has the obvious disadvantage of delaying the point at which business value can be realised.
But it gets worse: the customer/user endeavour to ensure that all of their requirements are documented during the early stages, thus the feature set is top-heavy. Failure to prioritise the feature-set often results in low quality systems that are overloaded with features that the customer/user does not actually require in "version 1". Indeed followers of Mary Poppendieck’s work (www.poppendieck.com) will know that "80% of a product’s value comes from 20% of its features".
With this in mind, can we conceivably build a product (a software product) that provides 20% of the feature set? Yes, we can and we do it iteratively. We can deliver "version 1" with 20% of the features, then, a little later, "version 2" with a further collection of features. The beauty of this approach is that development of 20% of the features should not take 100% of the project’s expected schedule and budget: we can realise business value much earlier in the cycle.
Scrum embraces the opposite of the waterfall approach whereby we start working on the analysis as soon as we have some requirements, as soon as we have some analysis we start working on the design, and so on. In other words, we work on small pieces at a time. This approach can be called iterative. Each iteration consists of some requirements gathering, some analysis, some design, some development and some testing culminating in an iterative release cycle (many deployments).
Scrum revolves around the ethos of simplicity, resulting in delivery of something that moves the project forward. It achieves this by proposing the following questions (referred to as Scrum’s three questions).
Fundamental Project Management issue
What have you done during the last 24 hours?
This is progress, it’s work completed to date
What do you plan to do in the next 24 hours?
This is forward planning, it is work you are about to do
What’s stopping you getting on with the work of the next 24 hours?
These are your impediments or obstructions, it might be things you need in order to work… more forward planning. It’s also identification of immediate risks.
Scrum uses three "roles": Product Owner, ScrumMaster and Project Team.
The Product Owner is possibly a Product Manager or Project Sponsor, a member of Marketing or an Internal Customer.
The ScrumMaster is key, he or she "represents management to the project". Such a role usually filled by a Project Manager or Team Leader. They are responsible for enacting Scrum values and practices (more about these shortly). Their main job is to remove impediments, i.e. project issues that might slow down or stop activity that moves the project forward.
The Project Team should consist of between 5-10 members. The team itself should be cross-functional, involving individuals from a multitude of disciplines: QA, Programmers, UI Designers, etc.
"Out of the box" Scrum is best described by Figure 1. Most projects have a list of requirements (type of system, planning items, type of application, development environment, user considerations, etc.) Scrum records requirements in a Product Backlog. Requirements need not be precise nor do they need to be described fully. As with most projects, the requirements are sourced from the expected users or "the business". The Product Owner prioritises the Product Backlog: items of importance to the project/business, i.e. those items that add immediate and significant business value, are bubbled up to the top.
The Project Team responsible for doing the actual work then creates a Sprint Backlog: this comprises of Product Backlog items that they believe can be completed within a 30 day period. The Project Team may liaise with the Product Owner and others in order to expand item(s) on the Sprint Backlog. After 30 days have elapsed, the team should have a "potentially shippable product increment". I will discuss the make-up of the Project Team later in this article, under the topic: Scrum Roles.
The Product Owner, the ScrumMaster and the Project Team will make an initial pass over the Product Backlog items where they work out roughly how long each item will take. Initially, these are estimates, best guesses. As time progresses, well within 30 days, we’ll know if the estimate was even close.
Scrum lets us refine our estimates on-the-fly: if we believe that a task will take longer than envisaged, we have the ability to say so before the tasks starts. By only ever working with small work packages (time-boxed to 30 days), any schedule/requirement issues are dealt with as soon as they are identified, not much further downstream where the cost of recovery is considerably higher.
What does this "potentially shippable product increment" actually mean? Put simply, every 30 days, the team should provide something of value to the business, something they can use or something that provides considerable direction.
The beauty of the 30 days approach is this: if the Product Owner, customer or the business likes what they see at the 30 day interval, they can then re-prioritise the Product Backlog. This is important as it means that we are only ever producing goods that will be used by the business: remember that only 20% of a [software] product‘s features are used frequently. In other words, 80% of a software product’s "value" comes from 20% of it features.
Figure 1 - The Scrum Process
Daily Scrum Meeting
One of Scrum’s primary practices is the 24 hour cycle shown in figure 1: the Daily Scrum meeting.
How many of you attend meetings on a regular basis? If you are in the corporate environment, meetings seem to be the norm and often they have little business value apart from to act as a caffeine injection mechanism. Folks who sit down at meetings get too comfortable: they attend meetings for the coffee and doughnuts, not for the project’s sake. Once relaxed, those same folks often stray off the meeting agenda and start discussing items that are either on the project periphery or are not even project related. I am sure you’ve all been in such meetings…
Scrum resolves these issues using two simple approaches.
Firstly, Scrum-managed project meeting rooms are devoid of chairs. Attendees have to stand up. This might sound cruel, but it focuses the mind and those folks who are capable of sitting in (often unproductive) meetings for hours on end are soon discouraged.
Secondly, Scrum-managed meetings are time-boxed or time limited. The Daily Scrum meeting is typically time-boxed to 15 minutes. Only extraordinary projects should require more than 15 minutes. Here is the crux: if you can’t say what you have to say succinctly in a short space of time, you’re waffling, get your coat. Keeping it time-boxed focuses folks’ minds and helps keep agenda items targeted at what’s important: Moving the project forward towards delivery of "something"… and identifying and removing obstacles that prevent this goal being met.
The purpose of the Daily Scrum meeting is to answer Scrum’s three questions:
- What did you do yesterday?
- What will you do today?
- What obstacles are in your way?
But there is more! The ScrumMaster and the Project Team are the only people who are allowed to talk: outsiders may listen in, but are removed or silenced should they say anything. This is all about who is committed to the project or not. Outsiders tend to volunteer items that are important to them, but not necessarily to the project and its immediate goal: delivery business value within the 30 day sprint.
Scrum refers to those who are committed to a project as "pigs" and those who are not as "chickens". The story goes like this: A chicken and a pig where chatting about setting about a business together. The pig asked the chicken: "What kind of business would we set up?" The chicken thought for a moment and said "How about a restaurant?" The pig liked the idea but asked "What would we serve?" The chicken responded "How about ham’n’eggs?" At which point the pig refused to take the business venture any further. The chicken was confused and asked "Why?" The pig responded "Well, you would only be involved, whereas I would be committed."
One thing I should mention is the fact that Scrum expects late-comers to any of its meetings to pay a nominal £1, $1, or €1 fine: at various milestones within the project the fines are donated to charity. You may find this slightly humorous; however it does focus the mind and it does prevent meetings dragging on because of late-comers (we have all been in meetings that have to start over because of late-comers, right?) Late-comers are simply told to pay their fine, the meeting continues without further ado.