This is a good book with lots of valuable information around the empirical nature of Scrum. For someone who was central to creating Scrum, the book doesn't offer much more.

It's broken up into three parts: Overview of Scrum / Why it works / Case studies.

The overview of Scrum is poor at best. There are much simpler ways to communicate it. If you don't know anything about Scrum then this book probably won't help get you started.

The "Why it works" chapters were much more interesting and valuable. It takes you through the epirical nature of scrum and why previous methodologies have failed. The most interesting part is the brief exposition around the psychological, anthropological and systematical viewpoints around Scrum. Like much of the book, this could have been written better and with more indepth information, but still meets a basic need.

The case studies and ancillary information in the last few chapters feel hasty and are of little value. Many of the examples (although based on actual events) feel contrived and are simplified so much that they aren't highly illuminating.

Overall the book wasn't the greatest but it did provide me with some value. The editing is quite poor and there are numerous mistakes throughout. The general layout of the page is also problematic and makes it difficult to read.

Most laughable however are the images and graphics. They look like they were made in MSPaint and screen capped into the book.

ASDS is a very good book, but only for the few who want to be Scrum experts. The material is thorough, and not necessarily easy to get through, in part because the Schwaber and Beedle walk through every part of Scrum in detail, as well as cover situations that likely don't apply to most, and they even go through philosophical views that some may care little about. To be sure, there are gems in the book, and I learned a few important points, but I have been to ScrumMaster certification training, read two other agile books, and been mentored by a CSM/PMP. I feel the book only moved me from 80% comfort level with Scrum to 85%. If you are a consultant managing projects, or you want to teach, coach or train in this area, read the book. If you a internal project manager,product manager, or IT manager, I recommend you get Agile and Iterative Development: A Manager's Guide (The Agile Software Development Series)and read the section on Scrum. It's simpler, cleaner, and the rest of the book gives good background to agile and options you may want to consider. If you are a team or development lead, or the senior developer, get Agile Project Management with Scrum (Microsoft Professional). It's an even easier read, focussed solely on Scrum and gives lots of enjoyable stories of real situations the author went through, good and bad.

This is the one book you buy everyone on your team and tell them to read as the first step to implementing scrum. It's well written, clear, and consise. Most people only need to read chapters 2-4, 5-7 are on control theory, etc that is interesting but not required.

This is good stuff 'straight from the horses mouth'.

I'm the resident 'Scrum Lord' at my company and I purchased this book early on in my 'Scrum' travels. It's been a handy quick read resource for our entire company. We bought a 1/2 dozen to pass around when we got new hires so they could read up a bit before they went to our in-house training in Scrum/Agile. For folks with just a little time, we suggested they read chapters 2 and 3 to get the gist of it. If they had more time...we suggested the read the whole book. Our in house training was inspired by some of the concepts used in this book. Its a great one! All of my 'loaner copies' are checked out somewhere here at work!

This book provides an excellent road map for the Agile development.
Must have on every manager's book shelf.

Ken Schwaber provides a hands-on and succinct introduction to the Scrum philosophy - albeit, it is a little idealistic at times. Where XP focuses on enhancing the quality of the software, Scrum acts as a management wrapper for streamlining the overall process.

Beginning with the history, you'll learn about the key positions, team interaction and structure, the timelines, and the tools involved in the process. This is, arguably, the de facto source of information on Scrum, and it is well worth the time given the relatively modest size of the book. This is a great book to pass around the office, so order a few copies, at least!

Helping the people who DO the work understand the value of simplicity. Take in context of the other Schwaber books, this book is intended to lead a developer/technologist down the path of evolving a lens of simplicity. Even greater value can be applied should one synthesize the data from Mike Cohn's two books, as well as, Weinberg and McBreen. Evolving something useful is not a book, degree or company reputation ... rather it is artful, experienced, pragmatic and thoughtful, context-driven decisioning with the sole purpose of making a customer smile.

This book will give you the basics of the what, why, how, and when for scrum. Make sure to pick up ken's other books for more on scrum, particularly 'the enterprise and scrum' for implementing scrum in a larger organization.

A revolutionary change to software development, relevant especially for business partners to read and master when development undertakes this progressive approach to staying competitive and advancing products.

This book is worth every penny. After buying the first one I bought two more so that I could pass them around the office. It's thorough and inspiring.

