Book: Henrik Kniberg - Scrum and XP from the Trenches: How We Do Scrum

This is the must-read book for any new agile team member!

Author: Henrik Kniberg
Title: Scrum and XP from the Trenches: How We Do Scrum
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Rating: highly recommended!

Are you dealing with new agile team members from time to time? Do you have to train and explain agile to developers, testers, managers? Do you need an easy to understand book on agile practices? Do you need a highly practical book on how to do Scrum and XP?

Get a copy of Henrik Kniberg's outstanding book and just distribute it to your audience.

This book is full of practical information and shows a very pragmatic approach of implementing Scrum and XP practices with an agile team. It covers almost all aspects and is really easy to read and understand.

Although in my opinion there is no best practice how to be agile--this book just shows a great way how it works. I give this book to all my teams and other people new to agile. It's just a great start to learn about agile practices.

Book: How to Read a Book

Everyone reading a large number of articles and books could read this book.

Authors: Mortimer J. Adler, Charles van Doren

Title: How to Read a Book

Rating: interesting

This book was one of many recommended readings from my survey at ACCDE10. The title was promising so I decided to give it a try.

Many aspects of the reading task are covered in both theoretical and practical ways. Four levels of reading are distinguished:

1. elementary reading - nothing more or less than the ability to read and understand written text
2. inspectional reading - the ability to skim and browse quickly through a text
3. analytical reading - the ability to get into the details of a text as well as understanding and criticizing an author's messages
4. syntopical reading - the ability to analyze and put a text into the context of related books on the same topic

The book offers many practical advice on how to read texts of specific kinds like e.g. history, novels, mathematics, and practical books.

I made the experience to have applied some of the practical advices to the book itself. So I skipped some 40% of the actual content of the book - and I don't feel bad about it. I assume such reading behavior was intended by the authors.

On the other hand I'm still puzzled if the book is worth its 400 pages. I'm sure the essence of the book with all its advices and "how to"s would fit on less than 10 pages. The authors probably should have read something like "How to write a book". Nonetheless the book is interesting and to read it may serve well for a reflection on one's own reading approach.

Let the Team play Product Owner

Today I made a nice but rare experience: team A could play Product Owner for team B.

Team A is settled since several iterations and is working on a new product. Team B is only a few days old and is going to build an internal, technical product to emulate the behavior of depending external hardware.

As the developers and testers of team A are going to be the real users of team B's product it was obvious to do a short user story workshop with them. So I gathered everyone of team A around a table in the team room bringing some blank index cards and a marker to start with.

I made several interesting observations during the workshop:

• Some developers show the same behavior as many customers do. They have problems to state what they want to achieve and rather base their statements on the currently planned product features.
• Some developers think very broad so that new themes and stories emerge no one had thought of before. Of course these stories look obvious afterwards but nevertheless would have been forgotten if the real users were not involved.
• Some developers fully understand the agile roles and do not care about the technical implementation. "I don't care how they realize it but I want to have this and that."

We finished that session with a dozen user stories which will result in many more smaller stories after some backlog grooming. I'm going to do the grooming exercise with the team as well so they have the chance to get more and deeper insights into a Product Owner's work and responsibility.

A team and it's Product Owner need mutual understanding and a prospering relationship. In the end it's again--as almost always--a game of Individuals and Interactions.

Recommendation to Scrum Masters and Agile Coaches: let the team play Product Owner every now and then.