Book review: Agile Project Management with SCRUM (and rant)

It is difficult to say anything bad about Agile Project Management with Scrum (Schwaber, 2004). It is a short book, lucid and easy to read. It sticks to its topic - managing projects using scrum. Rather than present Scrum in depth (which I think he has done elsewhere) Schwaber walks us through a set of small case studies and reflections on each one.

If this book has a failing it is: who will read it? - I’m not sure. There is probably not enough information here for someone to implement Scrum but I find it hard to see what someone experienced with Scrum would learn.

For me it was a late introduction to Scrum. I can’t ever recall reading a book dedicated to Scrum. But I picked up the basics of Scrum somewhere, probably websites, articles and conversations. So I would suggest this book is best for someone wanting to an introduction to Scrum, and specifically wanting an idea of how Scrum works in practice.

Which brings me to the question, Why Scrum at all?

I found that Scrum kept coming up more and more and I felt the need to get the introduction I never had so to speak. It is clear to me now (if there was ever any doubt) that Scrum is the management side that is missing from XP.

My own Blue-White-Red process is in effect an example of Scrum and XP (both modified) being used together. Looking back the roots of Blue-White-Red are difficult to work out. I think it was inspired by XP and Scrum and takes many practices form them but it was equally influenced by what I had done in the past and seen work. Perhaps more importantly it was influenced by a bunch of ideas I’d picked up on my MBA, specifically Lean manufacturing.

Unlike Scrum Blue-White-Red is there for anyone to pick up, use, abuse and modify as you see fit. Scrum isn’t, Scrum is actually Scrum (tm), and it is now surrounded by a host of Scrum certifications (Scrum Master, Product Owners, etc.), courses, books, alliances, etc. etc. Scrum has become its own little marketing platform.

In some ways this is good, by doing this Scrum can satisfy business that want to adopt some defined product, it allows Scrum to tackle CMM(I) type organizations and it allows people who want to do Agile to get on courses and learn the skills. But this is also leads to rigidity.

I recently met a Scrum Master who was having trouble with the process. I suggested a one week iteration rather than two week. She saw how this would help but knew the rest of the company used two. She expressed doubts about keeping her meeting schedule (as prescribed by Scrum) in one week. I suggested some changes, at this point she worried that she was deviating from the Scrum process too much.

At the end of this book are the rules of Scrum. Schwaber says: here are the rules, follow them, when you are good at them then (and only then) can the team think about changing them. Scrum needs this, if it was as free as Blue-White-Red it wouldn’t pass muster with CMM(I) and a certificate would be meaningless. But, it also builds in rigidity and people get worried about deviating from the rules.

For me there is an element of The Punk Ideal in Agile, some of it is just about getting our there and doing your own thing, your own way. Who cares if you get it right or wrong? The only mistake is not trying.

At this year’s XP Day conference Keith Braithwaite said something that struck a cord with me, and I’m paraphrasing here ‘cos I don’t remember word for word: ‘I’m not really part of the UK Agile set’ he said, ‘I never worked for Connextra or Thoughtworks.’ And that’s the point, neither of us waited to work for an Agile organization, or to be blessed with a Scrum certificate, we just got on with improving things.

Too many people sit around waiting for something to change, waiting for someone else to fix their problems, waiting for the magic dust that will make everything all right. That’s one reason why so many IT projects go wrong, people wait for someone else to fix it. In part our school system is to blame but that’s why the Punk Ideal is so important. Again, this takes us back to Post Modern Programming. There is no one ‘right’ way of doing this, there are many competing ideas of what right is.

So here is my advice: learn everything you can about XP and Scrum, they are good. Consider them resources to better your understanding. Then go and do Blue-White-Red.

Right now I’m adding two statements to Blue-White-Red:
• Blue-White-Red is open source, I can teach you it but there will never be a certificate
• Blue-White-Red is jazz, it is improvisation, no two performances should ever be the same

If you aren’t doing something different to what I have described you aren’t doing it properly. Like the English language, there is only one rule which is never broken, the rule is: every rule is broken at some time.