I've been a ScrumMaster for over 3 years now, and I still use this book on a constant basis (that's my fault, not the book's!). :)

While there are newer books, including Scrum for Project Managers by Ken, I find this book to be the closest to the cookbook many people want and need when implementing new methodologies and processes.

If you're thinking about implementing Scrum, this is the one book you cannot afford to pass over.

Good job Ken!

I've read both of Ken Schwaber's books back to back. Schwaber underscores that a Scrum Master is not a project manager, so you need to be aware that there's a gap to be filled between what a Scrum Master does and expectations by a client around agile project management.

Ken has created a radical thought of empirical project management as against the prevailing defined process paradigm..
Enter the world of successful Agile project management using SCRUM. And who say's it is anarchy here?? Ken introduces the concept of discipline in chaotic projects life

I really appreciates this book. It can helps me knowing in depth in Agile development and how to organize team with Agile process.

I love it.

This is the definitive source on how to do Scrum. While current practices have evolved from this starting point - this is where it all started. A great introduction as it explains all the steps.

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!

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!

One might think that a book published in 2001 could be out-dated in the fast-moving world of computing. This one isn't, because the search for the silver bullet of software development never ends and Scrum is still relatively early in its adoption. Scrum and agile development continue in their growth in importance, and as refinements and extensions of ideas that have been around or lurking for years. (In fact, one of the things that can be tedious about agile writings and lectures is the impression that everybody was doing pure waterfall since the beginning of development, until agile came along. Of course, that isn't true, as I can say from personal experience.)

Nevertheless, Agile, Scrum, XP, etc., have certainly brought another wave of excellent ideas and formalized them into a well-defined set of procedures that are mercifully light on formal documentation and sign-offs. The authors provide the necessary background, overview, and details, along with many positive examples and warnings against traps and faulty tendencies.

As you would expect from one of the inventors of Scrum and an early practitioner, the information rings true. These aren't guys writing an abstract book of theoretical processes that lack depth or relevance when you try to put them in practice. They give plenty of attention to the cultural and personal implications of different processes and what it might mean to have more transparency and a different approach to priorities. Of course, this isn't a psychology book, and their purpose is not to give detailed prescriptions for dealing with slackers and jerks.

For someone unfamiliar with Scrum and agile, this is one of many potential books that can serve as an introduction. At around 150 pages (although relatively expensive for a thin paperback), you can make a brief investment in time. In fact, you can also skim some major parts if you want to catch the main ideas, unless you just want to take a first crack via the Agile Alliance or the Scrum Alliance and then move on to a book.

One might think that a book published in 2001 could be out-dated in the fast-moving world of computing. This one isn't, because the search for the silver bullet of software development never ends and Scrum is still relatively early in its adoption. Scrum and agile development continue in their growth in importance, and as refinements and extensions of ideas that have been around or lurking for years. (In fact, one of the things that can be tedious about agile writings and lectures is the impression that everybody was doing pure waterfall since the beginning of development, until agile came along. Of course, that isn't true, as I can say from personal experience.)

Nevertheless, Agile, Scrum, XP, etc., have certainly brought another wave of excellent ideas and formalized them into a well-defined set of procedures that are mercifully light on formal documentation and sign-offs. The authors provide the necessary background, overview, and details, along with many positive examples and warnings against traps and faulty tendencies.

As you would expect from one of the inventors of Scrum and an early practitioner, the information rings true. These aren't guys writing an abstract book of theoretical processes that lack depth or relevance when you try to put them in practice. They give plenty of attention to the cultural and personal implications of different processes and what it might mean to have more transparency and a different approach to priorities. Of course, this isn't a psychology book, and their purpose is not to give detailed prescriptions for dealing with slackers and jerks.

For someone unfamiliar with Scrum and agile, this is one of many potential books that can serve as an introduction. At around 150 pages (although relatively expensive for a thin paperback), you can make a brief investment in time. In fact, you can also skim some major parts if you want to catch the main ideas, unless you just want to take a first crack via the Agile Alliance or the Scrum Alliance and then move on to a book.

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!

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!

... buy both this book and the other one ("Agile Project Management with Scrum" by Ken Schwaber). I found the other book slightly more helpful.

It does get the point of scrum across.

I'm now a convert.

But it could have been done in about 10 pages.

