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.

Different estimation methods compared

A while ago, I conducted a workshop about agile estimation. In this workshop, I showed the participants three (of many) different ways of estimation: Planning Poker, Magic Estimation and the Team Estimation Game.


Planning Poker [Interaction level: high]
Probably the classic estimation method. The product owner reads a user story, the team estimates using the planning poker cards. If there are any differences in the estimation, the team starts a short discussion about everyones different opinion of the story at hand. If after about 3 estimation rounds there is still no consensus, the story is obviously not clear enough and everyone tries to gather new information until the next estimation session. Planning Poker usually uses story points, although I've already seen cards with animals on it (quite a nice idea actually). The estimation session ends when either all the stories are estimated or when time is up.
At the workshop I let the participants estimate what it takes to clean a kitchen. During estimation the team realized, that story #1 and #4 are too large and split them up to 2 and 3 stories.

Magic Estimation [Interaction level: low - medium]
Probably the second classic estimation method. Prepare a flipchart (or similar) where you draw an arrow going up (symbolizing the increased complexity) and write your references beside the arrow, be it user stories, T-Shirt size or whatever you feel most comfortable with. The product owner reads a user story, writes it on a post-it and puts the post-it on the flipchart. This procedure is repeated for about 5 stories. The team then gets 2 minutes to stand in front of the flipchart and silently move the post-its to where it thinks they belong. If during the 2 minutes you realize, that a story is wandering around a lot, you might want to talk about some details after the 2 minutes. This whole procedure is repeated until there are no stories left or the time is up. 
At the workshop the result looked like this:

Team Estimation Game [Interaction level: low]
An estimation method I found a while ago here (page is in german) and have used at the workshop myself for the first time. This method is quite similar to magic estimation. As with magic estimation you need a flipchart prepared. The product owner brings all the stories on index cards to the estimation and lays them, heads down, on a table. Someone from the team (whoever wants to go first), takes the first story card, reads it out aloud and then puts it on the flipchart where ever he/she thinks it belongs. Now the second one in the team pulling a card can either put it besides, above or below the first story read. From the third story on, every team member has 3 possibilities for his move:

• Read the next story card and put it on the flipchart
• Reassign a story already on the flipchart, also explaining why he does that
• Skip

When reassigning a story, you might also mark the story with a dot. The more dots a story gets, the more opinions about it differ and you should discuss it in detail. Like with the two other estimation methods, the team estimation game ends when there are no more stories left or when time is up.

At the workshop the result of the team estimation game looked similar to magic estimation:

Conclusion:
In my time as a developer I only used planning poker (apart from any workshops or similar I attended). After having conducted this workshop, I still prefer planning poker over magic estimation and team estimation, since the interaction with planning poker is way higher than with the other two (which is also the conclusion of the workshop participants). That doesn't render magic estimation and team estimation totally useless, there are still valid use cases for them. They are actually quite useful when you need a lot stories estimated in a short time, e.g. at the beginning of a project. Other than that my favorite remains planning poker.

On conferences

You can catch me next week (June 4rd - June 6th) at the International PHP Conference 2012 Spring Edition. I will be speaking at the agile day about "The five dysfunctions of a team" and - if you do speak german - about "Stolpersteine agiler Methoden" together with Sebastian Bauer.


Hope to see you there!

Histogram: Team communication

Based on the satisfaction histogram from "Agile Retrospectives - Making good teams great" (p. 64 - 67), I did a communication satisfaction histogram in our last retrospective.
To measure how the team thinks about the communication between each other they could choose between 5 states:

"The communication in our team is ..."

• 5: ... outstanding
• 4: ... mostly very good
• 3: ... satisfactory, but needs to be improved
• 2: ... bad and needs to be improved badly
• 1: ... a disaster

Team members vote anonymously, for scoring you can use dots:

I also left some space for further comments (write them on Post-Its and put them on the flipchart).

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.