Posts

It’s been exactly one week since I came back from Brazil and now it’s time to share some of what happened there. Like I said before, this tour supposed to be a “mini” tour of three days in companies from Florianópolis, city hosting the Agiles2009 conference. Here are some of my findings: It doesn’t take long to get to know a company My biggest fear was that the time wouldn’t be enough to really get to see people working, but fortunately I was proven wrong....

Writing check-in messages is normally a reflection time for me. And lately I’ve been inclined to describe why I changed the code, instead of just describing what I’ve changed. I know I have to consider that all the time, but it can still serve as a last sanity check. It makes me think: “Am I really adding a valuable change to the codebase?” Do you agree with this approach? Think about it next time you check-in and then let me know in the comments....

Most of recent software development approaches bring code closer to business. According to Agile we should write software with customer collaboration, responding to changes and constantly delivering business value. Lean is all about creating a flow of business value and removing waste. Even Domain-Driven Design advocates having an ubiquitous language between programmers and business people. It’s interesting how most of state-of-art approaches to software development are focusing on business, programming itself is still seen by many as a completely technical discipline....

Tomorrow I’m flying to Brazil and will have a chance to do do something I wanted for a long time: a pair programming tour. The goal is simple: work with people in their companies. Not speaking, consulting or running coding dojos. I want to experience the everyday routine, learning their ways and hopefully contributing with some of my skills too. This idea came from Corey Haines’s programming tours and the work of other craftsmen like Enrique Riepenhausen, Dave Hoover and Antony Marcano from PairWith....

This week I had the chance to help the guys from the London Ruby User Group running a coding dojo for ~50 people. It was the largest dojo I’ve been involved so far and it was really interesting. To allow everyone to participate, the attendees were divided in three groups: Ninjas, Pirates and Zombies. Each group would solve the minesweeper challenge using the randori approach and at the end each group had a chance to show their solutions....

Many people tried different ways to define what “done” means in a software project (as you can see here, here and here). My experience, however, is making me believe that the problem may be in the word itself. Saying something is “done” always creates different expectations depending on who we’re talking to. And having to create a specific definition for a word means it will only be valid for the people who agree on it, and as long as they remember it....

On October I’ll have another great reason to travel: running a coding dojo at the Latin-American Conference on Agile Development Methodologies (or simply Ágiles2009). And if having an event like that in back in Brazil wasn’t good enough, the conference will be in Florianópolis, the city where I studied and used to work before moving to London. How cool is that? For this session, it seems like once more the challenge will be how to prepare a session for more people than we’re used to....

After working with stand-up meetings for a while I feel that this practice acts like a thermometer for an agile team. As a constant status report, it demonstrates how most of the other practices are being applied and how good is the team communication in general. That’s why I believe is important to be conscious about what happens during them. A stand-up meeting may hide problems if: It doesn’t have an exact time to start It doesn’t happen because someone is not present It’s a trigger for technical discussions It’s not focused on to the plan It doesn’t contribute to continuous improvement It’s a report for a single person, not the team People don’t stay close to each other It’s frequently interrupted It doesn’t include the whole team People don’t remember what they did on the last day It’s moment where most of the problems are raised It takes more than 15 minutes It doesn’t happen every day It doesn’t feel good These are all simple issues which can easily be addressed....

On the last April’s fool, Philip Calcado announced that ThoughtWorks was about to start an office in Brazil. At few months later and this message on Martin Fowler’s twitter proves the affirmation was not that far from reality: “My colleague Sid Pinney is investigating setting up a ThoughtWorks office in Brazil - talk to him at […]” The interesting thing about this is not the fact itself, but the reaction it’s causing....

The following parable has made me think about the different views on the software development work: A traveler came across three individuals working with stones. When asked about what he was doing, the first one replied, “I’m a stone cutter. I cut stones because I need the money to support my family”. The traveler then decided to ask the second worker, who answered, “I’m a great stone cutter. I can use all my techniques to produce the best shaped stone”....