The figures are laughable. They look like poorly enlarged bitmaps and rarely convey anything useful or intelligible. They will make you angry.

The formating of the text is confusing and short on structure. It's as if the editors had never heard of bullets.

Finally, the cost of the book is absurd for what could be condensed into a pamphlet.

In summary, you can learn all you need about scrum from browsing the internet.

It does get the point of scrum across.

I'm now a convert.

But it could have been done in about 10 pages.

The figures are laughable. They look like poorly enlarged bitmaps and rarely convey anything useful or intelligible. They will make you angry.

The formating of the text is confusing and short on structure. It's as if the editors had never heard of bullets.

Finally, the cost of the book is absurd for what could be condensed into a pamphlet.

In summary, you can learn all you need about scrum from browsing the internet.

People aren't very good at seeing into the future. If we do foresee what is going to happen, we often get the "when" of it wrong. And even if we get the what and the when right, we rarely predict the "what else" - all those unpredictable events that inevitably upset any plan. So why are so many software methodologies built so solidly around precise, complex, long-term plans? The only reason such methodologies appear to work at all is that everyone, their fondest proponents included, spend a lot of time running around behind the scenes, bolstering them each time the predictably unpredictable kicks another prop out from under.

Here's a radical proposal: why don't we just say that we're going to do (and then do) what we were going to do anyway? That's Scrum. It's built around short time-scales, a month or so, the kind where forecasting has a chance to work. It counts on simple plans with unambiguous goals, to be completed within those timeframes. It demands that people just go ahead and do what needs to be done, even if a few rules get bent, things that people would have done anyway. The difference lies in doing them with head held high, not as midnight missions intended to sneak success into fundamentally broken plans, in spite of counter-productive rules.

The consequences of the approach are far-reaching. For one, it outlaws the plus-one disease, or mission creep, or feature-itis, or whatever you call it. This plain-spoken approach makes promises and works to keep them - having the content of the promise changed by fiat, halfway through, is outlawed. There's a time and a place new commitements to be made, and that is not in the heat of the development moment. "Scrum" uses many sports analogies, and moving the goalposts (or having them moved) is not part of its game.

There's a lot more too it, of course, and that's why describing Scrum takes a whole book. It has a lot to like, including an emphasis on personal responsibility and even bravery - things that many work environments punish brutally. I don't go along with the authors' revival tent true-believerism. Despite that, there's enough good sense in this book to soften even doubts as solidified as mine.

//wiredweird

I really enjoyed reading this book. It has provided some valuable information and contextual background to Scrum. We are currently introducing Scrum to our Software Development organization and this book has helped clarify and understand the key drivers for Scrum to be successful in our environment. The book can be read in a couple of days and provides very practical and applicable information.

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.

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.

...the book itself isn't really that great. SCRUM has some very interesting ideas about managing a software project, but the book is just OK. I seem to remember him saying that "it was done quickly, just in time for a conference" on his blog at one point. However, if you're going to try some SCRUM, you'll want to read this.

Additionally, you'll need this book if you're going to read his other SCRUM book (Agile Project Management w/ SCRUM) from Microsoft Press, because you'll want the background from this book for that one.

One thing that is not covered in this book is how you get management approval when you have a "process by not having a process," or how SCRUM might scale to more that 7-11 people (other than a SCRUM of SCRUMs.)

...the book itself isn't really that great. SCRUM has some very interesting ideas about managing a software project, but the book is just OK. I seem to remember him saying that "it was done quickly, just in time for a conference" on his blog at one point. However, if you're going to try some SCRUM, you'll want to read this.

Additionally, you'll need this book if you're going to read his other SCRUM book (Agile Project Management w/ SCRUM) from Microsoft Press, because you'll want the background from this book for that one.

One thing that is not covered in this book is how you get management approval when you have a "process by not having a process," or how SCRUM might scale to more that 7-11 people (other than a SCRUM of SCRUMs.)

This is one of those spot-on books. It's small, easy to read and challenging at the same time.

It's not a silver bullet, but gives some real tools to get software out the door. Oh, and it's not limited to the software industry either.

Ken has another book "Agile Project Management with Scrum". Buy one or the other, but not both as it covers the same ground - as I found out.

Pop over to Ken's site at http://www.controlchaos.com/ and browse around the resources. You'll get the essence of Scrum.

I thought this was so relevant that I did the taining course!

