Agile Project Management with Scrum

When co-workers see this book on my office shelf, I inevitably get one of two reactions. The most common one is "Do you really want to take advice on project management from Microsoft?" The answer is probably not, but this book was written by the co-creator of SCRUM, and published by Microsoft press, so it's not exactly a recipe-book from Redmond. The second reaction I get is "I was at a company/on a project/reported to a boss who used SCRUM and it worked really well." After reading several books on the subject and applying the lessons, I can see why. SCRUM has been the most useful project management method I've tried so far on my software development projects. Since the goal of traditional project management is to standardize a known process to produce a required result, it has always had problems when applied to the creative process of producing software. This problem is only multiplied when the software to be produced is web based and consumer oriented, throwing a multitude of marketing and usability issues into the mix, making the desired end product as uncertain as the process. SCRUM is an ingenious solution to this problem; instead of trying fruitlessly to predict the future in the form of a project schedule, SCRUM emphasizes development as a continuous process that can be controlled using the same empirical feedback mechanisms of visibility, feedback, and adaptation that are already used to good effect in the manufacturing industry. In this view, the team is a machine that constantly produces features as output. That output is inspected by end users, who then provide feedback, which is then incorporated into the next round of development. The book details the organizational roles and responsibilities needed to set up this machine and the processes to keep it running. I found this book to be considerably more reader friendly than the original book by Schwaber detailing SCRUM. (Agile Software Development with SCRUM The emphasis on case studies rather than theoretical discussions certainly helps keep the discussion grounded, but more than that the text is more coherent and better written. Whether this is the effect of more experience or a better editor is hard to tell. The three roles of SCRUM are the Product Owner, the Scrum Master, and the Team. The first two are single person managerial roles that are responsible for requirements definition and maintaining the process. The Team, however, consists of everyone who is assigned to do work exclusively for the project, and in Schwaber's conception it is to be completely self-managed. Now that I have gained some experience using SCRUM, I have to say that this is both the most challenging aspect of the process. SCRUM depends on the Team effectively taking control of the product and committing themselves to delivering shippable features on a regular basis. To successfully introduce SCRUM engineers and other creative people have to be convinced that not only do they have the po

... you must not be taking Scrum very seriously.-) For what it's worth: I read this book before I read the first book ("Agile Software Development with SCRUM"). I didn't have any trouble reading them in that order. I found this book slightly more helpful than the first. It seemed to cover the mechanics of Scrum in more detail. More importantly, it help me understand how to fit Scrum into the context of the real world.

Reading this book won't turn you into a ScrumMaster- only experience with a few projects will do that- but this book really has all the information you need to start to implement the Scrum agile methodology in your company or department. I've been trained in two seperate PMI-certified methodologies, and both have been complete failures in my organizations. The response, of course, has been to bring in a third methodology. The real reason for the failures has been that traditional project managment as it is usually practiced is designed to fail. It encourages the creation of fictions that live a seperate existence form the actual project, with due dates dictated from above, and project schedules fudged to meet due dates rather than actual resources. In my own organization, we had a typical example of what happens in traditional "waterfall" development: A massive project to replace our main administrative system was ticking towards a June delivery (according to the detailed MS Project charts) and then, 30 days prior to delivery, it was announced that the delivery date had been pushed back an entire year! This can't happen with Scrum. Scrum reflects what's really happening in a project, and it encourages incremental development- prioritizing requirements, and delivering them in their order of need, instead of trying to deliver a complete project with every single componant at a certain date. It's also one of the least onerous of methodologies. As a Scrum Master friend notes, "It's the simplest methodology you can implement that will actually deliver results". It does requrie some changes in how things are done in the traditional organizations. Scrum project managers don't assign tasks and track performance on each task; instead, they assign goals and the programmers report on progress and any difficulties they many encounter. There's a daily stand-up review to report on progress and roadblocks and monthly reviews to reprioritize and review changes in scope. The result is that the project continually is driven by the needs of the customer as they evolve, and not by arbitrary goals in the distant future. If I've piqued your interest in Scrum at all, get a copy of this book. Better yet, order copies for all your team members, too.

Our organization recently implemented Scrum, and although theBeedle/Schwaber book was great to get us off the ground on Scrumtheory, we immediately had many questions once we actually tried to implement it in real life projects. I agree with the notion that Scrum is conceptually easy to understand, but actually quite complex to implement correctly. The scrum forum has been helpful, but we really needed a cohesive reference of situational problems. The APMWS book really hit the nail on the head and delivered what we needed the most: a practical guide to Scrum with anecdotes and "what happens if..." situations from real world Scrum implementations. This came just in time for us, and we are feeling more confident for our upcoming certification class.The appendices in the back are also very helpful. The "Rules"appendix is perfect as a quick introduction to Scrum for new Teammembers and Product Owners. It's actually quite detailed for being such a short appendix.Also, for newbies the three main Roles are very nicely explained. We had some misconceptions that were immediately addressed by this book.Anyway, from a Scrum newbie that is faced with implementation issues, thanks to Ken for putting together a real world implementation guide.

Agile Project Management with Scrum is a wonderful book. The author, Ken Schwaber (one of the originators of the Scrum process), informs us through case studies and anecdotes. If you like learning by example, this book is for you. Scrum is quite likely the best starting point for most companies interested in pursuing an agile development process. The readability and excellent anecdotes in this book make it a fantastic starting point for any journey into agile development.I loved seeing how Schwaber applied Scrum in many varying situations. Rather than introducing each case study one at a time, the book is organized around key areas. Multiple anecdotes are given for each key area. Throughout each chapter, Schwaber brings the anecdotes together in Lessons Learned sections and the chapters conclude by helping point out the conclusions we learn to draw from the anecdotes.I appreciated that Schwaber was not shy about mentioning projects that didn't go perfectly-including one he got fired from for being too zealous in his role of sheepdog guarding his flock of developers.Although this book is ostensibly about software development, Scrum has its roots in general new product development and can (and has been) applied to a wide variety of development projects. A problem with a process like Scrum is that it is best learned by "feeling it" rather than being told about it. There are many subtle differences between Scrum and a more command-and-control management process. Learning Scrum by reading a book filled with examples like this is the best way to get the feel for how to use it on your own projects.