Thursday, July 18, 2013

Active learning cycle

Many teams seem to struggle with keeping track of their improvements from the retrospective. One really useful tool for that is the active learning cycle.

Take a sheet of flipchart paper and divide it into 4 areas: Keep, Try, Breaks and Accelerators. The most common form looks like this but you can always use a different form if it suits you better:
Active Learning Cycle
At the end of the retrospective you put your actions/improvements you decided on in "Try". Those are things that you want to try out. Remember to put the active learning cycle afterwards in a place where everybody can see it, near the team board would be a good place.

Not later than in the next retrospective you use to active learning cycle to decide what you want to do with the actions that are on the cycle.

  • Did you like it and you want to continue doing it? Put it in "Keep" and keep on doing it
  • Did you think it rather impeded you and you want to stop doing it? Put it in "Breaks". This could be things like "Standup at 2pm", "Digital team board", etc. And, more important: Stop doing it ;-)
  • Was it something that helped you but which is nothing you can really keep on doing all the time? Put it in Accelerators. This could be things like "2-day team offsite" (It was an accelerator for the team, but you can't do a 2-day offsite every week).
You don't have to wait though, the active learning cycle is supposed to be a "living" artifact, so you can always move post-its around when you feel it's time to do so. Of course you can also move things from "Keep" to "Breaks" or "Accelerators" if at some point it isn't helping you anymore. Since your active learning cycle will be very full at some point you might have to remove post-its someday. The moment, when you remove something is totally up to you, but from my experience it's best to only remove them, when they've already become second nature to the team.

Wednesday, July 3, 2013

Why is the 4 week sprint still the literary default?

I’ve been wondering for a long time why the 4 week sprint still seems to be the default in Scrum literature. Even the State of Scrum Report states there is a 38% majority using 2 week sprint while 29% use 3-4 week sprints (page 25). Given that 3 and 4 week sprints have been merged in the statistics implies that the actual percentage amount of teams using 4 week sprints is even lower than 29%. Yet in the same report insight #2 states that “a Sprint is one iteration of a month or less that is of consistent length throughout a development effort.” completely ignoring its own results (page 38). Also, why isn’t the book “Software in 30 days”, released in 2012, called “Software in 14 days”?

Part of Scrum and agile in general is to generate feedback as quickly and often as possible, using 30 day sprints you spend a whole lot of time between two feedback cycles. In addition 4 weeks of time is so much that it’s really hard to look back at them when sitting in a retrospective. Can Scrum literature please inspect & adapt and use the 2 week sprint as the new default?

Friday, June 21, 2013

How to improve your retrospective

Marc Löffler did a session about "How to improve your retrospective" past weekend at agile coach camp 2013. Result was a list of possibilites what you can do to improve your retrospective and maybe sometimes vary the usual format as described in "Agile Retrospectives".

Since the results speak for themselves, I will just post the photos of the results here:


Wednesday, June 19, 2013

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:

Tuesday, June 18, 2013

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.

Monday, June 17, 2013

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!