Sunday, August 15, 2010

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.

Posted by at No comments:

Monday, July 12, 2010

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...
Posted by at No comments:
Labels: ,

Sunday, July 11, 2010

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
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.
Posted by at No comments:
Labels: , ,

Thursday, May 27, 2010

Aqua Doodle as Presentation Tool

Several days ago we bought a new toy for our 15 months old son. It's a drawing toy called "Aqua Doodle" and has a magic canvas: when the water filled pen touches the canvas it becomes visible and gradually disappears again within the next few minutes.

Image: the canvas and the water filled pen.

This is great tool for kids... but only for kids? I think this could also be used for presentations, moderation, creative group work, and unfocused people: there's a few minutes timebox to come to the point and sell your idea, nothing more.

Images: disappearing illustration.
The images were shot with three minutes gaps.

What's the big advantage? People need discipline and focus to reach their conclusion within the given timebox. And it should be an entertaining experience for the audience.

There's only one disadvantage: if you're really good at presenting quickly, the time until things disappear might be too long, so you'd better bring a hair-dryer.
Posted by at No comments:

Wednesday, May 12, 2010

Book: Rachel Davies - Agile Coaching

Everyone supporting agile teams has to read this book!

Authors: Rachel Davies, Liz Sedley

Rating: highly recommended!

More and more developers and project managers suddenly have to take over the role of ScrumMaster these days. All our agile frameworks and methodologies are easy to learn and understand so people become facilitators, supporters, and coaches of an agile team--without knowing anything about how to do that effectively. 

This book covers many important aspects of coaching an agile team.

Starting with coaching basics the authors explain what it means to work as an agile coach. Why do I coach? Do I have the right attitude for coaching? What does it mean to work with people? How do I encourage change? How can I help building an agile team? These and related questions get answered in the first part of the book.

Part two describes a lot of coaching tips and practices related to the planning activities of a team. The reader gets answers to questions like: How can I facilitate daily standup and planning meetings? Is it really necessary to coach in daily standup meetings? How to support the team understanding user stories and backlog priorities? How to create the team board and increase visibility?

The third part takes care about quality: How to introduce test-driven development? How to introduce clean code? How to start with pair programming? How to define and get to "done"?

The fourth and last part of the book covers inspection and adaption practices: How do I demo working software increments? How do I facilitate a retrospective meeting? What can I do to get better as a coach?

A very helpful resource in this book are all the short experience reports of Rachel and Liz. Every chapter ends with a typical list of hurdles and contains a checklist so it's easy to do regular self-reflections of specific topics as an agile coach.

This is a really nice reference book on the ScrumMaster's desk to look up how to improve one's own coaching skills.
Posted by at 1 comment:
Labels:

Sunday, May 2, 2010

Agile Coach Camp 2010 Germany - Day 3

The final day of the Agile Coach Camp 2010 in Germany started again at 8:30 am. Mike Sutton provided facilitation so attendees and session hosts could change the marketplace to their needs.

9:00 am. I joined the "Swashbooking" session of Jürgen "Mentos" Hoffmann. It was a fascinating experience. We were six people in this session with six books on a table. The goal of this session was to read 3 books in 30 minutes and to take notes on these books while reading them. After this time we talked about the books and the 3 people who have read the book gave a short report on their lessons learned within the 10 minutes they had with the book. My insight of this session was that the learning process of swashbooking highly relates to the structure of a book and the level of knowledge I already had of a book's topic. This is an experiment which has to be continued!

10:00 am. I joined the "Velocity" session of Deborah Hartmann-Preuß. I got a nice reminder of two important things: (1) the team has to look ahead 1-3 sprints to get a feeling of what probably will come, and (2) backlog grooming is explicitly needed in every sprint to get stories ready for the next sprint.

