What do you think?
Rate this book
Agile Software Development with Scrum (Series in Agile Software Development) by Ken Schwaber, Pearson
eXtreme Programming is an ideal many software shops would love to reach, but with the constant pressures to produce software quickly, they cannot actually implement it. The Agile software process allows a company to implement eXtreme Programming quickly and immediately-and to begin producing ...
Download Link :
readbux.com/download?i=0130676349
0130676349 Agile Software Development with Scrum (Series in Agile Software Development) PDF by Ken Schwaber
Read Agile Software Development with Scrum (Series in Agile Software Development) PDF from Pearson,Ken Schwaber
Download Ken Schwaber's PDF E-book Agile Software Development with Scrum (Series in Agile Software Development)
Download Link :
readbux.com/download?i=0130676349
0130676349 Agile Software Development with Scrum (Series in Agile Software Development) PDF by Ken Schwaber
Read Agile Software Development with Scrum (Series in Agile Software Development) PDF from Pearson,Ken Schwaber
Download Ken Schwaber's PDF E-book Agile Software Development with Scrum (Series in Agile Software Development)
ebook
First published January 1, 2001
39 people are currently reading
1115 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 58 reviews
March 5, 2015
Having been involved in attempts at Agile/Scrum in three companies now, I can say that the method--I refuse to call it a methodology as it is not the study of methods--has things to recommend it.
This book, however, is overlong and burdened with sales pitches. If one were to glean the wheat from the chaff, the page count might drop to 50 pages or fewer. Not one but two introductory chapters (following two forewords and a preface) stand in one's way before chapter 3, which is the first to get down to brass tacks. Chapter 4 staggers along with 13 figures, over twice as many than have appeared in the book to that point, but is otherwise practical and useful. Chapter 5 is evidently for the folks with degrees in organizational behavior--which, one infers from its presentation here, is psychology for people who don't want to admit they're studying psychology. Chapter 6 is an aggressive and somewhat tiresome attempt to sell Agile/Scrum to ten different audiences in sequence, concluding with a rugby metaphor--which pivots partway through to an American football metaphor, accompanied by a table which (sneakily or stupidly) changes the order of its columns halfway down--for that mythical reader who can't understand anything else yet has inexplicably read this far. Chapters 7 through 9 are all short and mostly useful, consisting of advice on implementing Agile/Scrum in large organizations, and case studies. A bit more preaching rounds out the excessive length of the text. I have patience for very long books, but this one tried mine so severely that I took five months to get through its mere 159 pages.
Adding insult to injury, the production values are cheap for a title that lists at around forty dollars. The book was typeset using TeX, which normally I like, but the figures are repellently ugly and when the colorful cover image is reproduced in the text at the point where it is introduced and explained, it appears in grayscale--which eviscerates its meaning. I guess Prentice Hall wasn't about to pony up for a color plate.
The index is insufficient, and for no apparent reason a single term appears in a different typeface-- paradigm shift , that clever coinage of Thomas Kuhn's, once young and beautiful, now broken-down, toothless, and track-marked like a streetwalker eligible for AARP membership. In the bibliography, the reference "Takeuchi and Nonaka" is carelessly used to refer to two different sources. (I didn't think BibTeX permitted that sort of error to happen?)
The rear cover promises advice on integrating Agile/Scrum with XP techniques, but XP is mentioned only in passing in the actual text. Again, an excess of salesmanship eclipses substance.
Moreover, at points, especially in the concluding chapter, the authors depict Agile/Scrum as an approach which helps flatten organizations and promotes autonomy and self-organization among workers. I'd have thought they could manage to tickle my anarcho-socialist G-spot with this talk, but it was too little too late. (Perhaps this was just more salesmanship, exposed by the tone-deaf choice of the term scrum master to denote the supervisor of/aide to a scrum team--not the way to pitch yourself to the "no gods, no masters" contingent, gentlemen!)
With all that, I can't say I hated it--there is some worthwhile material in here--but I believe the authors missed a market opportunity to publish this title as a book with the profile of a pocket reference. Perhaps they felt compelled to make an evangelical splash; that is strongly suggested by their tone, and this was evidently the first published title on its subject--but software developers are busy people and these days, with so many other "Agile" titles on the market, one can perhaps best make a pitch to that audience by getting to the point, being concise, and then getting out of the way.
Having absorbed Agile/Scrum's key concepts and terminology from this book, I have no plans to read any others on the method. Given the dozen or so other extant Agile/Scrum titles now available, it's a grim world indeed if this one remains the best introduction.
This book, however, is overlong and burdened with sales pitches. If one were to glean the wheat from the chaff, the page count might drop to 50 pages or fewer. Not one but two introductory chapters (following two forewords and a preface) stand in one's way before chapter 3, which is the first to get down to brass tacks. Chapter 4 staggers along with 13 figures, over twice as many than have appeared in the book to that point, but is otherwise practical and useful. Chapter 5 is evidently for the folks with degrees in organizational behavior--which, one infers from its presentation here, is psychology for people who don't want to admit they're studying psychology. Chapter 6 is an aggressive and somewhat tiresome attempt to sell Agile/Scrum to ten different audiences in sequence, concluding with a rugby metaphor--which pivots partway through to an American football metaphor, accompanied by a table which (sneakily or stupidly) changes the order of its columns halfway down--for that mythical reader who can't understand anything else yet has inexplicably read this far. Chapters 7 through 9 are all short and mostly useful, consisting of advice on implementing Agile/Scrum in large organizations, and case studies. A bit more preaching rounds out the excessive length of the text. I have patience for very long books, but this one tried mine so severely that I took five months to get through its mere 159 pages.
Adding insult to injury, the production values are cheap for a title that lists at around forty dollars. The book was typeset using TeX, which normally I like, but the figures are repellently ugly and when the colorful cover image is reproduced in the text at the point where it is introduced and explained, it appears in grayscale--which eviscerates its meaning. I guess Prentice Hall wasn't about to pony up for a color plate.
The index is insufficient, and for no apparent reason a single term appears in a different typeface-- paradigm shift , that clever coinage of Thomas Kuhn's, once young and beautiful, now broken-down, toothless, and track-marked like a streetwalker eligible for AARP membership. In the bibliography, the reference "Takeuchi and Nonaka" is carelessly used to refer to two different sources. (I didn't think BibTeX permitted that sort of error to happen?)
The rear cover promises advice on integrating Agile/Scrum with XP techniques, but XP is mentioned only in passing in the actual text. Again, an excess of salesmanship eclipses substance.
Moreover, at points, especially in the concluding chapter, the authors depict Agile/Scrum as an approach which helps flatten organizations and promotes autonomy and self-organization among workers. I'd have thought they could manage to tickle my anarcho-socialist G-spot with this talk, but it was too little too late. (Perhaps this was just more salesmanship, exposed by the tone-deaf choice of the term scrum master to denote the supervisor of/aide to a scrum team--not the way to pitch yourself to the "no gods, no masters" contingent, gentlemen!)
With all that, I can't say I hated it--there is some worthwhile material in here--but I believe the authors missed a market opportunity to publish this title as a book with the profile of a pocket reference. Perhaps they felt compelled to make an evangelical splash; that is strongly suggested by their tone, and this was evidently the first published title on its subject--but software developers are busy people and these days, with so many other "Agile" titles on the market, one can perhaps best make a pitch to that audience by getting to the point, being concise, and then getting out of the way.
Having absorbed Agile/Scrum's key concepts and terminology from this book, I have no plans to read any others on the method. Given the dozen or so other extant Agile/Scrum titles now available, it's a grim world indeed if this one remains the best introduction.
April 7, 2013
(4.0) Overall nice and concise, fair bit of proselytizing though
As with many methodology books, there's plenty of "really, this works!" and "I saved so many projects that were in the toilet," so just try to skim through those (or omit entirely). The rest is pretty good. You should read chapters 2 (intro--quickly), 3 (how-to), 4 (how-to), 6 (why it works), 7 (multi-team projects) and 9 (core values of scrum).
The core elements to scrum:
* remove distractions and let team focus on demonstratable features/goals
* team commits to its own goals and does what it takes to achieve them
* empower team with flexibility to achieve them
* scrum master/manager fights to remove impediments to the team, rather than charting progress
* demonstrate results at the end (make 'customer' happy, can't fake it)
* adjust as you learn more (budget, team size, expertise, functionality, delivery date...)
One of the much touted advantages (in this book at least) is that scrum lets you see intermediate results 'quickly'...on the order of sprint length (as opposed to many months or years). I happen to work in an environment where we can most often do that within days if not hours, so some of the demonstration stuff to get customer feedback, senior management buy-in feels a little less necessary. I can definitely see how crucial it can be for multi-month endeavors to release new products, however.
I could also see valid criticism of this particular book that success could depend on a) the teams knowing (how) to do things the Right Way, and that b) the scrum master authors are amazingly inspiring leaders who can solve any problems (technical, process, interpersonal) regardless of process.
a) It seems possible that with a less experienced team, leaving them to their own devices could have poor long-term results: lots of code churn and thrashing after a year or so of 'progress'. Without good technical leadership pushing for refactoring, renovating, rearchitecting when appropriate, maintenance can quickly dominate the backlog when the focus is always on delivering threads of functionality. This can also happen if business owners are just really vocal and block technical debt from entering sprints. One thing that can help is if the team keeps an eye on how much of the backlog is turning to maintenance, bugs. But when that approaches, say, 50% and alarms start ringing, the problem is already pretty bad...all the while the team has been ostensibly rocking it with launching new features every sprint. Just by virtue of empowering the team to do whatever it takes, doesn't mean they're going to end up with maintainable code. A less-emphasized point in the book was that it often makes sense to tell engineers that once they write code, they own it for life. I'm not sure that is always feasible, but it can certainly put pressure on quality code production as well.
b) The turnaround examples all seem to be cases where the authors jumped in and turned everything around. How do we know it was scrum that did it? Maybe they were just great leaders. In an environment where self-motivation, flexibility, just-in-time problem solving are the way of working, there's room to go in lots of directions. A good scrum master will need to be able to identify problems when there are fewer quantitative signs that problems exist: the data are essentially what is said during scrum and periodically seeing how burndown is going. It's conceivable that either the key to the success wasn't the process but the leaders themselves, who may have succeeded no matter the process they chose to use, or that scrum is much more demanding on leaders than other methodologies and such leaders are far more difficult to come by. What happens with ineffective leadership under scrum? Whose job is it to mentor/replace scrum master when it's clear he or she is The Problem?
---
One other note on description here on Goodreads: There was precious little about XP-under-scrum in this book...not sure if that came from when XP was 'hot' a decade or so ago or what. It's just kind of irrelevant. If you want to do XP under scrum you can.
As with many methodology books, there's plenty of "really, this works!" and "I saved so many projects that were in the toilet," so just try to skim through those (or omit entirely). The rest is pretty good. You should read chapters 2 (intro--quickly), 3 (how-to), 4 (how-to), 6 (why it works), 7 (multi-team projects) and 9 (core values of scrum).
The core elements to scrum:
* remove distractions and let team focus on demonstratable features/goals
* team commits to its own goals and does what it takes to achieve them
* empower team with flexibility to achieve them
* scrum master/manager fights to remove impediments to the team, rather than charting progress
* demonstrate results at the end (make 'customer' happy, can't fake it)
* adjust as you learn more (budget, team size, expertise, functionality, delivery date...)
One of the much touted advantages (in this book at least) is that scrum lets you see intermediate results 'quickly'...on the order of sprint length (as opposed to many months or years). I happen to work in an environment where we can most often do that within days if not hours, so some of the demonstration stuff to get customer feedback, senior management buy-in feels a little less necessary. I can definitely see how crucial it can be for multi-month endeavors to release new products, however.
I could also see valid criticism of this particular book that success could depend on a) the teams knowing (how) to do things the Right Way, and that b) the scrum master authors are amazingly inspiring leaders who can solve any problems (technical, process, interpersonal) regardless of process.
a) It seems possible that with a less experienced team, leaving them to their own devices could have poor long-term results: lots of code churn and thrashing after a year or so of 'progress'. Without good technical leadership pushing for refactoring, renovating, rearchitecting when appropriate, maintenance can quickly dominate the backlog when the focus is always on delivering threads of functionality. This can also happen if business owners are just really vocal and block technical debt from entering sprints. One thing that can help is if the team keeps an eye on how much of the backlog is turning to maintenance, bugs. But when that approaches, say, 50% and alarms start ringing, the problem is already pretty bad...all the while the team has been ostensibly rocking it with launching new features every sprint. Just by virtue of empowering the team to do whatever it takes, doesn't mean they're going to end up with maintainable code. A less-emphasized point in the book was that it often makes sense to tell engineers that once they write code, they own it for life. I'm not sure that is always feasible, but it can certainly put pressure on quality code production as well.
b) The turnaround examples all seem to be cases where the authors jumped in and turned everything around. How do we know it was scrum that did it? Maybe they were just great leaders. In an environment where self-motivation, flexibility, just-in-time problem solving are the way of working, there's room to go in lots of directions. A good scrum master will need to be able to identify problems when there are fewer quantitative signs that problems exist: the data are essentially what is said during scrum and periodically seeing how burndown is going. It's conceivable that either the key to the success wasn't the process but the leaders themselves, who may have succeeded no matter the process they chose to use, or that scrum is much more demanding on leaders than other methodologies and such leaders are far more difficult to come by. What happens with ineffective leadership under scrum? Whose job is it to mentor/replace scrum master when it's clear he or she is The Problem?
---
One other note on description here on Goodreads: There was precious little about XP-under-scrum in this book...not sure if that came from when XP was 'hot' a decade or so ago or what. It's just kind of irrelevant. If you want to do XP under scrum you can.
October 14, 2007
Can the authors be any more full of themselves?
When I went to such and such company "I" implemented this, "I" established that. I thought agile software development was about the team, not lauding individual accomplishments. An irony the authors seemed to have overlooked.
BTW, have you ever been to a company where agile development just plain failed? Just flat out sucked. I've worked at two companies in the last year where they brought in expensive consultants/analysts to help implement agile dev. and its totally ruining things. People leaving in mass droves. Why? Because of one simple overlooked principle - programmers are people, not robots. You maximize throughput (in theory) because your underlying goal is "to please the stakeholder". The stakeholder becomes your god in this model. Problem is, some people are a kind of aetheist (or don't worship that god) - the kind that has a family and kids, the kind that has life goals that don't include moving up a corporate ladder, the kind that likes be assigned tasks based on ability and interest, not mandate by the "scrum master" (which honestly sounds a bit gay).
Don't get me wrong, agile development (which I call "common sense with buzzwords") will work in certain situations with varying degrees of effectiveness. But its not the silver bullet of software development that so many people claim it to be.
When I went to such and such company "I" implemented this, "I" established that. I thought agile software development was about the team, not lauding individual accomplishments. An irony the authors seemed to have overlooked.
BTW, have you ever been to a company where agile development just plain failed? Just flat out sucked. I've worked at two companies in the last year where they brought in expensive consultants/analysts to help implement agile dev. and its totally ruining things. People leaving in mass droves. Why? Because of one simple overlooked principle - programmers are people, not robots. You maximize throughput (in theory) because your underlying goal is "to please the stakeholder". The stakeholder becomes your god in this model. Problem is, some people are a kind of aetheist (or don't worship that god) - the kind that has a family and kids, the kind that has life goals that don't include moving up a corporate ladder, the kind that likes be assigned tasks based on ability and interest, not mandate by the "scrum master" (which honestly sounds a bit gay).
Don't get me wrong, agile development (which I call "common sense with buzzwords") will work in certain situations with varying degrees of effectiveness. But its not the silver bullet of software development that so many people claim it to be.
April 20, 2013
Perhaps I shouldn't have read this while sick with the flu.
If you're working in an organization that already uses Scrum, or some flavor thereof, then chapters 3–5 offer some useful background. Had I been coming to this book cold, however, it would have been a real slog to learn from. The text is slathered in business jargon and mumbo-jumbo, like this example from page 12:
The situation isn't helped by the low production quality of the book itself. The quotations at the beginnings of chapters and sections are missing their attributions. The illustrations are low-res, MSPaint-esque affairs that don't contribute much to the text anyhow. For example:
It looks like they threw some page dimensions into LaTeX, ran the build command, and then e-mailed the output file to their printer without bothering to look at it first. It's not as bad as an ebook I once bought that contained "chapter heading goes here" placeholder text, but the book still gives off an aroma of, "I paid for this?"
If you're working in an organization that already uses Scrum, or some flavor thereof, then chapters 3–5 offer some useful background. Had I been coming to this book cold, however, it would have been a real slog to learn from. The text is slathered in business jargon and mumbo-jumbo, like this example from page 12:
A fully integrated component design environment leads to rapid evolution of a software system with emergent, adaptive properties resembling the process of punctuated equilibrium observed in biological species.
The situation isn't helped by the low production quality of the book itself. The quotations at the beginnings of chapters and sections are missing their attributions. The illustrations are low-res, MSPaint-esque affairs that don't contribute much to the text anyhow. For example:
It looks like they threw some page dimensions into LaTeX, ran the build command, and then e-mailed the output file to their printer without bothering to look at it first. It's not as bad as an ebook I once bought that contained "chapter heading goes here" placeholder text, but the book still gives off an aroma of, "I paid for this?"
April 29, 2013
Good book on formal Scrum - nice refresher on the "how" and "why" behind Scrum methodology. Would be lying if I said I didn't skim some of it. After a few "case studies" around what's wrong with traditional waterfall methodologies, you get the point. I'm guessing these parts were more interesting when the book initially came out and the whole concept of Scrum was a bit more revolutionary. It's been 12 years since the publish date- which is a long time in technology. (For example, they strongly recommend 30 day release cycles- which seems very slow in today's consumer internet world.) A lot of these practices have become much more commonplace since this came out- which I guess is a credit to the authors. But it might be nice if they came out with an updated version.
With all that said- a lot of good concepts and refreshers in here. Hope to incorporate some of this into our process at GR!
With all that said- a lot of good concepts and refreshers in here. Hope to incorporate some of this into our process at GR!
December 25, 2017
Good, and potentially the "genesis" book on Scrum, written by one of the founding fathers (Ken), and reviewed by another (Jeff). This is the only book I have read so far views Scrum as the solution for chaos, lack-of-focus mostly seen in startups; other materials always describe Scrum vis-à-vis Waterfall in big inflexible corporates only.
It's enlightening to see where/why Scrum events (such as Daily Scrum), artifacts (such as product backlog), and roles (such as Scrum Master) come from, before those entities were clearly defined and named. It's also intriguing to understand why Scrum just works, when with analogous example from viewpoints of sport, military and maritime navigation.
However, I'm quite disappointed about chapter 9, Scrum values, which could have been better.
It's enlightening to see where/why Scrum events (such as Daily Scrum), artifacts (such as product backlog), and roles (such as Scrum Master) come from, before those entities were clearly defined and named. It's also intriguing to understand why Scrum just works, when with analogous example from viewpoints of sport, military and maritime navigation.
However, I'm quite disappointed about chapter 9, Scrum values, which could have been better.
February 1, 2014
I think chunks of this book were excellent and extremely useful, while much of the rest was self-indulgent and repetitive. Coming from a marketing background to a career in technology, it was extremely useful to read chapters 3-5 and 9, but I could have easily skipped over the rest of the book. There are only so many times I can read the author explaining that a company had a bad process, he came in and introduced scrum, and then things worked. But I took some key learnings from those meaningful sections that will influence my work for the better. If you work in any role related to software development, reading those four chapters will be well worth your time.
May 15, 2013
Like most of the people I know who've read this book, I skimmed a good deal of it. It gives a lot of insight into why Scrum is such an attractive method of development (especially for startups), and explains the things that need to be cultivated to allow this process to succeed. In that sense, the book was pretty interesting. However, it wasn't very well written. It seemed like the two authors wrote slightly differently-worded versions of the same ideas, and since this was written in 2004 when very few people had heard of the process, they also spend a lot of time talking up their credentials. This seemed like something they put in to convince 'higher-ups' that Scrum is worth a shot, but isn't really anything that most people care about.
If you're interested In finding out more about how Scrum works, this book is a decent introduction).
If you're interested In finding out more about how Scrum works, this book is a decent introduction).
June 14, 2016
This was the book that changed my career. It was as close to a religious revelation as I have ever had. Up until I read this book I had struggled to deconstruct Waterfall and a number of other serial methodologies in order to overcome their egregious shortcomings. This book clarified and codified so much of my thinking and experience up to that point is was like it was written just for me.
I had my copy of this book signed by Ken Schwaber when I heard him speak at a local development conference. I later gave that copy away to an executive I was committed to convincing to adopt Scrum.
While I know this book is a little dated and Scrum has come a very long way since this first published book on the topic, it is still a great read and a bit of history anyone using Scrum should read.
I had my copy of this book signed by Ken Schwaber when I heard him speak at a local development conference. I later gave that copy away to an executive I was committed to convincing to adopt Scrum.
While I know this book is a little dated and Scrum has come a very long way since this first published book on the topic, it is still a great read and a bit of history anyone using Scrum should read.
October 21, 2009
This book provides a great introduction to the Agile development process which is really Getting Things Done for business. It has changed the way I want to structure organizations around me and has amazing strategies. I highly recommend this book.
June 18, 2019
I thought I worked in agile working environments for almost 10 years now, I should know enough. I do not and it is refreshing to revisit what scrum is.
First here are the languages and terminologies:
Scrum:
Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs.
Product backlog:
The product backlog is a prioritized list of all product requirements. Product backlog is never finalized. Only the Product owner can prioritize the backlog.
Scrum Master:
The person that manages the scrum process in an organization.
Scrum Teams:
A team commits to achieving a Sprint goal. The team is accorded full authority to do whatever it decides is necessary to achieve the goal.
Daily Scrum Meetings:
Software development is a complex process that requires lots of communications. The daily scrum meeting is where the team comes to communicate.
Sprint:
The team works for a fixed period of time called a Sprint.
Some highlights I liked:
Scrum is based on the empirical process control model. One of the fundamental principles of scrum is “the art of the possible.” That is, scrum instructs teams not to dwell on what can’t be done, but to think about what can be done.
The estimate does not mean, “this is how much time there is to build this functionality, and no more.” The estimate is a starting point, a best guess, from which the sprint can be empirically constructed and managed.
If a team member identifies something that is stopping him or her from working effectively, the Scrum Master is responsible for recording and removing that impediments. Examples of impediments are:
Unsure about how to proceed
Unsure of design decision
Unsure how to use technology
Management is primarily responsible for doing anything possible to increase team productivity and then adapting to the results. Scrum provides direct visibility into the progress of the project.
There are no mechanisms in Scrum for tracking the amount of time that a team works. Teams are measured by meeting goals, not by how many hours they take to meet the goal. Scrum is result oriented, not process oriented.
Why scrum and why scrum works?
Empirical process control models are elegantly simple. They employ feedback mechanism to monitor and adapt to the unexpected, providing regularity and predictability.
I is input, or requirements, technology
Process is Sprint
C is the control unit that monitors the scrum progress at daily scrum meetings and at the end of each Sprint
O is the incremental product built during each iteration.
My favorite part of the book is a reference to Eli Goldratt when describing the system dynamics view of Scrum:
"Inventories cost money, so having “idle” money sitting somewhere is never a good idea. On the other hand, not having enough raw materials at any given time can effectively stop a production line. So having minimal but sufficient inventories is ideal. "
Developer’s time can be seen as inventory and issues impeding developer’s time can be seen as lack of inventory of another resource.
Scrum provides feedback cycles at different levels of scale:
Measuring all resource inventory levels constantly and changing fast in small amounts how developers use their time.
First here are the languages and terminologies:
Scrum:
Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs.
Product backlog:
The product backlog is a prioritized list of all product requirements. Product backlog is never finalized. Only the Product owner can prioritize the backlog.
Scrum Master:
The person that manages the scrum process in an organization.
Scrum Teams:
A team commits to achieving a Sprint goal. The team is accorded full authority to do whatever it decides is necessary to achieve the goal.
Daily Scrum Meetings:
Software development is a complex process that requires lots of communications. The daily scrum meeting is where the team comes to communicate.
Sprint:
The team works for a fixed period of time called a Sprint.
Some highlights I liked:
Scrum is based on the empirical process control model. One of the fundamental principles of scrum is “the art of the possible.” That is, scrum instructs teams not to dwell on what can’t be done, but to think about what can be done.
The estimate does not mean, “this is how much time there is to build this functionality, and no more.” The estimate is a starting point, a best guess, from which the sprint can be empirically constructed and managed.
If a team member identifies something that is stopping him or her from working effectively, the Scrum Master is responsible for recording and removing that impediments. Examples of impediments are:
Unsure about how to proceed
Unsure of design decision
Unsure how to use technology
Management is primarily responsible for doing anything possible to increase team productivity and then adapting to the results. Scrum provides direct visibility into the progress of the project.
There are no mechanisms in Scrum for tracking the amount of time that a team works. Teams are measured by meeting goals, not by how many hours they take to meet the goal. Scrum is result oriented, not process oriented.
Why scrum and why scrum works?
Empirical process control models are elegantly simple. They employ feedback mechanism to monitor and adapt to the unexpected, providing regularity and predictability.
I is input, or requirements, technology
Process is Sprint
C is the control unit that monitors the scrum progress at daily scrum meetings and at the end of each Sprint
O is the incremental product built during each iteration.
My favorite part of the book is a reference to Eli Goldratt when describing the system dynamics view of Scrum:
"Inventories cost money, so having “idle” money sitting somewhere is never a good idea. On the other hand, not having enough raw materials at any given time can effectively stop a production line. So having minimal but sufficient inventories is ideal. "
Developer’s time can be seen as inventory and issues impeding developer’s time can be seen as lack of inventory of another resource.
Scrum provides feedback cycles at different levels of scale:
Measuring all resource inventory levels constantly and changing fast in small amounts how developers use their time.
July 16, 2017
Sure, before you grapple with this seminal, little book you should have studied a more recent account of Scrum’s practices (those you find on www.scrumguides.org and scrumprimer.org are brief, rigorous and updated), as the exposition here is mostly interesting for comparative, historical reasons. And, of course, Schwaber is a true believer in the method he nurtured, and -sometime- often he waxes lyrical about it.
Yet the lively anecdotes about how Scrum rules at first emerged tackling some real, hopeless situations are still relevant and help getting a fuller sense out of them.
Most of all, the discussion of the relationships of Scrum with process control theory [*] and with the crucial mind shift from «software development as manufacturing» to «software development as new product development» (which clarifies its tie with the renowned Takeuchi and Nonaka 1986 paper, hbr.org/1986/01/the-new-new-product-d...) is enlightening and, worryingly, I never ran into anything similar elsewhere. Scrum practitioners really need to read chapter 5 and 6, even if some of the ideas are definitely half-baked.
==
[*] He convincigly argues that traditional methods for controlling software development (for example, PMI-style methods) make the mostly false assumption that software development is a defined process, while it’s a complex process instead: «A project’s noise category indicates what approach should be employed for managing the project and building the system. There are two approaches in process control theory to control and manage processes. The first model is called the defined process control model.
When processes are simple, with unobtrusive noise, I can write a definition of how they work and use this definition to repeat the processes over and over, each time generating the same results. These are called defined processes. Management and control is exercised by defining the processes so well that everything is known and predictable.
Management and control arise from the predictability of defined processes. Since the processes are defined, they can be grouped together and be expected to continue to operate predictably and repeatably. In such clusters of processes, the defined process control model can be used for modeling and controlling such simple systems as traffic lights, or such involved but defined systems as manufacturing pharmaceuticals.
Almost no systems development project is so simple, has so little noise, for the defined process control model to be appropriate by itself.
If the process cannot be described in enough detail to be repeated, if there is so much complexity that any attempt to model the process results in different outcomes, the process is called a complex process. If I operate a complex process two times in a row, the results are more likely to be different than the same. The activities in the process are so noisy that their output cannot be predicted with an adequate degree of reliability. Empirical process control models are used to manage and control complex processes. Management and control is exercised through frequent inspection and adaptive response.»
Yet the lively anecdotes about how Scrum rules at first emerged tackling some real, hopeless situations are still relevant and help getting a fuller sense out of them.
Most of all, the discussion of the relationships of Scrum with process control theory [*] and with the crucial mind shift from «software development as manufacturing» to «software development as new product development» (which clarifies its tie with the renowned Takeuchi and Nonaka 1986 paper, hbr.org/1986/01/the-new-new-product-d...) is enlightening and, worryingly, I never ran into anything similar elsewhere. Scrum practitioners really need to read chapter 5 and 6, even if some of the ideas are definitely half-baked.
==
[*] He convincigly argues that traditional methods for controlling software development (for example, PMI-style methods) make the mostly false assumption that software development is a defined process, while it’s a complex process instead: «A project’s noise category indicates what approach should be employed for managing the project and building the system. There are two approaches in process control theory to control and manage processes. The first model is called the defined process control model.
When processes are simple, with unobtrusive noise, I can write a definition of how they work and use this definition to repeat the processes over and over, each time generating the same results. These are called defined processes. Management and control is exercised by defining the processes so well that everything is known and predictable.
Management and control arise from the predictability of defined processes. Since the processes are defined, they can be grouped together and be expected to continue to operate predictably and repeatably. In such clusters of processes, the defined process control model can be used for modeling and controlling such simple systems as traffic lights, or such involved but defined systems as manufacturing pharmaceuticals.
Almost no systems development project is so simple, has so little noise, for the defined process control model to be appropriate by itself.
If the process cannot be described in enough detail to be repeated, if there is so much complexity that any attempt to model the process results in different outcomes, the process is called a complex process. If I operate a complex process two times in a row, the results are more likely to be different than the same. The activities in the process are so noisy that their output cannot be predicted with an adequate degree of reliability. Empirical process control models are used to manage and control complex processes. Management and control is exercised through frequent inspection and adaptive response.»
February 13, 2025
I am a fan of Scrum, I’ve seen it work and it can benefit most development processes. But this book did not enhance my understanding nor do I believe it would encourage anyone to use the process. It comes across as a big advertisement, the author glosses over problems, he points to advantages that are not unique to Scrum, and generally fails to provide any concrete examples of why I should use Scrum.
The book does a good job of describing Scrum, its components, and to provide a basis for using the process. This is covered in the first 1/3 of the book. I believe that most readers should stop at this point. The rest of the book explains why Scrum works, its value, and advanced topics. But these aren’t convincing and I don’t see a real correlation to Scrum.
Then there are the contradictions.
The authors explain how having a technical writer on the team can relieve the developers of writing the documentation – which is required for the sprint delivery, and how including a tester so the developers don’t have to test their own code. Yet, two paragraphs later he talks about people being interchangeable, “Scrum avoids people who refuse to code”, there are no titles, no exceptions. And in one of his case studies he mentions the advantage he gained by putting off documentation until later in the project.
Later in the book, a case study talks about a design architect who is referred to as female in one sentence and male in the next. An earlier case study talked about an architect who left the project due to lack of control, and how not having an architect was a bonus for Scrum.
They mention the value of getting engineers into “flow”. Yet also insists that engineers work in bullpens, and that the lack of conversation indicates a poorly working team. They seem to believe that getting into the zone is free. In a later study, he talks about the advantage of having engineers in adjacent cubicles so that they only need to stand and talk over the cubicle wall.
Other suggestions include deferring peer reviews until after a sprint – “they have nothing to do with completing the project.”
Even the cover tie-in feels weak. (I have the cover with the psychology test where you identify colors of text indicating names of different colors.) He uses this text to illustrate the need for a team to focus. That consumes about 1.5 pages.
Apparently, applying Scrum practices to writing this book failed. They could have used a good editor and some better reviewers. They often aren’t clear on what practices are really important to Scrum. If I hadn’t practiced Scrum, this book would not help move me toward trying or even supporting the practice.
The book does a good job of describing Scrum, its components, and to provide a basis for using the process. This is covered in the first 1/3 of the book. I believe that most readers should stop at this point. The rest of the book explains why Scrum works, its value, and advanced topics. But these aren’t convincing and I don’t see a real correlation to Scrum.
Then there are the contradictions.
The authors explain how having a technical writer on the team can relieve the developers of writing the documentation – which is required for the sprint delivery, and how including a tester so the developers don’t have to test their own code. Yet, two paragraphs later he talks about people being interchangeable, “Scrum avoids people who refuse to code”, there are no titles, no exceptions. And in one of his case studies he mentions the advantage he gained by putting off documentation until later in the project.
Later in the book, a case study talks about a design architect who is referred to as female in one sentence and male in the next. An earlier case study talked about an architect who left the project due to lack of control, and how not having an architect was a bonus for Scrum.
They mention the value of getting engineers into “flow”. Yet also insists that engineers work in bullpens, and that the lack of conversation indicates a poorly working team. They seem to believe that getting into the zone is free. In a later study, he talks about the advantage of having engineers in adjacent cubicles so that they only need to stand and talk over the cubicle wall.
Other suggestions include deferring peer reviews until after a sprint – “they have nothing to do with completing the project.”
Even the cover tie-in feels weak. (I have the cover with the psychology test where you identify colors of text indicating names of different colors.) He uses this text to illustrate the need for a team to focus. That consumes about 1.5 pages.
Apparently, applying Scrum practices to writing this book failed. They could have used a good editor and some better reviewers. They often aren’t clear on what practices are really important to Scrum. If I hadn’t practiced Scrum, this book would not help move me toward trying or even supporting the practice.
March 12, 2018
Definitely one of the eye-opening book to read. The book might benefit from better structuring. After skimming, I decided the order that would work for me would be Chapter 6 - 1 - back to 7.
As an outsider I expected the authors to have more thorough literature review of alternative approach to Agile, before making a case for Agile. A few terms like "empirical method" are used extensively but I didn't not find proper definition of it (it could be that I was reading very fast) - but it was used in te first pages without clear definition, and possibly expected readers to be familiar with it already.
In all fairness, I still learned new approach from this book that can be applicable way beyond software development, so time definitely well spent.
As an outsider I expected the authors to have more thorough literature review of alternative approach to Agile, before making a case for Agile. A few terms like "empirical method" are used extensively but I didn't not find proper definition of it (it could be that I was reading very fast) - but it was used in te first pages without clear definition, and possibly expected readers to be familiar with it already.
In all fairness, I still learned new approach from this book that can be applicable way beyond software development, so time definitely well spent.
May 3, 2018
Ken Schwaber and Mike Beedle introduced empirical process control to modern software application development. Now there's close to 20 years of success and amazing stories about Agile/Scrum. It works, it's transformative, it scales really well and can be applied to almost any project, any platform.
I'd rate the book 5 out of 5 stars, but there were a few areas toward the back of the book where I was like WTF are they talking about. But overall this is an amazing book and one that all software developers should read and keep handy - whether you're a Scrum Master or not.
I'd rate the book 5 out of 5 stars, but there were a few areas toward the back of the book where I was like WTF are they talking about. But overall this is an amazing book and one that all software developers should read and keep handy - whether you're a Scrum Master or not.
October 10, 2017
Great book that helps you to believe the this can be done! The reader learns that others have felt their scrum pain and that there are ways to work through the anguish. The authors are quite experienced in the land of Agile and bring a candid perspective to making it work.
May 5, 2017
Great overview on Agile with interesting case studies with large environments. A great read for someone interested in Agile or who is looking to start using Agile in their careers.
Read
April 19, 2020A classic by one of the creators of Scrum. Read it to get the original ideas behind Scrum.
June 10, 2022
A bit dull, but a great reference with plenty of stories about why Scrum rocks!
September 29, 2023
Seminal book that contains all about Scrum and the original sources. Somehow, however, the Sprint Retrospective was not invented yet in 2001.
August 21, 2010
This isn't the best book out there about Agile or Scrum. (I'm not sure which book is the best, but it's definitely not this one.)
If you're interested less in how to apply Scrum and more in the authors' personal experiences in discovering Scrum and why they think it's a good idea, then this could be an okay book. If they had any experiences where Scrum didn't work spectacularly, though, those aren't included here.
It's particularly intriguing that in the Introduction chapter, when discussing introducing Scrum across several teams in a large organisation, Jeff Sutherland says, "While most teams were only able to meet the industry average in function points per month delivered, several teams moved into a hyper productive state producing deliverable functionality at 4-5 times the industry average." I'd really love to hear what the differences were between the average any hyper-productive teams--why Scrum worked so well for some but not others. But the answer is absolutely not in this book. This book is only about success.
Also, I agree with other reviewers about the poor editing--there are definitely places where things don't even make any sense at all.
If you're interested less in how to apply Scrum and more in the authors' personal experiences in discovering Scrum and why they think it's a good idea, then this could be an okay book. If they had any experiences where Scrum didn't work spectacularly, though, those aren't included here.
It's particularly intriguing that in the Introduction chapter, when discussing introducing Scrum across several teams in a large organisation, Jeff Sutherland says, "While most teams were only able to meet the industry average in function points per month delivered, several teams moved into a hyper productive state producing deliverable functionality at 4-5 times the industry average." I'd really love to hear what the differences were between the average any hyper-productive teams--why Scrum worked so well for some but not others. But the answer is absolutely not in this book. This book is only about success.
Also, I agree with other reviewers about the poor editing--there are definitely places where things don't even make any sense at all.
June 24, 2013
This is a good introduction to Agile Scrum, provided you are already working in the software development business and are reasonably au fait with business terminology. I wouldn't recommend it to an industry outsider as a first glimpse of what Agile Scrum can do for them, because it would likely send them to sleep. However, as a working manual for someone using Agile Scrum, it's perfectly adequate.
I have to concur with other reviewers, however, in regards to the poor publishing quality of the book. The so-called 'diagrams' look like they were created in MS Paint circa 1992, which doesn't exactly scream "modern" (a shame, considering that uptake for Scrum and Agile has only really peaked in the last few years). It could do with being broken out into more manageable paragraphs as well, perhaps with case studies in separate boxes away from the main text.
Overall, good enough for what it is - but I wouldn't advise buying a copy for a prospective client or co-worker in order to convert them to the ways of Agile Scrum. A decent enough manual it may be, but an evangelical book it ain't.
I have to concur with other reviewers, however, in regards to the poor publishing quality of the book. The so-called 'diagrams' look like they were created in MS Paint circa 1992, which doesn't exactly scream "modern" (a shame, considering that uptake for Scrum and Agile has only really peaked in the last few years). It could do with being broken out into more manageable paragraphs as well, perhaps with case studies in separate boxes away from the main text.
Overall, good enough for what it is - but I wouldn't advise buying a copy for a prospective client or co-worker in order to convert them to the ways of Agile Scrum. A decent enough manual it may be, but an evangelical book it ain't.
November 5, 2009
SCRUM is a process I had heard a lot about but I hadn't ever really learned about. I'm glad I did learn about it, how it works and how it came about.
The main idea is to enable development teams to focus on development without distractions or interruptions from management or anywhere else.
The most helpful part was the section on empirical process control and how such an approach is the only way to deal with creative development. The defined process approach can never work; despite what they may have taught in school.
Some of the writing in this book is quite lacking. There were many sentences and sometimes even entire paragraphs that flat out didn't make sense. Also other times it felt like a concept was just abruptly dropped halfway through the explanation.
The main idea is to enable development teams to focus on development without distractions or interruptions from management or anywhere else.
The most helpful part was the section on empirical process control and how such an approach is the only way to deal with creative development. The defined process approach can never work; despite what they may have taught in school.
Some of the writing in this book is quite lacking. There were many sentences and sometimes even entire paragraphs that flat out didn't make sense. Also other times it felt like a concept was just abruptly dropped halfway through the explanation.
July 22, 2009
I suppose it is one of the first books about Scrum and mandatory for anyone doing Scrum. Especially since the author Ken Schwaber is one of the most prominent figures up there in the Scrum Olymp.
Personally I think that regarding info and writing there are better books. He does explains the ideas, values and principles of Scrum and gives examples. But still, I much preferred reading "Scrum from the Trenches" fror example or any of the books by Mike Cohn.
I'll also try out Boris Gloger Scrum handbook and see if he does it better.
Also, the graphics could have been a lot better. Look like they were done with pre-'Word' text programme on a C64 ca 1985.
Personally I think that regarding info and writing there are better books. He does explains the ideas, values and principles of Scrum and gives examples. But still, I much preferred reading "Scrum from the Trenches" fror example or any of the books by Mike Cohn.
I'll also try out Boris Gloger Scrum handbook and see if he does it better.
Also, the graphics could have been a lot better. Look like they were done with pre-'Word' text programme on a C64 ca 1985.
October 30, 2015
Re-reading this after several years of agile software development projects of varying complexity. It was good to get a refresher on the key areas of Scrum and some of the not-so-obvious reasons why they cannot be ignored. Schwaber gives several real life examples that illustrate both the problems that many companies face and the benefits of Scrum. He includes many suggestions for handling large multi-team projects with Scrum.
July 23, 2016
Although some practices and Scrum itself evolved a lot since this book was published in 2001 it's still an incredible read. It gives you a glimpse into the early days and explains how Scrum is founded on empirical process control model and why it works. The last chapter discusses Scrum Values a concept that made it's way to the Scrum Guide in 2016.
Don't get discouraged by the negative reviews - it's not a book on HOW to do Scrum (in 2016+) but WHY.
Don't get discouraged by the negative reviews - it's not a book on HOW to do Scrum (in 2016+) but WHY.
November 15, 2008
Bloated with useless acronyms, unnecessary graphs, and cumbersome sentences. Poorly organized and poorly written. Where the hell was the editor?
Scrum's a useful software development methodology, but it's not well presented here.
Scrum's a useful software development methodology, but it's not well presented here.
August 6, 2009
A quick read, Agile Software Development with SCRUM provides a practical introduction to the methodology, emphasizing the value delivered by the ideology while explaining scrum process mechanics. This is the first book I give to folks I'm bringing into the process.
October 19, 2009
This is the book that changed my whole attitude to software development. The ideas were similar to my own thinking, but it was pleasing to find all the ideas summed up and put into a working framework.
April 22, 2012
Yes, the initial book on Scrum so it's 5/5 for the thinking, the ideas, the change it started. The book itself, is not an easy read, is not very consistent and some of the thinking have now moved on, better to read software in 30 days these days methinks.
Displaying 1 - 30 of 58 reviews