Coaching Dojo

You probably already know Coding Dojos (I'm not going to go into detail here, so if you don't know Coding Dojos yet you can get all the information at codingdojo.org). At agile coach camp 2013 (accde13) I heard for the first time that there is something similar for coaching called Coaching Dojo.

The goal of a coaching dojo is improving your skills by practice and by being exposed to various coaching styles. In Martins session at accde13 about Coaching Dojos we used the following setup:

Coaching Dojo setup

Split up into groups of 4-6 people. One person in the group will be your seeker. This should be someone who has a real-life problem/question he needs solved or answered. Nevertheless keep in mind that the goal of the coaching dojo is NOT to find a solution for the seeker but to train your coaching skills (although it might occur that the seeker's problem is solved). Next you need 2 people from the group that are the first to coach the seeker.

Do the coaching in timeboxes (we used 10 minutes). During this time the spectators watch and take notes (and most important: do not take part in the coaching!). When time is up, give feedback to the coaches. Usually most of the feedback will come from the spectators, as they are the ones watching from the outside. Then rotate the coaches and continue coaching, meaning the seeker will stay the same. Usually you do 4 rounds of coaching.

I thought it was exhausting talking a few times about my problem (in our group I was the seeker), so you can consider switching the seeker after a while (and with it the topic). I would leave this decision to the group.

Additional reading:

• http://agilecoach.typepad.com/agile-coaching/2010/08/improving-agile-coaching-skills.html

Sprint Burndown Chart: Yes or no?

I don't believe in sprint burndown charts. So far, in every team I've been Scrum Master for, not one developer really wanted to update the burndown by himself, meaning I was either the burndown-monkey or I found myself asking the team to update the burndown regularly. And since I don't get the real advantages of burndown charts, I struggle to explain the team why it's important to maintain the burndown chart. I guess that's what you call a chicken/egg-problem.

The burndown chart is supposed to show the current status of the team and indicates whether the team is likely to successfully get everything done in the sprint. But: In my opinion you don't need a burndown for that because all the information can be read from the sprintboard. Nowadays sprints are mostly 2 weeks long (I haven't heard from anyone using longer sprints than that in a long time), so it's relatively easy to overlook this time. While I think that a burndown is useful with 4 week long sprints, in sprints up to 2 weeks length it's basically just maintaining an information that is already on the sprintboard.

I've been trying to solve this dilemma for quite some time now but haven't found a real solution yet. First I tried to find the reasons for a burndown chart. Having found none that did satisfy me, I thought: Well, maybe there's another good, intuitive way to visualize the current status. One that would maybe integrate directly into the sprintboard. So far, I haven't found one.

Being on agile coach camp 2013 past weekend, I took the chance and conducted a session called "Burndown Chart 2.0" hoping to find this intuitive, sprintboard-integrated way.

Although we haven't found one, the session has helped me a lot to remind myself what the burndown chart is about, whom it is for and whether it is useful or not. First of all the burndown chart is a tool by the team for the team and no one else, no manager, no stakeholder, no one else. Second its main purpose is transparency: Transparency where we are, transparency what has happened.

Deriving from the fact that it's a tool by the team for the team, the burndown chart should be used when the team wants to use it. If you feel that a burndown chart could help you in your current situation, then use it, otherwise there's probably no real reason to use it. Using a burndown chart is not essential.

Apart from that it doesn't always have to be a chart. Depending on what you want to visualize it can also be a traffic light (visualizing if the team thinks the sprint will be successfull) or any other visualization you can think of.

How to praise your devs

There was a quite controversial but very fruitful and inspiring conversation about "How to praise your devs" from the viewpoint of a Scrum Master. Here are the few notes I took for myself:

• Sentences like "Thank you that you brought up that topic, it really helped the team move forward" basically are another way of saying "You did well"
• "You did well" sentences are a judgement of the work the developer does and are almost always seen violent. Least of all is a Scrum Master the one who is to judge the work of the developer
• When appreciating someone tell them how you feel (NVC) instead of judging the work they did
• Try to use appreciation instead of praise
• Base your feedback on your relationship with the other person
• Align your appreciation with the purpose of the team. If the team does not have a purpose or doesn't know its purpose give the team exactly that
• Developers do communicate and they communicate a lot. But they do it in their own ways and other people are sometimes seen as intruders

Solution Focus

Past weekend I attended the agile coach camp 2013 and one of the sessions I've been to was by Klaus Schenck about "Solution Focus".

Solution Focus is a coaching technique (and in more general a mindset) where you set your focus on solutions and solving problems when coaching and talking to people.

Solution Focus Matrix

One of the tools helpful to understand Solution Focus is the SF Matrix. The vertical axis represents the degree of happyness, the horizontal axis time.

Solution Focus Matrix

This leads to 4 quadrants:

• On the upper left are things from the past that we're feeling happy about
• On the lower left are things from the past that we're feeling sad or angry about
• On the upper right are things in the future that we're looking forward to full of expectation
• On the lower right are things in the future that we're worried about