This is one of those spot-on books. It's small, easy to read and challenging at the same time.

It's not a silver bullet, but gives some real tools to get software out the door. Oh, and it's not limited to the software industry either.

Ken has another book "Agile Project Management with Scrum". Buy one or the other, but not both as it covers the same ground - as I found out.

Pop over to Ken's site at http://www.controlchaos.com/ and browse around the resources. You'll get the essence of Scrum.

I thought this was so relevant that I did the taining course!

Some day, practitioners of any field will regret they did not read this book, apply it, and reap the benefits. Until that occurs the readers of this book will have an 'unfair' advantage in the markets that exists and are being envisioned.

Written from personal experience, Ken and Mike have unambiguously challenged what traditional management wishes would happen with a lucid description of the core activities that make some teams catalytically successful.

Those of us who lived in the places where Ken draws his experience from, are pleased and releived he has expressed what goes into moving from merely being really good to having the ability to do incredible things in a sustained way.

Some day, practitioners of any field will regret they did not read this book, apply it, and reap the benefits. Until that occurs the readers of this book will have an 'unfair' advantage in the markets that exists and are being envisioned.

Written from personal experience, Ken and Mike have unambiguously challenged what traditional management wishes would happen with a lucid description of the core activities that make some teams catalytically successful.

Those of us who lived in the places where Ken draws his experience from, are pleased and releived he has expressed what goes into moving from merely being really good to having the ability to do incredible things in a sustained way.

The reader, Frank Carver (Ipswich, Suffolk United Kingdom), could not be more clueless... I've been practicing Scrum for over a year and am a certified ScrumMaster, and one of the major strengths i see is the customer's ability to drive the project (which includes being involved throughout the sprint frank). I appreciate the fact that Scrum is a management wrapper, allowing me to inject whatever engineering processes are appropriate from project to project

This is a great hands on book for developers and development managers alike. Good analogies and case studies. Great references as well for those of us into process control theory and complexity theory. Only 150 pages makes it very readable.

This is a great hands on book for developers and development managers alike. Good analogies and case studies. Great references as well for those of us into process control theory and complexity theory. Only 150 pages makes it very readable.

A very practical guide, with easy to follow steps, great motivating arguments, and a logical presentation style make this book really work, especially given its short length. I also really enjoyed the examples given of team transitions. SCRUM itself is a very useful methodology for certain types of projects, and this book makes it clear what those projects are and how to adopt it for them.

On the bad side, the style change is pretty obvious and jarring when they switch authors, and some of the other-author chapters are interesting, but not necessarily as useful.

Missing from the book is a description of how to get buy-in and how to convince folks using a current process to switch (i.e. how to make and express a logical decision between two processes). It also neglects a bunch of the people issues, such as how to prioritize in career development, training, or even team-building / morale events. The book claims to be about the people and energizing them through shipping products, but I really think that's only one part of making your developers happy. A very important one, mind you, but not the only one.

This book is a strange mixture of trendy agile methodology and dusty corporate management. My guess is that it has been hurriedly re-edited based on an old draft to try and catch the Extreme Programming (XP) bandwagon.

Scrum is fundamentally a management technique, aimed at getting the most from development teams. As such it shares some principles with the new programming methodologies but, tellingly, many of the things which can lower the stress and help make software development fun are absent. There's no "40 hour week", developers are encouraged to put in whatever is necessary, even if it means working all night. There's no "Pair Programming", and mere programmers are actively discouraged from contacting the customers or users to get instant answers and decisions.

Where Scrum scores is in heavyweight, bureaucratic organizations, and its team isolation techniques can help to get a more extreme approach off the ground. Be prepared to abandon it like a first-stage booster if you do want to get XP into orbit, though.

The production quality of this book is poor. The illustrations are laughable pixelated screen dumps, and the same information could have been got across in a book half the size.

If you are a team leader of a project in chaos, and need a way out, this might be just what you need. But don't ever forget that your team are people, not just "resources".

This book is a strange mixture of trendy agile methodology and dusty corporate management. My guess is that it has been hurriedly re-edited based on an old draft to try and catch the Extreme Programming (XP) bandwagon.

Scrum is fundamentally a management technique, aimed at getting the most from development teams. As such it shares some principles with the new programming methodologies but, tellingly, many of the things which can lower the stress and help make software development fun are absent. There's no "40 hour week", developers are encouraged to put in whatever is necessary, even if it means working all night. There's no "Pair Programming", and mere programmers are actively discouraged from contacting the customers or users to get instant answers and decisions.

