Adaptive Project Management Using Scrum - Page 3

Craig Murphy, www.craigmurphy.com

Why Iterative Development Works

Consider figure 9, it presents an ideal profit and loss curve comprising of cost over time. Early in most projects, there is an initial hit, a start up cost and that's the period below the line.

After some time passes, typically a number of years, the project starts to make some profit and that's the period above the line.

Figure 9 - Profit & Loss using "traditional" development (from Software by Numbers)

The crux is getting the project into profit as quickly as possible. Obviously there are a number of tricks that you can use to achieve this, some of which may involve cutting corners, reducing quality, reducing scope etc. Beware if you do use such techniques early inducement of the profit position point can be a short-term solution that may affect future profit. Poor quality (of product, of support, etc.) can lead to a reduction in future sales.

Iterative development is a technique that allows a controlled inducement of the profit position: if we can release a product earlier on an iterative and incremental basis, we can realise the benefit of the early release much earlier on in the project. Consider figure 10, it presents a typical profit and loss curve where iterative development has been applied.

Figure 10 - Profit & Loss using iterative development (from Software by Numbers)

Iterative development means you are able to deploy your application sooner than before. The earlier you are able to deploy your application, the sooner you can reap the profit.

Scrum promotes iterative development: every 30 days you have a "potentially shippable product increment" (or executable). If you are able to move much of the useful functionality into early releases, not only are your customers going to appreciate early access, they'll be in a better position to confirm that they're getting what they asked for.

Adapting Scrum

I have enjoyed reasonable success by adapting Scrum's three questions. Early in 2004 I used the three questions in front of a small audience: they really appreciated the simplicity. They also appreciated the honesty that the questions seemed to portray: because of their simplicity, it's difficult to incorporate untruths into the answers to these questions.

I discovered that my upper managers wanted four questions answered:

1. Summary of work completed to date
2. Summary of work completed in the last 14 days
3. Plan of work for the next 14 days
4. Project issues requiring their action

Ignoring question 1 for now, it's clear that questions 2, 3 and 4 map directly on to Scrum's three questions: "what have you done?", "what do you plan to do?" and "what's getting in your way/stopping you working?".

If we keep track of our responses to Scrum's first question, "what have you done?", it lets us answer question 1, it gives us a summary of work completed to date. Indeed, whilst I have not been able to implement Daily Stand Up Meetings, because of geographical and diary time issues, their benefit has not gone unnoticed. I have had some buy in to "stand up" meetings, but not enough: we don't practice them right now.

Summary

I hope this article has provided you with a flavour of what Scrum is and how it can help you manage your next (or even current) project and help you deliver software incrementally instead of "big bang".

Keep asking these questions:

1. What is the simplest thing that can move the project forward?
2. Does what I am doing right now move the project forward at all?
3. Are there any impediments that are preventing progress?

I will let you think about figure 11. Where does your current/future project appear? Scrum lets us move our projects from "top right" towards "bottom left". Those projects that try to implement 100% of the requirements move themselves into anarchy; they try to do too much. By doing less work, accepting that 80% of a product's value does come from 20% of its features means you can move through complex and complicated towards simple.

Figure 11 - Where's your project?

Lastly, if you take one thing away from this article, it has to be Scrum's co-founder, Ken Schwaber being quoted in April 2004, Vienna: "Don't procrastinate, do something, no matter how small..."

Scrum: the ethos of simplicity and the art of the possible.

This article's resources

1. Scrum: It's About Common Sense http://www.controlchaos.com
2. Slide Deck accompanying this article
3. http://www.scrumalliance.org
4. Software by Numbers: Low-Risk, High-Return Development, By Mark Denne, Jane Cleland-Huang. Prentice Hall PTR, 2003, ISBN 0131407287
5. Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, 2004, ISBN 073561993X
6. Agile Software Development with Scrum, Ken Schwaber, Mike Beedle, Prentice Hall, 2002, ISBN 0130676349

---

Related Methods & Tools articles

Agile, Multidisciplinary Teamwork

Going round and round and getting nowhere eXtremely fast?

Opening Communication within a Scrum Team

More Agile and Scrum Knoweldge

Open Source Scrum Tools

Scrum Expert

Agile Videos And Tutorials

---

Page 2   

Click here to view the complete list of archived articles

This article was originally published in the Winter 2004 issue of Methods & Tools