DRM - Daniel’s Random Mutterings

Introduction

I recently attended a CSM (Certified Scrum Master) training course and was (still am) pretty convinced that Scrum is a very good approach to running your software development projects — making sure you meet (or exceed) your customer’s expectations, reacting to changing requirements, while at the same time allowing the development team to maintain focus and control. While preparing for this course, I read the two canonical Scrum texts: Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, and Agile Project Management with Scrum, by Ken Schwaber.

What is Scrum?

Scrum (not SCRUM — it’s not an acronym) is an agile development methodology. You might say that Scrum is XP’s (not so) ugly step-sister. Where XP focuses more on the actual programming side of things (pair programming, test-driven development, etc.), Scrum provides a light-weight methodology and framework for keeping your project on track.

By following an iterative, strictly time-boxed, project schedule a development team delivers project functionality (business value for the customer), making sure that the project owner is always aware of what the project is doing and where it’s going. A Scrum project delivers software in increasingly complete releases. Each iteration of the process (a ‘Sprint’, in Scrum lingo) must finish with a potentially shippable unit of increment. This unit of increment is presented to the customer (or a representative of the customer) in a Sprint review meeting, which serves as the basis for planning the next iteration. The importance of team communication is emphasized by the introduction of daily (!) meetings — the Daily Scrum. In the Daily Scrum, the entire team brings itself up-to-date. Each team member briefly presents his progress as well as any issues preventing him from achieving his goal.

The beauty and simplicity of Scrum is its approach to requirements management and change management. At the outset, a set of requirements for a Sprint is defined by the product owner as the Sprint goal, describing the expected increment of functionality for this iteration. From this, the team develops its Sprint backlog, typically containing every task that has to be performed in this iteration in order to meet the expected Sprint goal. Once a Sprint has been started, the product owner is expected to provide the necessary input to the team, but cannot change the Sprint goal or the requirements priorities. The Scrum Master’s role is to enable the team to do the best work they possibly can. The Scrum Master’s responsibility is to remove obstacles which keep the team from reaching their goals. Also, the Scrum Master can serve as a mediator between Product Management and the development team — making sure that regular meetings are held and the Sprint goals and priorities remain unchanged. By keeping a tight rein on the ever-changing requirements, the hectic frenzy of last-minute changes, unspecific additions to the developer’s workload (’Sales just called — they need fancy rotating buttons by Friday.’) is reduced, allowing the development team to keep a clear head and continue along the planned course. The relatively short duration of a Sprint — one month, or thirty days — still provides the product owner with a high degree of control and flexibility. While he cannot change his mind or add new tasks within a running Sprint, every completed increment at the end of a Sprint shows clearly how the project is progressing. By setting goals for the next Sprint, adding requirements to the project’s backlog, and by adjusting priorities, every new Sprint plan is a chance for the product owner to react to changing market or customer requirements. The requirement of having a (potentially) shippable increment after each Sprint provides the maximum flexibility — deciding to release early, potentially beating the competition. Ultimate time-to-market.

Agile Software Development with Scrum

‘Agile Software Development with Scrum‘, by Ken Schwaber and Mike Beedle, presents the Scrum methodology. The basic elements of the Scrum approach (Sprint goals, Sprint backlogs, Sprint planning meetings, daily Scrums, sprint review meetings) are presented in detail. The various components, as well as their impact on the development project, are presented very clearly and concisely. As the definitive reference to Scrum, this book is a must-read for anybody who wants to implement Scrum (and also anybody who wants to get a new perspective on why his or her development projects are maybe not very satisfying). Ken has a lot of experience in development projects and he clearly spent a long time not only thinking about the Scrum methodology, but also discussing it with other practitioners and refining the methodology. This experience show throughout the book. There are good examples to back up the various elements and everything you read in the book makes sense (at least it did to me).

