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.

CCD Reflection 2: Red Grade finally finished

Four weeks have passed since my last CCD Reflection. So today is day number 49 of wearing the CCD Red Grade wrist band which is quite a lot of time staying with one single CCD grade.

What have I done in the last four weeks?

• Weekly Coding Dojos with my team
• Thought about features and user stories of an online CCD Reflection tool to make daily reflections easier
• Took Industrial Logic's eLearning course on "Composing User Stories"
• Worked on the formal proof that agile practices match very well the software life cycle requirements of specific laws and regulations. But well, this is way too off-topic here.

How do I rate my performance on the principles and practices of the CCD Red Grade?

• DRY - highest rating
• KISS - high, still room to improve
• Beware of Optimization - high, no longer skipping TDD baby steps but from my gut feeling still room to improve
• FCoI - high, I initiated a design session with the team to talk about FCoI. One guy came up with FNoCaI: Favor Nothing over Composition and Inheritance - which sometimes could be the best choice.
• Boy Scout Rule - lowest rating due to 100% work on new, fresh Kata code
• Root Cause Analysis - high, this just belongs to my daily job as team coach and Scrum Master, at least in the last four weeks
• Version Control - high, nearly 100% done
• Simple Refactoring - highest rating, completely done as integral part of doing TDD
• Daily Reflection - medium as I have thought about developing an online CCD Reflection tool

I gave every of these principles and practices a value from 1 point (not done at all) to 5 points (perfectly done), see image.

Red Grade finished for now!

Although I wrote in my last post ...

It would be meaningless to go on as long as I fail to apply the boy-scout-rule, root-cause-analysis, and daily reflexions on a regular basis.

... I'm going to switch to the next Orange Grade by tomorrow morning simply because it's the right time to do so from my point of view. I'm just too excited to experience the next grade. Expect feedback in at least 21 days here again.

CCD Reflection 1: Red Grade finished

Today is day number 21 of wearing the CCD Red Grade wrist band and time to reflect on the last three weeks.

What have I done in the last three weeks?

• Several code katas
• A little pairing with one of our developers to find weird UI problems
• Initiated the first Coding Dojo in our team - we are going to do weekly Dojos now

How do I rate my performance on the principles and practices of the CCD Red Grade?

• DRY - everything was done only once, I give a high rating
• KISS - almost everything was kept simple or--even better--was made simpler
• Beware of Optimization - I can't remember any optimization but want to rate "not perfect" as I think that some shortcuts were made during TDD (two or more baby steps at once). And taking shortcuts is some kind of optimization as well.
• FCoI - my kata and dojo code was too simple, FCoI could not have been applied
• Boy Scout Rule - interesting experience: during a debugging session we walked through code and saw dirty places BUT at that time we were hunting a very specific system behaviour and did not want to interrupt this task by doing boy scout cleaning. Unfortunately we forgot to clean the code afterwards. Learned for next time: take a note of the dirty location and come back later to clean it.
• Root Cause Analysis - did not happen at all in the last three weeks
• Version Control - 50% done but not for some spiking code experiments and all my private katas
• Simple Refactoring - completely done as integral part of doing TDD
• Daily Reflection - thought about it but not very structured

I gave every of these principles and practices a value from 1 point (not done at all) to 5 points (perfectly done), see image.

Red Grade done, finished, or on-going?

The idea of the CCD initiative is to stay with your current grade until you are able to high perform on all aspects of this grade for at least 21 days in a row. My initial plan was to switch to the next Orange Grade after three weeks regardless of my red performance. I wanted to go on and focus on the next principles and practices - and simply keep in mind that I have to improve my red skills. Now I realize that CCD doesn't work this way. I want to prove significant success in the current grade to myself as a trigger to switch to the next grade. It would be meaningless to go on as long as I fail to apply the boy-scout-rule, root-cause-analysis, and daily reflexions on a regular basis.

I try to do daily reflexions from now on to get self-feedback early and improve my grade performance. To be continued...

CCD: The Personal Experiment

Two years ago I left the path of writing code as I had to deal with leadership, management, and organizational things for my teams more and more. That really was no big deal in the beginning but after a while I felt two important reasons to get back into coding again: (1) something was missing regarding my passion for software development: actual coding working software, and (2) I was not able to participate actively in discussions about all those fancy new things: frameworks, languages, and technologies I've never used.

From my theoretical point of view I knew that Uncle Bob's Clean Code was the right approach to go. This was what I wanted to head for not only personally. I also wanted to work with developers who understand and foster their own software craftsmanship in that way: writing clean and SOLID code, following XP practices, and valuing Agile principles.

In November 2009 I started to contribute to the Agile Skills Project for quite a while but unfortunately this project was running into a dead end in the last months. I still hope it will continue somehow but this is another story for another blog post.

At about the same time in November 2009 I attended a session of Stefan Lieser talking about the Clean Code Developer (CCD) initiative at XP-Days 2009, Germany. For in-depth information take a look at

clean-code-developer.de

but note that there is only a German version available.

CCD was exactly what I needed. It it based on four values which always should be focused by developers:

• Evolvability - take care that software is able to be changed easily and at a reasonable low price late in a project or even after years of production.
• Correctness - software is correct if and only if all functional and non-functional requirements are implemented
• Efficiency of Production - short development time, automated tasks, and low bug ratio are necessary to be efficient
• Reflection - learn and improve often and early (on all the individual, the team, and the organizational levels)

These are good values to follow but they are quite too abstract to know how to do it. Ralf Westphal and Stefan Lieser,  founders of the CCD initiative, did a great job with structuring lots of principles and practices and giving easy-to-start guidance to developers.

The whole system is divided into seven colored grades of which five contain specific principles and practices. A CCD developer starts with the first (red) of these five grades and works with the given principles and practices until she has reached a proficient level in this grade for at least three weeks in a row. Then the developer turns to the next grade and continues cycling through all the grades. This grade system provides an easy way to start with specific things and increases a developer's focus.

So I started with the red grade a while ago and will post my experiences on a regular basis here on my blog.