Sunday, December 23, 2012

How to kill your Retrospective Debt

The expression technical debt is widely used among the software development community. The debt is some work that should have been performed but, for any reason, there was no time to do it. Some alternative solution was found and now we are living with it. The idea of debt is that you'll have to pay for it in the future, and you'll pay more the later you pay, maybe because the code will become harder to maintain.

Sometimes you find a group (maybe a team) where there's a lot of conflict, unsolved problems or difficult communication. Maybe they have been doing retrospectives but the hard topics have never been raised. Maybe there's a lack of trust and transparency and everybody seems burnout. You have to address it, and it's not easy (if possible at all).

If all these problems had been addressed when they appeared, maybe the tension would not be that hard. If the retrospectives had worked maybe the team would feel more motivated. As long as there are things that could have been addressed in retrospectives and weren't.

I'll call it Retrospective Debt. The later the team address the problem, the harder to fix. It's a debt that the team is going to pay later. What to do?

There's no unique solution for all teams, but I'm sure that doing exactly the same they were doing won't fix anything. Maintaining the same retrospectives won't work. And a single action won't fix anything. And it won't be quick. So, faith and patience.

Maybe you'll have to think in the five dysfunctions of a team, perform some dynamics in the team like a Lego game, introduce the Core Protocols,  perform retrospectives in a different way, use some clever coaching techniques or just have some beers.

Start as soon as possible, draw a plan, address people problems. Don't look for metrics, please.

And above all, don't let your Retrospective Debt grow.

Sunday, December 9, 2012

Global Day of Code Retreat 2012

Last year I was in the Global Day of Code Retreat in Barcelona, held in Runroom (their former office), organized by Agile-Barcelona and facilitated by Jaume Jornet. It was a great experience, and I learned a lot, not only about programming, but about teamwork and sharing.
This year the event was planned again in Runroom, but for difficult dates: public holidays and the Barcelona Developers Conference were difficult rivals. And this time I was a facilitator.

I agreed to co-facilitate the event with José E. Rodríguez Huerta and I joined the facilitators group and attended a training using Google Hangout. In the training we were people form New Zeland, Sweden and Australia, with an amazing trainer: Jim Hurne. The organization of the event, the sessions, the connections with other cities, and the focus of the exercises were all good lessons.

Then I started contacting with the groups around Spain that were having the same event to organize live connections.

Everybody was distilling an energy that was impossible to not be infected.

The day of the event 11 guys showed up in Barcelona (30 had confirmed), and we opened a Hangout during all day so we could be chatting with other cities. Valencia (Ricardo), Madrid (Juanma), Bilbao (Jorge), Berlin (Greg) and Viena (Michael) were some of our connections. We followed the schedule and had sessions with interesting restrictions (ping pong, no conditional, ask don't tell,...) and the programmers used Ruby, C#, Python, Java, C++ and JavaScript.

The retrospective was interesting. They suggested:

  • Having a retrospective reviewing the code someone has writer
  • Choose a language to use everybody in some iterations (and learn the basics of language beforehand)
  • Try a randori, maybe with this language.
  • More on legacy code.
  • And choose a cool mechanism for the raffle 

Out of their confort zone. No pressure for getting the problem done. Try new things. Pair with new people. Thinking in a different way.

This crazy idea from Corey Haines deserves my respect. So many people crazy to become better professionals. And having fun.

Big Thank You.