Schwaber - Agile Project Management with Scrum

My new boss wasnt being a jerk, but it seemed like it at the time. We were writing new software for use in the companys high-volume call centers. Instead of the 12 months I told him wed probably need, he had agreed to give me 4 months. We wouldnt necessarily start using the new software in 4 months, but from that point on, all my boss could give me was 30 days notice of a go-live date. After the first 4 months, I would have to keep the software within 30 days of releasable. My boss understood that not all functionality would be there after 4 months. He just wanted as much as he could get, as fast as he could get it. I needed to find a process that would let us do this. I scoured everything I could find on software development processes, which led me to Scrum and to Ken Schwabers early writings on it.

In the years since my first Scrum project, I have used Scrum on commercial products, software for internal use, consulting projects, projects with ISO 9001 requirements, and others. Each of these projects was unique, but what they had in common was urgency and criticality. Scrum excels on urgent projects that are critical to an organization. Scrum excels when requirements are unknown, unknowable, or changing. Scrum excels by helping teams excel.

In this book, Ken Schwaber correctly points out that Scrum is hard. Its not hard because of the things you do; its hard because of the things you dont do. If youre a project manager, you might find some of your conventional tools missing. There are no Gantt charts in Scrum, theres no time reporting, and you dont assign tasks to programmers. Instead youll learn the few simple rules of Scrum and how to use its frequent inspect-and-adapt cycles to create more valuable software faster.

Ken was there at the beginning of Scrum. Ken, along with Jeff Sutherland, was the original creator of Scrum and has always been its most vocal proponent. In this book, we get to read about many of the Scrum projects Ken has participated in. Ken is a frequent and popular speaker at industry conferences, and if youve ever heard him speak, you know he doesnt pull any punches. This book is the same way: Ken presents both the successes and the failures of past Scrum projects. His goal is to teach us how to make our projects successful, and so he presents examples we can emulate and counterexamples for us to avoid.

This book clearly reflects Kens experience mentoring Scrum Teams and teaching Certified ScrumMaster courses around the world. Through the many stories in this book, Ken shares with us dozens of the lessons hes learned. This book is an excellent guide for anyone looking to improve how he or she delivers software, and I recommend it highly.

Mike CohnCertified ScrumMasterDirector, Agile Alliance

Suppose Im traveling from Chicago to Boston by airplane. Before and during the flight, the pilot gets instructions from air traffic control. We take off on command and follow the prescribed route. Once we are in the air, computers predict almost to the minute when we will land in Boston. If things changesay the air is bumpythe pilot must get permission to move to a different altitude. As we approach the airport, the pilot is told what runway to land on and what gate to go to.

If, however, I set out for Boston in a car, I can take whatever route I want, whenever I want. I dont know exactly when Ill get there, and I probably havent planned what route Ill take or where Ill stop for the night. En route, I follow traffic laws and conventions: I stop at red lights, merge into traffic according to the prevailing customs, and keep my speed consistent with the flow. In an automobile, I am an independent agent, making decisions in my own best interests framed by the rules of the game of driving.

Its amazing to me that thousands upon thousands of people travel by car every day, accomplishing their goals in a framework of simple traffic rules, with no central control or dispatching service. It also amazes me that when I want to ship a package, I can enter a pickup request on the shippers Web site and a driver will arrive at my door before the time that I specify. The driver isnt dispatched to each house; he or she receives a continually updated list of addresses and deadlines. Its the drivers job to plot a route to get all the packages picked up on time.

As complexity increases, central control and dispatching systems break down. Some might try valiantly to make the control system work by applying more rigor, and indeed that works for a while. But the people who prevail are those who figure out how to change to a system of independent agents operating under an appropriate set of rules. It might work to provide same-day delivery with a dispatch system that plans a drivers route at the beginning of the day. However, it is far more difficult to preplan a pickup route when customers can enter pickup requests at any time. Taxi companies sort things out at a central control center. Some shipping companies send the request to the driver responsible for the area and let the driver determine the best route based on current conditions and other demands.

The more complex the system, the more likely it is that central control systems will break down. This is the reason companies decentralize and governments deregulaterelinquishing control to independent agents is a time-honored approach to dealing with complexity. Scrum travels this well-trodden path by moving control from a central scheduling and dispatching authority to the individual teams doing the work. The more complex the project, the more necessary it becomes to delegate decision making to independent agents who are close to the work.

Another reason that Scrum works is that it dramatically shortens the feedback loop between customer and developer, between wish list and implementation, and between investment and return on investment. Again, complexity plays a role here. When a system is simple, its not so hard to know in advance what to do. But when we are dealing with a market economy that changes all the time and with technology that wont stand still, learning through short cycles of discovery is the tried-and-true problem-solving approach.

We already know this. We try out various marketing campaigns and discover which approach works. We simulate vehicle behavior during car design to discover the best slope of the hood and best distribution of weight. Virtually all process-improvement programs use some version of the Deming cycle to study a problem, experiment with a solution, measure the results, and adopt proven improvements. We call this fact-based decision making, and we know that it works a lot better than front-end-loaded predictive approaches.

Scrum is built on 30-day learning cycles that prove complete business concepts. If we already know everything and have nothing to discover, perhaps we dont need to use Scrum. If we need to learn, however, Scrums insistence on delivering complete increments of business value helps us learn rapidly and completely. One of the reasons complete increments are important is that partial answers often fool us into thinking that an approach will work, when in reality, the approach doesnt work upon closer examination. We know that until software is tested, integrated, and released to production, we cant really be sure that it will deliver the intended business value. Scrum forces us to test and integrate our experiments and encourages us to release them to production, so that we have a complete learning cycle every 30 days.