Book: The Five Dysfunctions of a Team

The definitive must-read for everyone having anything to do with teams!

Author: Patrick Lencioni
Title: The Five Dysfunctions of a Team

Rating: highest recommendation!

Have you ever wondered why weekly team meetings become meaningless rituals without any results? Have you ever had the feeling that important topics were not discussed and severe conflicts not surfaced?

This book offers a very simple model of five dysfunctions of a team. The model explains typical anti-patterns of behavior you can recognize in many teams:

1. Absence of Trust
2. Fear of Conflict
3. Lack of Commitment
4. Avoidance of Accountability
5. Inattention to Results

Some nice exercises to overcome these dysfunctions are described as well.

The first 90% of the book are written as a novel which is easy to read and understand but still highly exciting and insightful. The latter part of the book contains the pure description of the model and the exercises. But it's much more fun to read the novel and see how Kathryn--the main protagonist--is analyzing and guiding the team away from its old habits and dysfunctions.

In the real world you could use the model for team building events or retrospective meetings. Explain this simple model to your team and confront them with their habits. As simple as it is to understand, as hard is it to live it in a team. Just do it and give it a try!

I give this book the highest rating possible. Buy it, study it, apply it, share it with your peers!

Book: Fearless Change

If you need to get some activities to drive change, read this book.

Authors: Mary Lynn Manns, Linda Rising

Title: Fearless Change

Rating: recommended

You work as a change agent? You have a new idea for your organization and want to change processes and interactions? This book may be helpful as it presents 48 patterns for introducing new ideas.

The first part of the book describes a general approach with many examples how to apply all the different patterns. The second part contains detailed descriptions of the patterns with many cross-references between them.

Although the majority of the patterns should be well known to change agents, there might be many insights how to initiate and maintain changes inside an organization. In my point of view there are no brand-new approaches presented in the book. The highest value this book provides is giving an elaborated pattern language so people involved in change are able to talk about the same things with the same wording.

This review may sound as the book would not be worth its pages. Don't get me wrong. It contains a very nice reference and map of change patterns to look up. I'm going to take a look at a random pattern from time to time just to get a reminder and maybe new insights.

Read it so we can talk about it!

Done-Related Story Estimation

In today's Backlog Grooming I tried a new method of estimating user stories. The estimations were based on and related to known done-stories of former sprints. The method is very simple and contains only five steps. 

Step 1: Get user stories from Product Owner

Your Product Owner should be prepared for Backlog Grooming and bring his top-priority stories for discussion and estimation.

Step 2: Select reference stories

Pick a few random stories from your already done stories. Make sure their story points differ enough so a typical mixture of story points is in the set. In today's experiment I chose stories with 3, 5, 8, and 20 points.

Then write a new reference story card for each of them in the following way: write the story on the front of the card and write its story points on the back of the card. Make sure to hide the story points from the team's eyes for now.

Step 3: Sort user stories

Let the team find the right order of old reference stories and new undone stories. You will notice much more comparative conversation on the stories than with playing Planning Poker.

Step 4: Show story points

Now the fun part begins. Turn the reference stories and surprise the team by showing the reference story points.

Step 5: Adjust stories and story points

Let the team discuss if any adjustments are necessary. There will be more conversations on single cards to gain more understanding. Some stories may change due to these conversations. Take care that stories with high points get split properly. In today's example the story at the bottom with 20 points could be discussed and split into two stories. The result was much deeper understanding of the real value for both the team and the Product Owner. 

I'm looking forward to the Sprint Planning meeting next Monday.

Book: Harrison Owen - Wave Rider

Everyone dealing with self-organizing teams should read this book!

Authors: Harrison Owen

Title: Wave Rider: Leadership for High Performance in a Self-Organizing World

Rating: highly recommended

Have you ever wondered why in a well-defined organization there are always a few "key" people who know how things really do work? Have you ever thought about how to plan and deliver the daily food supplies for several million people? Read this book to find out.

In the first part of this book Harrison Owen offers deep theoretical insights of High Performance Systems, Self-Organization, and Open Space Technology. According to his definition, the three major elements of High Performance are chaos, confusion, and conflict, which lead to wholeness, health, and harmony--be it in small teams or large organizations. He states the necessity of grief work at the end of anything, and that--although highly important--such grief work rarely happens. The reason of missing self-organization is the need of control coming from traditional habits and thinking.

The second part of the book is written for practitioners and shows "eight essential steps for the care and feeding of self-organizing systems":

1. Do Your Homework Before You Start.
2. Extend an Invitation.
3. Come to the Circle.
4. Welcome Passion, Responsibility, and Authentic Leadership.
5. Remember the Four Principles.
6. Observe the Law of Two Feet.
7. Keep Grief Working.
8. Formalize the System.

This may sound weird at the first look but it gives a very nice description how Open Space works and how to do it.

The book is an eye-opener and offers so many insights why and how self-organizing systems work. The level of understanding one may reach by reading this book is not restricted to Open Space but is applicable to any organizational structure.

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.