Agile Podcast by André Faria

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.

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 teamthe 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.

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 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’l

Hello and welcome to the forth episode of the Agile Podcast. I’m André Faria your host. Let’s talk about pair programming today.

Pair programming is an agile software development practice in which two programmers work together at one work station. One types in code, while the other reviews each line of code as it is typed in. The person typing is called the driver, and the person reviewing the code is called the navigator. The two programmers should switch roles frequently.

Let’s see some benefits of pair programming according to the c2 wiki.

1. Focus and discipline: Pairing partners are more likely to “do the right thing” and are less likely to take long breaks. You know, when we are alone, working in a computer there are many things that can distract us from the actual work that we should be focused. Twitter, e-mail, blogs… Working with somebody else tends to help us to not get distracted.

2. Better code: Pairing partners tend to come up with higher quality designs.

3. Improved morale: Pair programming, done well, is much more enjoyable than programming alone, done well. (On the other hand, pair programming done poorly is much less enjoyable than programming alone done poorly.)

4. Collective code ownership: When everyone on a project is Pair Programming, and pairs rotate frequently, everybody gains a working knowledge of the entire codebase. Have you ever worked in a project that just one developer knew how to deal with some piece of code? Well, pair programming really avoid this kind of problems.

5. Mentoring: Everyone, even junior programmers, has knowledge that others don’t. Pair programming is a painless way of spreading that knowledge.

6. Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.

The most important benefit in my option is synergy effect. It’s like Gramma use to say: “two heads are better than one”. What I mean is that working in pairs, the two programmers are able to produce code that alone they wouldn’t.

According the Extreme Programming website, pairing is a social skill that takes time to learn. 
 Don’t expect people to be good at it from the start. It helps if you have someone on your team with experience to show everyone what it should feel like.

Ping Pong Pairing

Alexandre Martins wrote in his blog about a very interesting technique to make pair programming even more fun and totally integrated with Test Driven Development. It’s called Ping Pong Pairing.

It happens when the developer 1 from a pair implements a test for a given feature and see it failing, then passes the keyboard to developer 2 who makes the test pass, do some refactoring on the code and implements another test, passing the keyboard back to developer 1 to do the same thing and continue until the feature is done.

This really makes programming funnier and more dynamic . It is worth a try!

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.

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 to you again next week.

On the last episode I talked a little bit about Martin Fowler’s first talk  at the Agile Brazil 2010 Conference. In this episode, still about the conference, I would like to talk about Manoel Pimentel’s presentation on coaching.

Pimentel was a pioneer in coaching agile methods down here in Brazil, he is the chief editor of the brazilian magazine Agile Vision (in portuguese, Visão Ágil).

Pimentel did a great job introducing the coaching concepts and its essence. He started his presentation with a little joke, asking people to close their eyes and try thinking positively to make a paper in their laps levitate. Nothing happened. Why? Because of the lack of action, he explained. The message here, is that the same happens with us in real life, when we want something to happen, but do not take action to make it actually happen. The essence of coaching according to him is to help people discover the right actions to take and then act in order to achieve their goals.

The coaching process has two main roles. The coach and the coachee. The coach is the one who conducts the process and coachee is the one who is being coached. The coachee could be a person or a group of people, like a software development team, for example.

The coach should help the coachee to discover how to achieve his or her goals instead of telling him or her what to do.

Talking about goals….

Do you have one? Think a little bit about that. What’s your goal?

What motivates you to achieve it?

Once you have  a goal in mind, think about the forces in favor and the forces against your goal. Identify those forces. What you help you achieve your goal? What would make it hard?

What is important for you?

Does you goal have any relationship with that?

Are your current actions connecting you with your goal?

Are them adding value to your goal?

What do you gain if you achieve your goal?

What do you loose?

Well, I think you got the idea. Those are some questions that a coach asks the coachee, focusing on helping him or her to have a good return on the energy invested in order to achieve a goal. You should invest your energy, your effort, and your time in actions that connects you to your goals, said Pimentel. Asking those kind of questions in agile retrospectives could be really helpful.

Another good advice is to have milestones. Divide your path, so your can better visualize it. That’s something that is done through the iterations in agile software development, isn’t it?

The strongest point of the coaching process is that it generates responsibility in the coachee. When someone just tells you that you should do something, and then it goes wrong, you can blame the person who told you, but when you are the one who actually decide the path your are going to take, it is a totally different approach, there’s no one to blame. It’s your own choice.

Well, I guess this is it for today. Thank you very much for listen, and please post your comments, questions and feedback. I’m André Faria, great to have you listening. I’ll talk too you next week.

Last week we had the Agile Brazil Conference, which gathered more than eight hundred people from different states of Brazil, England, France, Canada, and the United States. Martin Fowler, David Hussman, and Philippe Kruchten were here.

Today I would like to talk a little about Martin Fowler’s key note. He divided it in three talks of 20 minutes each. The first he called the essence of Agile. After talking about the origin of the agile manifesto, he explained a phenomenon that he calls semantic diffusion and according to him it is happing in agile software development right now.

After getting popularity the ideas can easily get lost. People are just thinking about what the process suggest them to do, and in fact, a lot of people says that they doing   agile for 3 or 4 years, but then, when we go to see what they are really doing, we see something that we would never call agile.

Fowler talked about the changing nature of software, and that the difference of agile is that planning and execution is done in a very high frequency, and then it is possible to learn from what happens in each iteration. This is not a chaotic approach because there is still a lot of planning on it. The difference is that agile doesn’t try to predict everything, and releases early and often. Agile focus on how much value is delivered instead of being concerned about up-front plans.

Adaptive plan needs evolutionary design, and this needs as much design as the other approaches but in a different way (refactoring, self test code, continuos integration, simple design). Read Fowler’s article “Is design dead?” for more information.

Another aspect of agile, according to Fowler is that  the process should change over time. Evolve. That’s self adaptability. That’s, for example, is the importance of agile retrospectives. Its an ongoing exercise to improve our work continuously, said Fowler. He mentioned a quota from Kent Beck that says “i n software development perfect not an adjective it’s a verb”.

Well, I guess this is it for today. Thank you very much for listen, and please post your comments and feedback. I’ll talk you again next week.