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.

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.

Skillboard

Here at CHIP Online we introduced a Skillboard a short while ago. We did this, because we realized that it's hard to keep track of who knows what the larger the company gets.

The skillboard itself is quite easy: You put the skills in the rows (like PHP5, NoSQL or Meeting Moderation) and each row has 3 columns: Basic, Advanced, Pro. These 3 columns represent the knowledge state. Now everyone has the opportunity to put his name at the proper position: Which skill do I have at what level. If you're pro at PHP5, simply put your name in the pro column of the PHP5 row.

The advantage of this skillboard is: If anyone needs help with any technology, he/she can take a look at the skillboard and see if someone in the company has knowledge of it.

Teams Board

In order to visualize who works in which team, we introduced a team board in our company:

On the left is the team name, right to it the people working in the team. The blue index cards are used for the product owners, the yellow cards for the UX designers, the green ones for the team. The Scrum Masters and Kanban Coaches are indicated by the white circle.

Keeping track of changes

Finding a bugs' origin can be really annoying at times and quite often bugs are introduced by recent releases. In order to easily keep track of what happened when (mostly releases), we introduced a "timeline":

As you can see this timeline is simply a large sheet of paper where we write down date, time and a short description of the change, be it a release or an activated feature. This way, when a bug comes up, we can easily look up, if the error started on the date of the change, raising the odds to find the bug quickly.

Teams working together

5 weeks ago, 2 teams in my company decided to work together for 6 weeks, since the one team needed urgent help. The team helping out was my team.

We decided not to create a new team for these 6 weeks (as this new team would have spent at least 3 weeks to adapt to each other) but to keep a team a team. 

In order to manage this constellation we set up a board that works like a feature board but which visualizes the work of the 2 teams:

The cards on the actual board are not empty, this picture is photoshopped.

We drew 3 rows, each row representing 2 weeks time. The first column was for Team A, the second column for Team B and in the third column was the done column.

In order to visualize which stories are in progress we used pins in the shape of a flag:

Each team has its own color (Team A has white flags, Team B yellow flags). If a task is in progress, it's "flagged". In order to keep track of who did what, the index card stays flagged once it's moved to the "Done" column (you can see the little flags in the Done column on the first photo).

After 5 of 6 weeks I can say I'm really glad we used this board to organize the work of the 2 teams as it made organizing really easy and transparent.

Who's doing what?

When using Scrum Sprintboards or Kanban Boards you usually also want to show who's currently doing what.
We started with pinboards, pins and index cards. In order to visualize who was doing what we printed out a photo of every team member and pinned the photo to the current index card that was in the "Work in progress" (Wip) column.


A while ago we changed this system: We bought a large whiteboard and started using magnets instead of pins. This gave us the chance to print magnets for each team member thus you simply have to put a magnet on the Wip index card to visualize that you're working on it:

As you can see, we didn't use actual photos but gave every team member the opportunity to choose a picture of their liking. I chose Dr. Zoidberg. If you choose to do so aswell, don't forget to include a legend on your whiteboard so that everyone can see which magnet belongs to whom.

Every team member has 10 magnets, which makes it really easy to still know who completed what since the last standup, as we keep the magnets on the index card until the next standup.

You can order the magnets here.

Availability with a traffic light

This week I started a test to signalize my availability with a traffic light. It's a small one I bought at Amazon which lets me change the color by pushing a button. Only disadvantage of this model is that the current color is always blinking (product description didn't say anything about blinking), but this should be enough for the test.


What the colors mean:

Red: I'm not available, please do not disturb!


Yellow: Only disturb me, if it's really, really important (like we're-all-gonna-die-important)!


Green: Say hello!




As soon as I have made some experiences, I will gladly share them here.