Where Scrum scores is in heavyweight, bureaucratic organizations, and its team isolation techniques can help to get a more extreme approach off the ground. Be prepared to abandon it like a first-stage booster if you do want to get XP into orbit, though.

The production quality of this book is poor. The illustrations are laughable pixelated screen dumps, and the same information could have been got across in a book half the size.

If you are a team leader of a project in chaos, and need a way out, this might be just what you need. But don't ever forget that your team are people, not just "resources".

SCRUM is a "light weight wrapper" of techniques to manage and guide your software projects. Actually, you could use it on a lot of other types of projects, but software is its best use.

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

SCRUM is a "light weight wrapper" of techniques to manage and guide your software projects. Actually, you could use it on a lot of other types of projects, but software is its best use.

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

This book packed an amazing amount of information into few pages. Most importantly, Ken Schwaber provided real-life examples of what worked for him and what didn't--and explained why.

Schwaber, the primary proponent of SCRUM, and Beedle have much experience with SCRUM and share it freely. Over the years, I've worked with numerous "newfangled" approaches to programming, including XP. Without SCRUM, however, we could not realize XP's potential. SCRUM is so deceptively simple, so logical, and so effective that one wonders why it hasn't been adopted more widely. In fact, I believe that as Schwaber continues to spread his message, SCRUM will be the wave of the future.

Schwaber's and Beedle's blueprint is a must read for every software developer. Once you try it, you'll wonder how you ever lived without it!

Scrum is the lever that can people-wise scale the development methods of XP and some of the other agile processes...

I used Scrum with a cross-functional team of 40+ people split into four smaller teams. It worked exceedingly well. We used some of the XP engineering disciplines as well, but what I love about Scrum is that it really doesn't have anything at all to do with software. You can use it for any task-oriented project that has ambiguity associated with the way the work should be done.

Scrum is IMHO the relatively undiscovered gem of the Agile Methods family. Corporate IT professionals in particular ought to learn and apply Scrum...

Let me start off with my gripe. This is not a [price] book. It is short (150 pages with about 100 of those being the meat) and the graphics look like someone printed the bitmaps from their powerpoint slides. For [price] they could have hired a graphic artist to redo them in a vector-based graphics program.
Now on to the good stuff. This book is quite practical. It provides a lot of insight into what practices the authors have found to work, what problems they solve, and *why* they solve them. The practices in this book are largely common sense and most successful projects have probably adopted at least a portion of them already. The concept is simple: reduce distractions so you can get real work done. This is missed too often in today's environment though. Requirements keep changing even multiple times in the same day.
Everyone who is managing a software development team should read this book. It will give you a good idea about what your job is (giving your people covor to work) and what it isn't (micro-managing everything with process).

Let me start off with my gripe. This is not a [price] book. It is short (150 pages with about 100 of those being the meat) and the graphics look like someone printed the bitmaps from their powerpoint slides. For [price] they could have hired a graphic artist to redo them in a vector-based graphics program.
Now on to the good stuff. This book is quite practical. It provides a lot of insight into what practices the authors have found to work, what problems they solve, and *why* they solve them. The practices in this book are largely common sense and most successful projects have probably adopted at least a portion of them already. The concept is simple: reduce distractions so you can get real work done. This is missed too often in today's environment though. Requirements keep changing even multiple times in the same day.
Everyone who is managing a software development team should read this book. It will give you a good idea about what your job is (giving your people covor to work) and what it isn't (micro-managing everything with process).

If you've survived software projects that have gone schizophrenic after doing a lot of up-front planning, you may find that chapters 2 and 5 are worth the price of the book. Those chapters compare two process control models: the "defined" model, which is the basis for most methodologies, and the "empirical" model, which is the basis for SCRUM. Knowing the difference between these process control models, and their implications when applied to software projects, is essential when trying to understand why so many projects fall apart under pressure, and why Agile techniques, including SCRUM and XP, are improvements on the way we've been doing business.

Ignore the few faults this book has (it could have used a thorough copy-edit pass, illustrations that weren't low-res screen shots, and a complete index), and you'll be rewarded with a book that dense in timely, useful information, with case studies to back the theory up.

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.