Agile Project Management with Scrum

by Ken Schwaber

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

Genres: Business, Management, Nonfiction, Reference, Technology, Programming, Software

192 pages, Paperback

Published February 11, 2004

Reviews

[Ruth]

Agile 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.

[Robin · Rating 4 out of 5]

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.

[Micah Tan · Rating 2 out of 5]

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.

[Tim Nowotny · Rating 5 out of 5]

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?

[Lazysmokier · Rating 4 out of 5]

Книга не столько описывает скрам, сколько рассказывает истории, иллюстрирующие те или иные аспекты методологии. С одной стороны чувствуется отсутствие какой-то последовательности в подаче материала. Но с другой, в какой-то момент начинаешь осознавать, что в тему въезжаешь и вроде как начинаешь что-то понимать. Наверное книга неплоха в качестве дополнения к какой-то более систематизированной

[Joshua]

I 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.

[Supreeth · Rating 4 out of 5]

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.

[Dave Weber · Rating 1 out of 5]

In Agile Project Management, Ken describes how, as a result of his professional pride, he hired a private investigator to track down a team member so that they could save his sprint. Avoid at all costs.

[Mark · Rating 4 out of 5]

May be a bit dated now, but still some great stories to describe how people live in the Scrum framework.

[Callum · Rating 2 out of 5]

This book is littered with red flags that made me feel extremely suspicious of the author.

Before I enumerate these, it’s imperative that I mention an anecdote from the book that is so shocking it literally left me slack-jawed.
This man organised an ex-FBI private investigator to hunt down a colleague who was on a one-week vacation in the wilderness with his wife because of a bugs that arose from this guy’s code (this allegedly involved giving his colleague’s social security number to the investigator). Here is a snippet from the book:

“Unfortunately for Thomas and his vacation plans, I'm a fan of mystery novels. ‘Of course!’ I thought. ’I’Il hire a private detective to find Thomas.’ After some searching, I found an ex-FBI agent who had an office in Billings, Montana. He was excited about working for an Internet startup. He found Thomas within two days. Thomas was able to assist the team, and the Sprint goal was met. I figured that I had been pretty inventive, spending only several hundred dollars to get around a major impediment in an unconventional manner. As ScrumMaster, I had weighed overall Team good against individual good and chosen. Had I chosen correctly? Everyone had a different opinion, but you'll find yourself making similar choices about the Team's welfare.”


Psychotic. Other red flags:

• The author says he has implemented Scrum “in hundreds of organisations over the last decade”. This feels like a like, assuming “hundreds” to be 200, this would mean he’s implemented scrum in 1.6 organisations per month. Seems unlikely given he often describes spending several months at companies to do this.

• If he has implanted Scrum in “hundreds or organisations” then why is there like 5 or so organisations he uses for every anecdote throughout the whole book?

• I’m suspicious that these companies even exist, some of them have such hilarious names like “WebNewSite”. Maybe it’s real, who knows, but again, it just detracts completely any sliver of authenticity

• Constant contradictions. One chapter Scrum is a simple, easy to understand process, other times it’s an elusive, complex, and hard to apply process that needs training in order to be able to apply correctly…

Overall, I feel like this entire book is just part of the Snake Oil that is Scrum™ so that the author can make money selling Certified ScrumMaster classes…

[Richard · Rating 4 out of 5]

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.

[Dmytro Chasovskyi · Rating 3 out of 5]

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.

[Jowen Mei · Rating 4 out of 5]

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.

[Anna Hellwing · Rating 3 out of 5]

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.

[Sicofonia · Rating 4 out of 5]

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.

[Hunter Hart · Rating 4 out of 5]

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.

[John · Rating 4 out of 5]

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.

[Max Cherepitsa]

Хорошие основы скрама в приложениях, а в основной части книги много историй о том, с какими сложностями можно столкнуться при внедрении и какие профиты получить в случае успеха. В одной из последних глав интересный пример масштабирования скрама.

[Faith · Rating 3 out of 5]

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.

[Mohammad Zaripour · Rating 5 out of 5]

Agile methodologies are always beneficial for environments characterized by rapid changes and the need for quick delivery. They provide the flexibility and adaptability required to respond to evolving requirements and ensure timely delivery of high-quality products

[Charles Baker · Rating 5 out of 5]

Great book by one of the originators of SCRUM. Outlines all the principles and reinforces them w/ story like case studies.

[Victoria · Rating 5 out of 5]

I love his books. Ken is the baseline of scrum. go for it!

[LB · Rating 4 out of 5]

Case studies to understand/apply agile scrum project management

[Rob · Rating 5 out of 5]

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.

[Robert Shaw · Rating 3 out of 5]

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.

[Thomas · Rating 4 out of 5]

Gutes, kurzweiliges Buch mit verschiedenen Fallstudien. Es ist durchaus inspirierend, manche Abschnitte bieten (mir?) aber auch wenig Mehrwert.

[Prajakta · Rating 4 out of 5]

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 ***

[Jeanne Boyarsky · Rating 3 out of 5]

"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!

[Francis · Rating 4 out of 5]

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.

[Vladimir Tarasov · Rating 4 out of 5]

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.