Where Scrum and XP from the Trenches is Wrong.
I was the product owner in the book "Scrum and XP from the Trenches" by Henrik Kniberg. As I will come back to on this site, I think that the message it conveys is a bit wrong. It is really from the trenches, but that is not where wars actually are won.
Scrum should be introduced on a product management level. The book presents it as something of a subversive underground movement, but from an organizational perspective, why should you take such an approach when you as easily can get the Product Management to drive this.
Books and other resources on the scrum methodology are getting more and more common and for anyone serious in introducing scrum it is of course essential that to read and understand the concepts from the books. In the reference section there is a good list of books for the interested, although it is implied that the reader actually is pretty familiar with the basic concepts.
The books however don’t really tell you the full story. This is a very common and inevitable problem with books that they don’t. Partly because the people writing the books do not have the complete picture, partly because the reader may not pick it up completely but also largely because the book doesn’t set out to convey it. A lot of times, the introductory books are just introductory and thereby simplify and describe simplified scenarios to give a clearer picture of the concepts and vision.
In fact, Scrum and XP from the trenches is a good book. It is not an introduction to scrum, but rather suits as a bridge between reading a book on scrum and actually starting to implement it in an organization. The problem with the book as I have noticed is that it leaves a lot of questions open. One might argue that this is part of the “inspect and adopt” concept of lean process improvement. The problem here is that the book tends to step over the line, listing a lot of practices but failing to explain why decisions are made. This can be dangerous as inexperienced organizations tend to follow these advices sometimes in the wrong direction.
The other problem with the book is the tone it sets that scrum as a methodology is something to be run from the development department. Albeit a lot of the practices within the framework are related to development, this is not a silver bullet. One of the problems in introducing Scrum has naturally been to answer on wherefrom the productivity gains will come. Changing the way the development department works will only achieve so much and without the support from product management this may not even be noticeable in the organization, which unfortunately many organizations actually has been experiencing.
My recommendation is definitely to read the book, but be critical adapting to it. The decisions were right for that situation. Not necessarily for your situation. And it will not tell you when and why. And the sad end of the story is actually that Henrik did not save the day. The product was discontinued. Another conclusion was that the quality improvements of the product were not the result of the change of the process, it was still done by the people working late nights and massive overtime. These were the real heroes of that story. (Yes you know who you are!)