10:30 am. I moved to Krishan Mathis' session on "Kanban sucks the spirit out of agile". We had consensus that Kanban offers an easy way to de-agilize a self-organizing Scrum team. Kanban tends to create a dangerous mini-waterfall if applied invalid. It's a good approach to extend the Scrum board on the left side with more lanes to define the steps it needs to get a story ready. And maybe on the right side to define necessary steps after a story is done-done. But the simple, team protecting Scrum board must not be changed!

11:00 am. I joined the "How to make a Product Owner" session of Nicole Rauch. We discussed about the responsibilities of a Product Owner and what a Product Backlog has to contain. I gave a short experience report of my last project on how I tried to transform one of three product managers to a committed Product Owner. The fundamental way to get a Product Owner committed is to show the benefits for the Product Owner with Sprint Reviews and the ability to give and get early feedback.

11:30 am. I moved to the session "LEGO Serious Play" of Olaf Lewitz. It's amazing what can be surfaced just by letting adult people play with a set of LEGO bricks. The game is to build models of individual constellations, teams, and organizations. These models can surface many aspects which would not have been surfaced only by talking to people. This needs further inspection from my side... finally I found a reason to buy some new LEGO sets.

12:00 am. Lunch break.

1:00 pm. I made a small walk around the venue to give my wife a phone call. And I never intended to participate in Martin Heider's outdoor session "Walk the Wire". As I walked by, it just looked interesting what they did between those trees so I moved closer. In the end I tried to walk the wire several times with one or two people guiding on my side. It was amazing how many similarities to coaching were discussed. Even if a way (of change) is difficult, it often is enough that a coach (or guide) exists inactive. For me this session was an eye-opener.

2:00 pm. The "Open OpenSpace" session of Sebastian Eichner and me was not needed as all attendees had enough other sessions to go to. Some people in the book's corner were inspecting books which suddenly brought me to the idea to start a spontaneous survey: I wanted to ask all attendees which one book they recommend other people should read. I posted the results of this ACCDE10 Survey: The One Book already.

2:30 pm. I went on to the "Agile Coach Camp 2011 Organizer" session and registered as volunteer.

2:45 pm. Finally I took a look at Heiko Stapf's session on "Marshmallow Challenge". They already had built a tower with spaghettis and a marshmallow on top of it. The tower was 65 cm in height and very stable. The marshmallow challenge is a nice game to demonstrate agile engineering practices.

3:00 pm. Last small break.

3:15 pm. All attendees of the Agile Coach Camp gathered in the biggest room for a final retrospective of the last 2 days. Mike Sutton was our moderator. We had great appreciations and the group felt energized!

4:15 pm. End-of-the-show. All attendees left the venue. We organizers cleaned everything up and took all important artifacts with us for our internal organizer retrospective in a few weeks. The Agile Coach Coach started off with 9 people heading back to Karlsruhe, which we arrived at 7:30 pm. It was just in time for me to drive home and put my little son Henry to bed.

The Agile Coach Camp was a great event. From my perspective, it was exactly the right people at the right time! Thanks to everyone for participating!
Posted by at No comments:

ACCDE10 Survey: The One Book

During the last few hours of the Agile Coach Camp 2010 in Germany I started to do a spontaneous survey with one simple question: "Which ONE book should I read?"

People's reactions were quite different. Some mentioned a book within a few seconds, others needed time to think of the most recommendable book. The question even triggered something in a handful of people so they started to brain dump a list of books. Several people hesitated and wanted to know about the context--should it be a technical book or a novel or related to a special topic? I just didn't care. The goal was just to name the one book everybody should read.

Have fun browsing the list of recommended books. Try following experiment if you want: take a look at the list but completely ignore the people who recommended the books. Choose the book which sounds most interesting to you. Now take another look at the list and take the recommending people into account. Which book would you choose now? Why? Think about your decision process and how it is related to coaching, leadership, and rock stars. Self-reflect on this and add your thoughts to the comment of this post if you want.

So here are the survey's results in order of their appearance.

Posted by at No comments:
Subscribe to: Comments (Atom)