What do you think?
Rate this book
Agile Project Management with Scrum
The rules and practices for Scrum―a simple process for managing complex projects―are few, straightforward, and easy to learn. But Scrum’s simplicity itself―its lack of prescription―can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-creator and evangelist Ken Schwaber identifies the real-world lessons―the successes and failures―culled from his years of experience coaching companies in agile project management. Through them, you’ll understand how to use Scrum to solve complex problems and drive better results―delivering more valuable software faster.
Gain the foundation in Scrum theory―and practice―you need
Gain the foundation in Scrum theory―and practice―you need
192 pages, Paperback
Published February 11, 2004
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 86 reviews
Read
May 10, 2009Agile makes software development a human activity, instead of the stressful, pressured, life-eating occupation it often turns into. Agile and Scrum allow us to act as whole people in our professions, responsible, creative, fulfilled, respected.. and still actually have decent mental health and time for a social life. Agile streamlines projects into creating what is actually needed, and reduces risk by building in lots of inspect-and-give-feedback opportunities and reprioritizing work as changes occur. It's intuitive. It's a breath of fresh air. I feel free again, and empowered to succeed.. no longer getting beaten down by crushing top-down waterfall management. Agile cuts through the red tape and focuses everyone on the crux of the matter: the clearest predictor of success in a project is the PEOPLE you have with you.
September 6, 2014
An excellent, readable, brief introduction to Scrum. Only Chapter 1 is devoted to the theory of Scrum; the rest of the book respects the author's strong view that Scrum can't be learned by studying the theory--a team must apply it to a practical situation in order to truly get a handle on Scrum. Schwaber accepts the limitations of the book format by turning quickly to case studies, showing how Scrum has been applied in various complex situations, including how Scrum has been mangled in its application and what lessons can be learned from those manglings.
July 7, 2010
Would have preferred less "bad situation + Scrum = good situation" type rah-rah anecdotes. Common pitfalls, a deeper discussion of tensions in applying the framework to different types of organizations and situations, and an exploration of different methodologies that still fit within the Scrum framework would have been preferred.
August 3, 2018
One of the best books I have read on general project management.
I like that it has many examples that make the theory more pragmatic and feel the general Scrum techniques could help many projects delivering more in general.
I wrote project management instead of scrum because I think good project management in general works a lot like it is described here, not just if you want to work by agile paradigms. So a lot to learn for everybody, clear structure that makes a read though and just picking your pieces valuable and a praxis oriented foundation. What‘s not to like?
I like that it has many examples that make the theory more pragmatic and feel the general Scrum techniques could help many projects delivering more in general.
I wrote project management instead of scrum because I think good project management in general works a lot like it is described here, not just if you want to work by agile paradigms. So a lot to learn for everybody, clear structure that makes a read though and just picking your pieces valuable and a praxis oriented foundation. What‘s not to like?
Read
August 19, 2018I found a few things interesting (so far):
- Sprint planning meetings time boxed at 8 hours, even with a 30 day sprint! We are drastically different at ISC, and take a whole week on the PSC side to get a sprint planned and committed to. I think we can reduce that two a day and gain a whole bunch of dev time back.
- Help documentation counts towards the definition of 'done' in a sprint.
- Scrum is much more than the framework, it's more about the philosophy. Self-organization, ownership, empirical process control (visibility, inspection, adaptation). You can modify the mechanics in line with that philosophy to adapt to challenging situations, such as distributed teams, multiple scrums (scrum of scrums), interdependent portfolio, etc.
- Ideas for sprint review meetings: trade show format; use as opportunity to report out to leadership (vs. emails and other meetings); invite customers; knowledge sharing with other scrum teams.
- Sprint planning meetings time boxed at 8 hours, even with a 30 day sprint! We are drastically different at ISC, and take a whole week on the PSC side to get a sprint planned and committed to. I think we can reduce that two a day and gain a whole bunch of dev time back.
- Help documentation counts towards the definition of 'done' in a sprint.
- Scrum is much more than the framework, it's more about the philosophy. Self-organization, ownership, empirical process control (visibility, inspection, adaptation). You can modify the mechanics in line with that philosophy to adapt to challenging situations, such as distributed teams, multiple scrums (scrum of scrums), interdependent portfolio, etc.
- Ideas for sprint review meetings: trade show format; use as opportunity to report out to leadership (vs. emails and other meetings); invite customers; knowledge sharing with other scrum teams.
This entire review has been hidden because of spoilers.
December 27, 2014
I read the book. This was purely because my previous project followed agile. The book is a collection of events, is it the best way to start? Not sure. There are other Scrum Books which can give you the grasp of Scrum and then may be read this book for understanding how or what can happen. At that point, this is a good book. Start of with other Agile/Scrum books / cards and then come to this.
October 17, 2013
May be a bit dated now, but still some great stories to describe how people live in the Scrum framework.
March 9, 2023
Scrum is a simple framework with simple rules and practices to build products in complex environments.
Despite Scrum's simplicity, its lack of prescription can be disarming, and new practitioners revert to old project management tools and habits.
A series of stories illustrate the responsibilities and typical problems that Product Owners, Scrum Masters, and Teams face. Throughout each section, there is a brief, concise story followed by a lessons learned section that summarizes the various points made.
As a result of his years of experience coaching companies in agile project management, Scrum co-creator, and evangelist Ken Schwaber offers this series of case studies in Scrum to help you really understand it, always remembering that this is a 2004 book.
This book covers crucial subjects to help you gain a foundation in Scrum theory and practice:
- Rein in even the most complex, unwieldy projects
- Effectively manage unknown or changing product requirements
- Simplify the chain of command with self-managing development teams
- Obtain customer feedback and clearer specifications
- Greatly reduce project planning time and required tools
- Avoid missteps by regularly inspecting and fine-tuning projects
- Support multiple teams on a large-scale project from many locations
Scrum is an agile framework for managing and completing complex projects.
It is a process that helps teams work together to deliver products incrementally and continuously.
The Scrum framework includes roles such as the Product Owner, Scrum Master, and Development Team, as well as ceremonies such as Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
The book provides an in-depth understanding of the Scrum framework, including its principles, roles, ceremonies, and artifacts.
It also includes tips and best practices for implementing Scrum in an organization and dealing with common challenges.
The book is intended for project managers, team leads, and anyone else involved in managing projects using the Scrum framework.
These topics will help you learn how to use Scrum to solve complex problems and deliver better results.
There is only one chapter in the book devoted to the theory of Scrum. The rest of the book adheres to the author's opinion that knowledge of Scrum cannot be gained by studying theory, but by putting it into practice.
This is part of my collection of book notes at https://www.williammeller.com/p/all-b...
Despite Scrum's simplicity, its lack of prescription can be disarming, and new practitioners revert to old project management tools and habits.
A series of stories illustrate the responsibilities and typical problems that Product Owners, Scrum Masters, and Teams face. Throughout each section, there is a brief, concise story followed by a lessons learned section that summarizes the various points made.
As a result of his years of experience coaching companies in agile project management, Scrum co-creator, and evangelist Ken Schwaber offers this series of case studies in Scrum to help you really understand it, always remembering that this is a 2004 book.
This book covers crucial subjects to help you gain a foundation in Scrum theory and practice:
- Rein in even the most complex, unwieldy projects
- Effectively manage unknown or changing product requirements
- Simplify the chain of command with self-managing development teams
- Obtain customer feedback and clearer specifications
- Greatly reduce project planning time and required tools
- Avoid missteps by regularly inspecting and fine-tuning projects
- Support multiple teams on a large-scale project from many locations
Scrum is an agile framework for managing and completing complex projects.
It is a process that helps teams work together to deliver products incrementally and continuously.
The Scrum framework includes roles such as the Product Owner, Scrum Master, and Development Team, as well as ceremonies such as Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
The book provides an in-depth understanding of the Scrum framework, including its principles, roles, ceremonies, and artifacts.
It also includes tips and best practices for implementing Scrum in an organization and dealing with common challenges.
The book is intended for project managers, team leads, and anyone else involved in managing projects using the Scrum framework.
These topics will help you learn how to use Scrum to solve complex problems and deliver better results.
There is only one chapter in the book devoted to the theory of Scrum. The rest of the book adheres to the author's opinion that knowledge of Scrum cannot be gained by studying theory, but by putting it into practice.
This is part of my collection of book notes at https://www.williammeller.com/p/all-b...
December 15, 2018
Probably the most important takeaway for me was that this book took me back to the starting point of the entire Agile movement and helped me clearly understand where Agile stems from - i.e. (1) software development is unbelievably complex, and (2) Agile was born to address that complexity by the deceptively simple process of Inspect & Adapt. This is important because too many Agile practitioners focus on the how's rather than the why's of what they do and get easily lost in the technicalities of their practices. Retrospectively, all of this seems pretty obvious and straightforward. However, we quite often forget what is pretty obvious and straightforward, don't we? This book from one of the original founders of Agile brings us back to where it all started. Yes, it is true that this book sometimes sounds like an advertisement, but, hey, when you're a lone voice in a wilderness, you're bound to raise your voice quite a bit and try to sound like a prophet.
April 12, 2020
It is interesting how to apply Scrum in different circumstances. The main outline, as for me is this works for projects with defined tasks, goals but not for projects with fixed-price budgets, strict deadlines, and uncertainty in what has to be delivered. This method also doesn't guarantee any deliveries, so if tasks are large and the team cannot deliver, this approach simply doesn't work. Use Scrum only when boundaries are defined for 70%+, you understand what should be as a result and you can predict, estimate, separate deliveries. The previous list is where the complexity lays, not in the technical delivery itself.
June 19, 2020
Valuable practical advise in the spirit of Scrum
I enjoyed this book!
The first chapter is very information-dense and describes how Scrum works and why.
The other chapters are mostly war stories which describe how to deal with practical situations (in the spirit of Scrum), which I found very valuable.
Even though it's an old book, the majority of it still holds today. There have been some changes though (like the views on Scrum of Scrums and the reference to pigs and chickens; See the Scrum Guide revisions for more details). Furthermore, reading the appendix A raised some eyebrows several times, I would rather refer to the Scrum Guide instead.
I enjoyed this book!
The first chapter is very information-dense and describes how Scrum works and why.
The other chapters are mostly war stories which describe how to deal with practical situations (in the spirit of Scrum), which I found very valuable.
Even though it's an old book, the majority of it still holds today. There have been some changes though (like the views on Scrum of Scrums and the reference to pigs and chickens; See the Scrum Guide revisions for more details). Furthermore, reading the appendix A raised some eyebrows several times, I would rather refer to the Scrum Guide instead.
March 29, 2018
The book presents set of case studies from companies/projects that were adopting SCRUM. I liked how stories are organised and that there are always "Lessons learned". However, some of the case studies I found a bit boring/superficial. I also noticed, the author sees scrum master as a person conducting daily scrum (person enforcing order of asking questions, to whom people are reporting) which is a practice rather avoided nowadays. Just something worth being aware of while reading.
March 8, 2018
I would agree with other reviewers in saying the book is a bit dated by now. But I still would say that many of the case studies presented in the book are still valid nowadays. I would recommend this book to any ScrumMaster wanting to learn more about the practicalities of a Scrum implementation in different circumstances.
A worth read, with concise and straightforward language.
A worth read, with concise and straightforward language.
March 4, 2018
As an aspiring agile product manager you might find yourself in a place
where you need to bring the rest of the organisation along with you on
the journey towards agile, so agile project management skills often come
in handy.
where you need to bring the rest of the organisation along with you on
the journey towards agile, so agile project management skills often come
in handy.
September 14, 2018
A quick lightweight introduction to the mysteries of Scrum that does a decent job of selling the benefits of it as a process and some techniques to making effective use of the methodology.
If you are in the field and don't know anything about Scrum, this book is a good place to start.
If you are in the field and don't know anything about Scrum, this book is a good place to start.
Read
January 3, 2022Хорошие основы скрама в приложениях, а в основной части книги много историй о том, с какими сложностями можно столкнуться при внедрении и какие профиты получить в случае успеха. В одной из последних глав интересный пример масштабирования скрама.
January 25, 2022
Overall a good selection of case studies in Scrum, but goes off the rails pretty quickly in one case study in which the author boasts about how he gave the SSN of a team member on vacation to a PI to track him down. That’s a pretty significant breach of ethics.
December 9, 2017
Great book by one of the originators of SCRUM. Outlines all the principles and reinforces them w/ story like case studies.
February 12, 2018
I love his books. Ken is the baseline of scrum. go for it!
August 15, 2018
Case studies to understand/apply agile scrum project management
November 12, 2018
Good book to get a history of how scrum was used and proven in the late 90s and early 2000s. This is recommended reading from scrum.org for PSM2 and PSM3 certification tests.
September 14, 2019
A little dated but this can be overcome by reading the scrum guide. It is also a book seeking the idea of scrum with some ideas of what can go wrong.
October 6, 2019
Gutes, kurzweiliges Buch mit verschiedenen Fallstudien. Es ist durchaus inspirierend, manche Abschnitte bieten (mir?) aber auch wenig Mehrwert.
October 10, 2016
As complexity of the tasks increases, the central control system breaks down.
Scrum is built on 30 day learning cycle to prove a complete business cycle. Helps us learn rapidly. In one scrum cycle of 30 days, a software is built, tested, integrated and the most important of all, released to production.
Scrum is a process to manage complex projects. It does not describe what to do in every situation. It provides a framework and set of guiding principles, instead.
*** Common sense is a combination of experience, training, humility, wit and intelligence.
Software development is a complex process. The complexity and the issues that arise during development process can be resolved with hard work, intelligence and courage.
To take control of a complicated process, the empirical approach should be used.
How to implement a process using empirical process control mechanism?
1. Visibility - The aspects which affect the outcome must be visible to those who are controlling the process.
2. Inspection - To detect unacceptable variances in the process.
3. Adaptation - If after inspection it is found that some aspects of the products are not within acceptable limits, changes should be made.
Most significant aspects of software development - 1. Requirements 2. Technology 3. People
Heart of Scrum -
Product Backlog - Iteration - 24 hour inspection - Increment of functionality -- At the start of an iteration, the team reviews what it must do. It then selects which functionality it can convert into shippable product in one increment. Team, then starts working on the iteration. At the end of the iteration, team presents its output to the stakeholders. Stakeholders inspect the functionality and timely adaptations are made, based on that. This artifact is never complete, it evolves over time based on sprint progress and business requirements.
Scrum roles - Product Owner, Team, Scrum master
Product Owner - represents the stake holders, gets the funding, keeps the cashflow. PO uses Product Backlog (list of requirements), prioritizes it.
Team - It works on the product backlog on iterative basis. It is self-managing, self-organizing, independent and cross-functional.
ScrumMaster - teaches Scrum to the team members and product owner. facilitates the progress of the sprint.
Product Owner + Team + Scrum Master are people who are committed to the project. They have complete authority to take decisions to ensure success of the project.
Scrum flow -
It all starts with a vision. The Product Owner converts the vision into a list of functional and non functional requirements, called Product Backlog. PB(not Peanut Butter) is prioritized based on the value generating items coming on top. The top priority items are divided into proposed releases.
All work is done in Sprints. Each sprint is of 30 consecutive days. Each sprint starts with a sprint planning meeting, which can last maximum of 8 hours. In this meeting, the team and Product Owner decide on the items from the product backlog that can be completed in one sprint.
More about the Sprint planning meeting - First four hours - the team and PO decide the items to completed during the sprint.
Next four hours - the team plans the sprints based on the commitments made to the PO.
Daily Scrum - 15-min meeting every day, only for team members. Every team member answers three questions - 1. What have you done since the last meeting? 2. What are you planning to do till the next meeting? 3. Any blockers?
Sprint review - It is held at the end of the sprint, four-hour meeting with team, Product Owner and other stakeholders (if any). Team presents the functionality.
Sprint retrospective meeting - 3 hours - with team and Scrum Master. - to revise Scrum principles used during the meeting.
Burndown chart - It shows amount of work remaining across time.
Sprint backlog - it is an artifact prepared by the Team during second half of Sprint planning meeting. It consists of tasks, each task of 4 to 16 hours. It also consists of the person responsible for a particular task.
**At the end of every sprint, a potentially shippable functionality should be built. Hence the implementation should be well structured, well-written and properly tested.
Team handles its own management. ***
ScrumMaster is similar to Project Manager, he understands the process of Scrum, makes team follow the artifacts and framework of scrum.
Optimal team size for Scrum is 7 people.
*** Insanity - Doing the same thing over and over and expecting different results ***
Scrum is built on 30 day learning cycle to prove a complete business cycle. Helps us learn rapidly. In one scrum cycle of 30 days, a software is built, tested, integrated and the most important of all, released to production.
Scrum is a process to manage complex projects. It does not describe what to do in every situation. It provides a framework and set of guiding principles, instead.
*** Common sense is a combination of experience, training, humility, wit and intelligence.
Software development is a complex process. The complexity and the issues that arise during development process can be resolved with hard work, intelligence and courage.
To take control of a complicated process, the empirical approach should be used.
How to implement a process using empirical process control mechanism?
1. Visibility - The aspects which affect the outcome must be visible to those who are controlling the process.
2. Inspection - To detect unacceptable variances in the process.
3. Adaptation - If after inspection it is found that some aspects of the products are not within acceptable limits, changes should be made.
Most significant aspects of software development - 1. Requirements 2. Technology 3. People
Heart of Scrum -
Product Backlog - Iteration - 24 hour inspection - Increment of functionality -- At the start of an iteration, the team reviews what it must do. It then selects which functionality it can convert into shippable product in one increment. Team, then starts working on the iteration. At the end of the iteration, team presents its output to the stakeholders. Stakeholders inspect the functionality and timely adaptations are made, based on that. This artifact is never complete, it evolves over time based on sprint progress and business requirements.
Scrum roles - Product Owner, Team, Scrum master
Product Owner - represents the stake holders, gets the funding, keeps the cashflow. PO uses Product Backlog (list of requirements), prioritizes it.
Team - It works on the product backlog on iterative basis. It is self-managing, self-organizing, independent and cross-functional.
ScrumMaster - teaches Scrum to the team members and product owner. facilitates the progress of the sprint.
Product Owner + Team + Scrum Master are people who are committed to the project. They have complete authority to take decisions to ensure success of the project.
Scrum flow -
It all starts with a vision. The Product Owner converts the vision into a list of functional and non functional requirements, called Product Backlog. PB(not Peanut Butter) is prioritized based on the value generating items coming on top. The top priority items are divided into proposed releases.
All work is done in Sprints. Each sprint is of 30 consecutive days. Each sprint starts with a sprint planning meeting, which can last maximum of 8 hours. In this meeting, the team and Product Owner decide on the items from the product backlog that can be completed in one sprint.
More about the Sprint planning meeting - First four hours - the team and PO decide the items to completed during the sprint.
Next four hours - the team plans the sprints based on the commitments made to the PO.
Daily Scrum - 15-min meeting every day, only for team members. Every team member answers three questions - 1. What have you done since the last meeting? 2. What are you planning to do till the next meeting? 3. Any blockers?
Sprint review - It is held at the end of the sprint, four-hour meeting with team, Product Owner and other stakeholders (if any). Team presents the functionality.
Sprint retrospective meeting - 3 hours - with team and Scrum Master. - to revise Scrum principles used during the meeting.
Burndown chart - It shows amount of work remaining across time.
Sprint backlog - it is an artifact prepared by the Team during second half of Sprint planning meeting. It consists of tasks, each task of 4 to 16 hours. It also consists of the person responsible for a particular task.
**At the end of every sprint, a potentially shippable functionality should be built. Hence the implementation should be well structured, well-written and properly tested.
Team handles its own management. ***
ScrumMaster is similar to Project Manager, he understands the process of Scrum, makes team follow the artifacts and framework of scrum.
Optimal team size for Scrum is 7 people.
*** Insanity - Doing the same thing over and over and expecting different results ***
April 10, 2012
"Agile Project Management with Scrum" is a series of case studies to make points about using Scrum properly.
The book begins with an overview of Scrum. The majority of it is introducing a company and showing how they (mis) used Scrum. It's an excellent example of learning from the mistakes of others rather than repeating them on your own.
This really gets called out in the lessons learned section for each case study. I would have liked some tips on how project managers should deal with "insulating the team" from problems. One example was extreme where he hired an investigator to track down someone with the knowledge that went on a planned vacation. Someone should have asked for it beforehand. Scrum isn't supposed to be about individual heroes and I felt this was space that could have been used for a common scenario.
In one diagram, there is a typo of "Spring" instead of "Sprint". It doesn't detract from the reading at all, but I was entertained because I do that a lot!
The book begins with an overview of Scrum. The majority of it is introducing a company and showing how they (mis) used Scrum. It's an excellent example of learning from the mistakes of others rather than repeating them on your own.
This really gets called out in the lessons learned section for each case study. I would have liked some tips on how project managers should deal with "insulating the team" from problems. One example was extreme where he hired an investigator to track down someone with the knowledge that went on a planned vacation. Someone should have asked for it beforehand. Scrum isn't supposed to be about individual heroes and I felt this was space that could have been used for a common scenario.
In one diagram, there is a typo of "Spring" instead of "Sprint". It doesn't detract from the reading at all, but I was entertained because I do that a lot!
August 29, 2009
This book, written by one of the founders of Scrum, gives a rich variety of anecdotes on applications of Scrum to various scenarios. It is best suited as a sequel to introductory courses/readings that define the basic Scrum processes, since it concentrates mainly on ways of implementing Scrum principles in various circumstances. There are some enlightening boundary cases (e.g., the time he had to stealth-implement Scrum without letting anyone find out). The stories are not entirely seen through rose-colored glasses either (he describes a time when he failed to convince leadership to follow Scrum and was let go from the project).
All in all, an educational and worthwhile read for anyone making the transition to Scrum and trying to figure out how to implement Scrum principles in a real-world scenario.
All in all, an educational and worthwhile read for anyone making the transition to Scrum and trying to figure out how to implement Scrum principles in a real-world scenario.
April 21, 2012
You do not find engineering practices in this book. It doesn't contain much theory, but enough to make the reader, which is unfamiliar with Scrum, understand its basics.
This book contains real life examples which one can face during transition to Scrum or running the project using Scrum. Author carefully describes of different situations and their traits, so it will be possible to spot the problem, and then he shows the reader the way it was solved.
However, this book is not a cookbook which contains prescriptions how to handle any problem the Team, Scrum Master or Product Owner can deal with, but it teaches you how to find what is wrong and who should be addressed to work it out.
As to me, this book is worth reading both for experienced practitioners and for those who just start using Scrum.
This book contains real life examples which one can face during transition to Scrum or running the project using Scrum. Author carefully describes of different situations and their traits, so it will be possible to spot the problem, and then he shows the reader the way it was solved.
However, this book is not a cookbook which contains prescriptions how to handle any problem the Team, Scrum Master or Product Owner can deal with, but it teaches you how to find what is wrong and who should be addressed to work it out.
As to me, this book is worth reading both for experienced practitioners and for those who just start using Scrum.
July 28, 2013
This book is an OK set of case studies describing how to use Scrum.
The case studies are nicely organised to help someone who is not familiar with the methodology understand it, and they touch on some interesting tweaks and difficulties that can arise when adopting Scrum. In particular, some of the studies consider political and cultural problems that introducing Scrum or another agile technique might raise and how they could be handled.
On the other hand, the other case studies aren't very interesting or insightful, and just seem like a long-form way of describing the Scrum methodology. There is a very good appendix at the back that does the same in far less time. The book is also very badly formatted for the Kindle. It feels rushed and amateur.
The case studies are nicely organised to help someone who is not familiar with the methodology understand it, and they touch on some interesting tweaks and difficulties that can arise when adopting Scrum. In particular, some of the studies consider political and cultural problems that introducing Scrum or another agile technique might raise and how they could be handled.
On the other hand, the other case studies aren't very interesting or insightful, and just seem like a long-form way of describing the Scrum methodology. There is a very good appendix at the back that does the same in far less time. The book is also very badly formatted for the Kindle. It feels rushed and amateur.
February 17, 2015
Hmm... I bet this book is a go-to scrum book for many people. This was my 2nd reading of it, first was 10 years ago without knowing anything about scrum and the second now after having been part in many scrum projects. The book lays out a realistic view of software project landscape and detects the most obvious pitfalls. I especially liked many "lessons learned" chapters. The book is somewhat "cold" and impersonal, as to the writing style doesn't appeal to me. The layout and oRdering of the chapters could have been better, for example, the chapter "product owner" doesn't even explain what a product owner is, so this book must be read from a beginning to an end in order to be understood, a big minus, I think. Some errata, sometimes sprint is called spring. All in all, ok book.
November 26, 2011
Didn't enjoy this book quite so much as the other Agile books I have read. It seems lighter on the details and more simplified. However the case studies are probably the most valuable part of the book, so it makes a good companion to any other books you might read on Agile.
I'm still not quite sure exactly what Agile project management without Scrum is, they seem to be one in the same to me, perhaps I need to read a few more books. It may also be the case that Scrum has become a default technique to espouse the core values of Agile.
Definitely worth reading to find out what the buzz around Agile is actually about.
I'm still not quite sure exactly what Agile project management without Scrum is, they seem to be one in the same to me, perhaps I need to read a few more books. It may also be the case that Scrum has become a default technique to espouse the core values of Agile.
Definitely worth reading to find out what the buzz around Agile is actually about.
Displaying 1 - 30 of 86 reviews