Agile Software Development with SCRUM (Series in Agile Software Development)

What's unique is that it wraps around the "Design it first" school that I follow, as well as the Extreme Programming (XP) school that follows a proto-typing approach.

SCRUM provides the mechanisms for organizing and controlling the development of your software project. You develop a short list of deliverables for the next 30 days and have a series of daily meetings. Oh, there's more to it than this.

In software projects I have followed a process where the design is fully thought out in advance. I say it is 85 % accurate as I know that mid-course corrections will be made as the software is developed and delivered to the client.

On large projects we typically work in 2 week deliverables, the author suggests 30 day "sprints". We break all the projects up into many packages of deliverables. One advantage to this was the client could see progress, give on course corrections, and you'd be sure to get paid. On small projects we have not followed any formal procedures.

What SCRUM does is give me a better, more thought out process for what the author calls these 30 day "sprints." I wish I had read this book earlier.

I picked up the book at a computer store and bought it reluctantly. I had heard good things about SCRUM, but the book looked too small and a quick read at the store didn't really turn me on that much.

But after I sat down to read it at home, I was very pleased. It is a very well-underlined book now.

I agree with the XP folks on the productivity of 2 person programming teams and have found their "test first" approach to be very interesting. However, I do find that their design-on-the-fly approach to be flawed. When XP works, I think it is because it attracts good programmers... it's not the XP proto-typing approach itself. In fact, I think any methodology that relies on proto-typing wears out the goodwill of the client. The clients time is limited and they value it highly.

I will say that I found many interesting ideas in XP. And, I recommend that anyone interested in the subjec of this book, go to the XP websites and read their books (about 6 or so at this time).

SCRUM fits around XP just as well as the design-it-first approach. What I disagree with in SCRUM (and XP) is the use of open office areas for programming. I believe studies have actually been done on this and closed offices, no windows, white walls, lots of marker boards... wins out. Anything beyond trivial programming requires concentration. Noise and movement kills concentration.

The graphics in the book really suck, as they look like they were printed out in some kind of old 320x200 screen resolution. But there is great depth to this book. It's a smaller sized book with small type (but still easy-to-read). So you actually get a lot of meat.

In the future, I will refer to this great book often and recommend all software people read it.

John Dunbar
Sugar Land, TX


Great for learning how to complete projects faster/better   March 30, 2002
Michael Cohn (Lafayette, CO USA)
20 out of 21 found this review helpful

This is the book I've been wanted for years. Until this book, the Scrum development process was not very well known and was documented only piecemeal in a couple of papers and websites. Finally, there's a book a that covers everything you need to know to run your software project using Scrum.

Schwaber is the "Godfather of Scrum" and essentially invented the techniques; Beedle was one of the first converts to Scrum and together they definitely know their stuff.

The book covers everything from the theoretical basis for Scrum to how to organize your teams, conduct daily Scrum meetings to keep things moving along, to planning your Scrum project, to tracking the "backlog" of items that need to be completed to finish a project.

Scrum is not a rehash of another methodology. As the authors say, "Scrum is different." Some of the things you'll learn in this book will seem counterintuitive but they work and the authors do a great job of laying out enough information to, if not fully convince you, then at least persuade you to give Scrum a try. (And once you've done that, you'll be convinced!)

I think this book is especially important for anyone reading any of the XP books that have come out over the past two years. Scrum provides an excellent management wrapper around the techniques of XP.

This book is great because it's only 150 pages but everything is succinct and clear--very different from some other books on project management techniques that are needlessly long.

After reading this book you will know everything needed to get started with a Scrum project--and most likely that project will be more successful with Scrum than with whatever process you're using currently.


The book that introduced the world to SCRUM   February 11, 2007
Eric D. Austrew (Brookline, MA United States)
12 out of 13 found this review helpful

Schwaber and Beedle are the co-developers of the software project management methodology known as SCRUM. This book was their first on the subject, and it did a worthy job of convincing me that this particular flavor of agile project management might help ameliorate some of the problems I see on a regular basis with my projects.