The goal of Solution Focus is to reach the upper right quadrant, we wanna be optimistic about the future. In order to do that we first need to identify in what quadrant sentences said lie. Some examples:

Before Scrum we had no problems. Now everything is bad!

The way management talked to us a few years back was absolutely horrible.

Hey, we want to start with Kanban. Could you help us please? 

As you may have realized while reading the examples the real world isn't always as easy as a model and words and sentences can easily fit in more than one quadrant. The whole point of Solution Focus is to lead the coachee / dialog partner to focus on an optimistic future and we can reach that by asking the right questions.

• If you realize your coachee is happy about the past your questions should be about how the past experience could be repeated
• If you realize your coachee is unhappy about the past your questions should be about how she survived and what she learned from that experience
• If you realize your coachee is worried about the future your questions should be about what she would like instead or how she would want to do things differently
• If you realize your coachee is already optimistic about the future your questions should make her want to kick off right away

Naturally asking the right questions isn't that easy and additionally questions like "What did you learn from that experience?" feel rather odd to the coachee (as they would to everyone), meaning your focus is on getting that questions answered but not necessarily asking it directly. One possible way would be to ask about the feelings and go on from there. But that is only one possibility.

Solution Focus Scaling

A second tool for Solution Focus is a ladder / scaling technique:

Solution Focus Scaling

SF Scaling is used to show where you are right now. You could use a flipchart, draw a ladder and ask your coachee to draw where he thinks he stands. However using a room (or similar) as Klaus did with us in his session seemed more impressive to me. The length of your room represents the scale from 0 to 10.

1. Ask your coachee to stand where she thinks she is with her problem right now, her sight towards 10.
2. Ask her to turn around and ask how she feels (this will most likely be something like "I can see that I'm not still at the beginning", "I'm farther than I thought", etc.)
3. Ask her to stand at 10, sight towards 0 and ask how she feels now (answers will be most likely something like "this is really far away" or "I feel uncomfortable standing here"). 
4. Ask her to stand where "good enough" would be and ask her how she feels
5. Ask her to return to the original position and ask her how she feels now (the answer will probably include that she's seen the "perfect state" and that things look differently for her now)
6. As a last thing ask her to take a step forward and then turn around. Ask her how it feels like to have taken a step forward.

When we did this excercise Klaus asked us to pick something that we care about and want to improve for ourselves, I chose my rhetorical skills. Seeing where I am right now and where I can be with only one step forward got me inspired to finally take that rhetoric workshop I've been wanting to do for 2 years now. Thank you Klaus for that!

The evilness of bugtrackers

It is quite common for software projects to use bugtrackers. Personally, I don't really like them and usually like to advice teams to stop using them. Let me tell you why.

Back in 2008/2009 when I had my first experiences with Scrum and agile software development, I was taught to "fix bugs immediately", meaning: If a bug comes up, you fix it.

We adopted this point of view and as soon as a bug was found we would write an index card for the bug put it in the todo-column of a lane of a story we were currently working on. Not later than in the next standup someone from the team took the bug and fixed it (admittedly this worked most of the time, there were times when a bug could have stayed in the todo lane for a day or two longer). We kept the bugtracker alright, but the only reason we did so, was to enable users to easily submit bugs and be informed when we have closed the bug. If a new bug came up in the bugtracker, we also wrote an index card and put it on the board with the bugtracker issue number as additional information.

As putting bugs in a lane they had nothing to do with was rather confusing we introduced a bug-lane at the top of our sprintboard, by this also visualizing: Bugs that occur have top priority! Basically this meant that every bug caused disturbance.

What effects did all this have on us?
First off, let's face it: Nobody really likes fixing bugs, it's annoying. The immediate disturbance added even more annoyance, meaning every time a bug came up, we were really annoyed. Annoyed about ourselves that the quality of our software was so low. To speak numbers: In 2008 we had an average of 25 bugs per month.

What happened to us was that we started looking for ways to produce less bugs. Obviously, we succeeded as we could cut the defect rate in half in the first year:

Average amount of bugs per month

All we did was implement one simple agile value: transparency.

Let's get back to bugtrackers.
Before Scrum we also used bugtrackers and kept collecting bugs (which I now believe is sometimes the most important use-case of a bugtracker). Once in a while we would organize a "bug-fixing-day" where we tried to fix as many bugs as possible in one day only to realize that at the end of the day there were still a lot of bugs left, we felt like Sisyphus. Bug-fixing-day soon became a dread and we tried to do it as seldom as possible.

Also I have seen projects were 150 bugs were accumulated over the course of a 3/4 year only to spend a whole month at some point almost doing nothing else than fixing bugs and at the end still having 50 open bugs although having fixed 200. If it hadn't been for the approaching release date probably eveb more bugs would have been accumulated. The team did the opposite of implementing transparency by hiding the bugs.

In this context the "fridge-effect" also applies: You do have a vague knowledge of what's in your fridge but as long as you don't open it, you don't exactly know what's in it. Moreover you have to actively open it, to see what's in it.

Situations like these two mentioned have a few impacts:

• The developers are annoyed and demotivated and try everything to postpone the bugfixing as much as possible.
• Any measured velocity of the team has no value at all since there is a lot work that has to be done some time later.
• Any release planning has no value at all since there is no actual velocity to begin with.
• Any calculated or tracked development costs have no value at all since there is a lot of work that has to be done some time later and there is no usable velocity.
• Any calculated ROI has no value at all since there were hidden costs some time later.

What you can calculate in a stunning accuracy though is the average cost of a bugfix. Way to go!

Let's continue with response times.
Imagine you're spending your winter holidays in Prague and you're staying at a really nice hotel. Your room is nice and all and you feel comfortable but unfortunately the heating isn't working and your room is as cold as it is outside. You decide to go the check-in:
"Hi. The heating in my room is broken. Can you please fix it?"
"Of course. I will just write it down on our Needs-to-be-repaired-list and we'll get back at you asap! In the meantime use this warm blanket as a workaround."
The next day nothing has changed, so you decide to cancel your stay at the hotel (after all you paid a lot of money for it) and go to another hotel. 2 years later you get a call from that first hotel: "Hello Sir, we just wanted to inform you that we fixed the heating in that hotelroom of yours".

Sounds silly? In software projects this actually happens all the time. I've had bugs filed for Mozilla Firefox that only took 2 years until they even got any kind of response or bugs for Netbeans (mostly for the PHP components) that took 3 months. Needless to say, I don't use either product anymore. Although it's not the only reason, I'm not using them anymore, all these cases made me feel like I'm not taken seriously as a customer. And when that happens I start looking out for alternatives, which are usually easy to find. And since software always has users, there is always someone who wants to be taken seriously.

All in all my experience taught me that bugtrackers support the lazyness of developers and the tendency to low-quality-software where customers are not taken seriously. These are the reasons why like to advise teams to stop using them.

Update:
As Volker Dusch correctly stated I left out the part about "don't spend time managing lists of bugs. Just fix them". That was intentional and is covered by the first link in "Additional reading".

Additional reading:

• When should we fix bugs?
• Viehzugs in Scrum - Bugs vom Product Backlog trennen oder nicht?
• Some changes I suggested in 2009 for Netbeans are even still open and got nothing more than some reassigning

A christmas retrospective

This is a quite nice end-of-the-year-retrospective method I read about first last year on Boris Glogers blog. Since the original post is in german and doesn't tell you how to prepare, here is a detailed preparation instruction and the how-to itself, both in english. One warning ahead: Preparation for this one takes a lot of time. But it's totally worth it.

Time needed
Preparation: A few hours
Playing: 60 - 120 minutes, depending on your team size

Preparation
First of all take a flipchart paper (or something of at least similar size - depending on your team size you might need a larger sheet of paper, you will understand why later on) and draw a large christmas tree. Draw it as large as you can and don't forget the star on the top, after all you want the tree to look nice:

Now draw some small candles and christmas baubles in 2 colors. Draw one candle and 2 baubles for every team member. If you're lazy you can draw one candle and one bauble in each color and then copy it a few times (that's what I did ;-)

