Not exactly a SQL Book review, but I recently read a great book about the SCRUM project management and figured I should review it:

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.