Although the writing style can be disjointed and opaque at times, the essence of SCRUM comes through in every chapter: Team responsibility and project controls that react to reality instead of attempting to define it. The authors point out that even highly specified software projects quickly escape any pre-defined project plan as development exposes issues and complexities that could not be anticipated. The SCRUM practices they describe are a method of running a project based on required outputs, rather than intermediate steps.

The general rules and methods described here all seem reasonable and well thought out, but at times the insistence on strict adherence to every detail of SCRUM seems oxymoronic. If we are running a project that is supposed to constantly react to the reality of where we are, who is to say that we might not find that 45 day sprints are more appropriate than 30 day sprints? Why not have a full day of planning for each sprint, or just a few hours? The important concepts - like time boxing certain activities - might be lost if the details don't mesh with the environment in a specific company.

There is also a certain assumption of dysfunction inherent in the concept of Product Owner, Scrum Master, and Team. The Product Owner is solely responsible for the backlog - that is, the requirements to be met by development. Well and good, but where is the standard meeting where the Owner receives feedback from the developers? SCRUM insists that outside of certain pre-defined meetings the Team is to be left strictly alone, so we can only assume that such wisdom is not meant to be passed. This is symptomatic of organizations where Product Managers think they know exactly what is to be done, and pass it directly on to the development team. But such a knowledgeable Product Owner is rare, and even when it happens, the transfer of a vision from a single person to a team is not easily accomplished in a short meeting. It seems to me that the Owner should be intimately involved throughout the sprint, rather than only at the beginning at end.

In a way, this points out the major gap in SCRUM. There are three roles, and none of them is the Customer. The Product Owner should represent the customer, but since he or she is not involved in day to day development decisions, and since interactions between him and the team are at a minimum, it seems that it is responsibility only in theory. Interjecting a more robust form of customer feedback than the Sprint Review would, in my mind, be a welcome change.

But ultimately these are all nitpicks. As an introduction to a light-weight and tested project management process, this book is invaluable. It lays out many of the pitfalls and nearly all of the necessary ingredients necessary to let a team of developers produce good work on time and without driving them crazy. As a product owner or project manager, that makes it worth its weight in gold right there!


Scrappy and thought provoking   January 3, 2007
A. Vander Meulen (Boston, MA USA)
5 out of 5 found this review helpful

I first purchased and read "Agile Software Development with SCRUM" after talking at length with Ken Schwaber at a software development conference in 2001.

I find some of terminology used in the Scrum process to be a bit trite - such as "Pigs and Chickens" - but the approach itself is solid. Overall, I'm sold on the process, and have employed many of Scrum's concepts in projects I've managed.

Scrum focuses on delivering maximum quality and predictability of the software development process with minimum overhead. The book is rather expensive given its length, but is a really good and thought-provoking introduction to a means of managing software development in way that empowers the folks who do the actual development while ensuring that those with a vested interest in the results get a reasonable quality deliverable (or deliverables) in a timely manner; and have a well defined means of tracking progress and providing guidance or feedback before it is too late for an off-track project to get back on course.

Anyone working to start-up a new software development project should read this book, if for no other reason then to gain insights into what really matters when managing such a project; how to manage without needlessly burdening the team members, or destroying their creativity and enthusiasm; and how to ensure that external forces do not cause a project to spin out of control.

On a final note - if you ever get a chance to hear Mr. Schwaber speak, definitely take the opportunity - though a bit salty, he is both entertaining and informative, and very good at responding to questions from his audience - well worth listening-to!



A practical book on the scrum process   August 6, 2005
S. Peterson (Bloomington, MN USA)
6 out of 8 found this review helpful

If you're the kind of person who demands technical books that weigh 15 pounds, with beautify layout and tons of white space, this book isn't for you.

But if you want a straightforward introductio to Scrum, this is it.