Once you have your candles and baubles finished, draw a present and a christmas sock for every team member and write their names on it. In order to keep the presents and socks individual you might want to not copy them ;-)

Cut out the candles, baubles, presents and socks. After that create a matrix putting the socks on the left of the tree and the presents under the tree:

Last part of preparation is to buy some cookies for the retrospective itself :-)

How to play

Give everyone a candle. Set the timer to 5 minutes and ask "What does motivate me getting up and going to work?". Everyone should write some words about the question on the candle (answers could be: I love our team, the current project is awesome, etc.). When the time is up everyone in turn glues her/his candle on the tree where her/his name crosses itself and says a few words about it. A glue stick might come in handy ;-)

Give everyone 2 baubles for every other team member. Set the timer to 10 minutes and ask them to write something about every team member. On one bauble they should answer the question "What did I like most about working with you?" (answer could be something like "I really liked pair programming with you") on the other "What do I hope I'll be able to be doing together with you next year?" (answer could be something like "I know you're really good at test driven development, so I hope you could teach me how to do it, at best while pair programming").

When you're done filling out the baubles, everyone in turn gets their presents. Let's assume you are the first to get your presents. Everyone in the team tells you what they wrote about you on their baubles and glue them at the corresponding positions in the tree-matrix (there are 2 for every combination). Once you have received all your presents, say a few words about how you feel and continue with the next person in your team.

Once you're finished, your tree should look like this:

Definition of done traffic light

This is a quite nice retrospective method I learned from agile42. Prepare the definition of done of your team by writing each point on a single line and put three columns besides every point. Paint the columns in red, yellow and green. The now colored columns stand for "We did that well" (green), "We did that ok" (yellow), "We didn't to that very good" (red).

In the retrospective every team member puts a dot in the colored column expressing his view on how good the team applied this point of the DoD. The result looks like this:

Now you can pick the 3 points with the lowest overall rating, discuss them (20 min timebox each) and develop optimisations for them.

You can do the same for your working agreements.