Having said that, I have a huge issue with this book. The content is great and extremely important, the book is just very, very badly put together. To start off, the book is not very well proof-read. There a loads and loads of typos and slight grammatical errors (such as a sentence ending in a different tense than it started in). I found this very distracting. It’s probably my very personal problem, but each time I come across a typo or strange grammatical error, my concentration is broken and I need a couple of sentences to get into the flow again. For me, this made it harder to enjoy the book. My second gripe is with layout and diagrams. The book has diagrams which look like they were thrown together from Office clip-art (in fact some of them are — see figure 4.4 in the book for a particularly ghastly example), and then printed on a dot-matrix printer, making some of the pretty much illegible. The layout of the figures in the text is just as bad: No text flow around the figures, figures more or less haphazardly aligned on the page, leaving large parts of the page empty. This makes the book appear very amateurish and unpolished. If a student had given me this as a thesis draft, I would have told him to go home and explore the layout features of his office application. I found this lack of polishing extremely distracting and disappointing.

I would really like to see a revised and cleaned-up edition of this book. With all the attention that agile development has been getting, it would definitely be worth it. As it stands, I’d give this book 9 out of ten for content, but only 3 out of ten for presentation.

Agile Project Management with Scrum

The second book, ‘Agile Project Management with Scrum‘, by Ken Schwaber, is a companion text to the first book (the Talmud to the Torah, if you like). Where the first book concentrated on the Scrum methodology and its application in development projects, this second book — as the title would imply — concentrates more on the project management side of things. The first chapter contains an introduction to the Scrum methodology, so the book can be read on its own, without having first read ‘Agile Software Development …’. The remainder of the book follows a very interesting pattern — in his introduction, Ken Schwaber tells us that the book ‘in in essence a book of case studies about Scrum’. The benefits of the Scrum methodology, and its use in project management, are presented based on real-life project examples from Ken’s day-to-day experiences with coaching Scrum projects. Each of the examples serves to demonstrate a specific point of the Scrum approach and each example really brings this point across. Some of the examples are positive examples, where experienced Scrum practitioners and Scrum Masters have used the Scrum methodology to improve their development projects. Other examples are bad examples (anti-patterns perhaps), illustrating dysfunctional project teams, Scrum Masters who just don’t ‘get it’. Each example is presented along with an excellent analysis of what went wrong (or what the positive results were, in the case of the positive examples), what could have been done to improve the situation and where Scrum provides benefits in each of these situations.

What makes this book fun to read is the way in which it allows you to jump around between the chapters, following whichever thread interests you. It’s especially interesting to have this book available while reading the first book. This allows you to hop between the books; whenever you come across an issue in the first book which makes you say “Hmm… OK, but I wonder if ….”, you can be pretty sure that there’s a scenario or case study in the second book that answers your concern and provides additional enlightening background information.

Also,’Agile Project Management…’ is very well proof-read, expertly laid out and has clean and pleasing figures, making it a very enjoyable reading experience for anal-retentive nitpicking smartasses like myself. So this one I’d give 8 out of ten in both content and presentation.

Summary

Scrum is a very promising (and highly successful) approach to bringing order from chaos and developing software in an agile and flexible iterative manner. From my own development experience, I strongly believe that agile approaches are the superior way of going about project management. Project requirements will change over time, as new technologies are introduced or new customers adopt a product — or just as the demonstration of the current Sprint results suggests new and exciting avenues to explore, which hadn’t been envisioned at the outset. An iterative approach, delivering shippable increments of software, can help the project team to retain control over their schedule, while at the same time providing product management with a highly responsive project, enabling rapid and effective reactions to shifting requirements.

If you’re involved in software project management and want to improve the way your projects are run and deliver results, you should at least read the first book, ‘Agile Software Development with Scrum’. This will provide you with a solid foundation for applying Scrum in your next development project.

The second book, ‘Agile Project Management with Scrum’ provides invaluable background information and case studies of Scrum development. Read this if you need more anecdotal evidence, a more thorough foundation for the various Scrum techniques. Also, give this book to your manager (or present it to him in a condensed form) when you want his or her OK to go ahead with implementing Scrum in your next project.

Literature references

Agile Software Development with Scrum
Ken Schwaber, Mike Beedle
Prentice Hall, 2002
ISBN 0-13-067634-9

Agile Project Management with Scrum
Ken Schwaber
Microsoft Press, 2004
ISBN 0-7356-1993-X

Bookmark on del.icio.us
Add this post to digg.com
Bookmark on reddit.com

This entry was posted on Sunday, November 20th, 2005 and is filed under Reading. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.