Agile Project Management with Scrum (Microsoft Professional)

It's very hard to part with the practices accepted for generations. Many companies talk about a new, better way of a project planning, developments' ehgagement and other agile techniques. When trying to apply these techniques, these companies immediately hit the wall of a management looking for traditional ways they've been using for life and with a success (at least, in their estimate). This book makes a Scrum approach very clear and very compelling. You can read chapters from this book to your manager (by the way, I'm a manager myself) and move him/her, step-by-step, to the better understanding how a new approach works.
Books on a market about an Extreme Programming left me with much less clarity and didn't prove compelling to my CIO. This book does an excellent job of describing a total approach and all small details you need to implement Scrum, as an excellent form of agile development.
I strongly recommend this book to everybody who is tired of products "dead on arrival" and project plans (thanks, Billy, for an outstanding piece of bureaucracy - Microsoft Project) which never work as planned.

Teaching others the minimalist approach to software delivery. This book should be read/processed in context of the Agile Software Development with SCRUM book by Schwaber, as well as, the Enterprise SCRUM book by the same. All three craft a lens from which to view what really matters versus what gets in the way of getting work done that is useful, tested, and tangible to a customer in short bursts of time. And no, this isn't so simple as saying it's another version of RUP iterative logic .. this is actually a low-ceremony lower COA/COO, higher ROI than RUP (as said by someone who's done both now multiple times).

This is a book you can pass around to anyone involved anywhere around software solution delivery streams - they read it, and get it. It provides concept explanations, real world examples and suggestive commentary .. like walking into a swimming pool on a gradient slope. My perception of the problem to solve with this book? What is Scrum and why do I care? And .. if I entertain Scrum .. what does that look like? Schwaber's book tells you about it, what it is, who's doing it, challenges, etc. Look at this book as a doorway into new space and practice. This book _does not_ prescribe how to solve all your woes.

I just plain encourage the purchase of and pass this book out to others. Quick read. Concepts are face value. Cracks the door open to Agile space implementations, esp. for those unfamiliar with anything other than standard linear waterfall stuff.

Let's just start this out by saying I am not a project manager, I am a SQL Server architect and developer. So this review should be taken as coming from such a person and not a person who has managed numerous successful project. In fact quite the opposite. I have been on numerous chaotic, insane projects. It is from this perspective that I review the book, and the methodology given forthwith.

This is a great idea, and a great concept. What it is not, however, is a methodology that you cherry-pick the parts you like and leave the rest. Only choosing to implement some of the Scrum methodology will take your previously chaotic project lifecycle and choke the life out of your employees.

In a nutshell, projects are broken up into thirty day, self enclosed cycles. Development, implementation, documentation, and testing done. Testing, that oft forgotten step in the development process. The teams are empowered to manage themselves, with only a coach along to make sure the rules are folled. One of the scrum "rules" is that you have to actually test the code in the 30 day window (all of the rules are presented in an appendix.) Customers are involved at the beginning and end, deciding what features to implement, and then implementation happens. Obviously it is more complex than that, but not by much.

Will it work? I believe so, given the right corporate involvement, customer buy in, the right team, and a good deal of team self-discipline. Developers will eventually love it, and should have no problems following the rules once they understand them. The "customer" may have the hardest time, as they can only apply a heavy hand to direct development monthly, rather than daily. On the other hand, with many classic projects, the problem was that design was done for months, then development for months, then testing and documentation done by the poor unwitting users!

The book is very well written. I like how he introduces the team roles, then gives good and bad examples of how they have been done on past projects. Very reasonable examples are presented that feel very genuine and real, that I as a developer for over twelve years could eaisly relate to. It isn't perfect, and there are places where the author seems almost too eager to believe that Scrum is the fix to all of the world's problems. Only one place does he seem negative, that having to do with fixed bid, fixed time contracts. I also feel that the level of developers you will need to make this work will have to be above average. Not to say it won't work without world class developers, but their motivation will need to be derived from doing a good job, not at being told what to do and just mindlessly doing it.

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.

The book was an easy read and provided a fair but light treatment of Scrum. The numerous examples provide a good illustration of some of the key concepts of the method and help in better understanding implementation issues and lessons learned. This being said, a complete understanding of Scrum requires additional reading above and beyond this book, and most importantly a good solid (if not many) attempt at applying it in the real world. For individuals interested in Scrum, I would also recommend a very active discussion group to which the book's author and many other Scrum aficionados contribute regularly: http://groups.yahoo.com/group/scrumdevelopment/