#6 – Six Hats Retrospectives
This is transcript of the podcast. Download it here.
Agile Retrospectives are very important to the growth of an agile team and to the continuous improvement of the process. It’s a way to achieve kaizen, witch its a japanese word that means to improve continuously.
photo by furnari
According to the retrospectives.com website, a retrospective is a ritual gathering of a community at the end of a project to review the events and learn from the experience. No one knows the whole story of the project. Each person has a piece of the story. The retrospective ritual is the collective telling of the story and mining the experience for wisdom.
It’s very common for agile teams to have one retrospective meeting each iteration. A very good tool recommended by Rob Bowley is the Six Hats of Thinking. It’s a method develop by Dr. Edward de Bono that combined with the idea of parallel thinking, provides means for groups to think together more effectively.
According to the wikipedia, the premise of the method is that the human brain thinks in a number of distinct ways which can be identified, deliberately accessed and hence planned for use in a structured way allowing one to develop strategies for thinking about particular issues.
Dr. Bono, identified six different states represented by six hats with different colors. To apply this technique in an agile retrospective meeting, divide the retrospective in six parts, one for each hat, its recommend to spend about 10 minutes in each hat.
First start with the blue hat. Discussing with the team the objectives for the session and writing the output on the whiteboard.
After the blue change to the white hat. Now the participants raise and discuss anything from the last iteration which can be said to be a fact or information. Hunches and feelings and any discussion of reasons or other non information based output should be left for the appropriate hat.
The third hat is the yellow. Participants can only talk about the good thinks that happened in the last iteration.
Then go to the black hat. Participants can only talk about the bad things that happened, any negative criticism they have or worst case scenarios they can think of.
The next is the green. The discussion moves on to any ideas people have about solving problems or things that may add more value to the business or help in any way.
Now go the red hat, and give the participants a short period of time to come up with two statements each. These could be the issues that have stood out for them the most or an idea for solving a problem. These statements should be instinctive which is why you will give them very little time to do this.
Finally spend a little time with the group looking at the output and let the team decide on some actions to take in order to solve some of the bad things, keep the good ones, and apply some ideas in order to improve.
Well, that’s all for today. Thank you very much for listen, and please post your comments, questions and feedback at the agile podcast website or drop me a line at andrefaria at agilepodcast dot com. Let me know what you think, tell me about how your team retrospective meetings are going.
I’m André Faria, great to have you listening. I’ll talk too you again next week.
References
Read More#5 – Coding Dojos
This is transcript of the podcast, download it here.
Hello and welcome to the fifth episode of the Agile Podcast. I’m André Faria, your host.
Today’s topic is Coding Dojos. The first time I went to a coding dojo session, was in the University of Sao Paulo down here in Brazil. Since that day I have been learning a lot in coding dojos, I even started one at my company. It’s one of the best tools to help programmers to improve their skills I have ever seen.
Photo by Esther Gibbons
Programming is a learned skill. To be a master programmer you must practice! In this sense it is very similar to learning to play a musical instrument or a martial art. In order to became a master programmer, you have to take time to hone your skills, says professor Gary Pollice, of the Worcester Polytechnic Institute. A coding dojo is an extraordinary tool to achieve this master level.
A coding dojo is a coding session centered around a programming challenge. The challenge is small in scope and often based in Dave Thomas’ idea of Coding Kata.
A code kata is a small exercise to improve your programming skills by challenging your abilities and encouraging you to find multiple approaches. This give you the opportunity to play with code without fearing any consequences, and also discover and learn new methods, areas, algorithms, languages, libraries, etc.
Dave Thomas and others have published several different katas that you can try to solve. Danilo Sato wrote a post in his blog listing a lot of good sources of problems for coding dojos. Look at the references at the agile podcast website to find more information.
There are two main styles of Coding Dojos. One of them is also called Kata, and the other Randori.
In the Kata, someone presents a rehearsed choreography of developing a solution for a given problem. During the session, the group comments on the design and coding style and suggests changes to improve the solution.
The Randori is an exploratory form of a Kata where the whole group participates in carrying out an improvised choreography rather than following a rehearsed sequence of steps. Each member of the group takes a turn at the keyboard, adding to the code.
The Rules of a Randori dojo session may be different from one dojo group to another, but it generally follows these main guidelines:
- The coding challenge and the programming language is chosen and announced beforehand.
- There is a room with one computer attached to video screen.
- The presenter explains the coding challenge and starts the Randori with a pair from audience.
- One half of the pair is changed every 5 or 7 minutes.
- The pair on the keyboard should continuously explain what they are doing.
- The pair on the keyboard should stop when someone from the audience doesn’t understand something and continues when everybody is back on track again.
- The audience should give comments on design only when there is green bar, in others words, when the test is passing. (During red bar audience can only ask questions)
- The code should be always well refactored before starting to write new code
- The pair will use TDD
- The programming language to be used is announced in advance per session.
- The presenter acts as a product owner
I hope I have gotten the ideia. I really encourage you to try to find a dojo group in your city and participate, and if there is not one yet, why don’t you create one? Maybe your can start with team…
You can find a list of coding dojos around the world at the codingdojo.org website.
I would like to thank my friends Mary and Hugo who presented the coding dojo to me, and also to the fellows from a company in Brasilia called Sea Tecnologia, those guys use coding dojos even to find new people to work with them, and indeed they already hired good people that they met at dojos sessions.
Well, that’s all for today. Thank you very much for listen, and please post your comments, questions and feedback at the agile podcast website. Let me know what you think. I’m André Faria, great to have you listening. I’ll talk too you again next week.
References
- http://codingdojo.org
- http://wiki.agilefinland.com
- http://bossavit.com/dojo
- http://codekata.pragprog.com
- http://en.wikipedia.org/wiki/Kata_(programming)
- http://codingkata.org
- http://web.cs.wpi.edu/~gpollice
- http://www.dtsato.com/blog
#3 – Time for Learning
This is transcript of the podcast. Download it here.
Hello and welcome to the third episode of the Agile Podcast. I’m André Faria your host.
In this episode I’m gonna talk about the importance of having time for thinking and learning. On last November, Lisa Crispin has written a nice post about this subject. She mentioned some insights that she had, attending a Linda Rising talk.
Many people says they don’t have time for thinking and learning, but probably, they aren’t analyzing the root cause of their problems, and fixing them.
Time for Study
In order to have a good learning environment, it’s important that we don’t criticize or blame our teammates. Every team member should feel safe to raise issues and propose ideas, said Crispin. So the trust between team members is essential.
According to Crispin, a very nice approach related to learning is the Google’s 20% rule! Lots of companies, big and small, have done something similar to increase team members professional growth. For example, take Bluesoft, the company that I’m working for. We have a program called Bluesoft Labs (unfortunately all the videos are only in portuguese) that gives each team member 4 hours a week to study something that he or she thinks could be useful for the team, then the person presents what was learned in a talk of 45 minutes every two months. The talk is recorded and then published in our website, so it can also help other developers from other companies too.
Most of the people get books to read and them prepare a presentation about it. Clean Code, Working Effectively With Legacy Code, Refactoring Databases, The Toyota Way, and Lean Software Development are some examples of the books that have already been read and presented. This program really helped people to get into learning, and the challenge of presenting to the other team members gives every person a bigger sense of responsibility.
Try considering if a similar approach could be useful in your team. In fact, a lot of people says that they are not improving themselves because they don’t have time enough to study. Well, you know, it might be just an excuse. But giving the people the time to get into learning, and a helping the team to get accountable for their improvement as professionals, can really change the scenario and performance of a software development team.
There are also several other things like pair programming, coding dojos, attending conferences, participating in open source projects, agile retrospectives and book clubs that can help a lot to create a good learning environment to a software developer team. We are gonna talk more about those on the next episodes.
Well, I guess that’s all for today. Thank you very much for listen, and please post your comments, questions and feedback. Let me know what you think. I’m André Faria, great to have you listening. I’ll talk too you again next week.
Read More
