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.

Monday, October 29, 2012

Drive

The surprising truth about what motivates us
De Daniel H. Pink. 260 páginas. 2009, Riverhead books

Lo que nos motiva ha evolucionado junto a nuestra manera de pensar: nuestro Sistema Operativo de la Sociedad. Inicialmente, con Motivación 1.0, lo que nos motivaba era la supervivencia: cubrir nuestras necesidades biológicas.

Una vez cubiertas estas necesidades en la sociedad, los humanos somos algo más que la suma de nuestras necesidades biológicas así que para motivarnos en Motivación 2.0 buscamos recompensas y evitamos el castigo: "palos y zanahorias". Este tipo de motivación a veces funciona muy bien, pero no siempre. Puede funcionar cuando el trabajo se puede realizar siguiendo unas instrucciones, pero cuando no es rutinario, es artístico o requiere empatía, no.

Algunas mejoras de la Motivación 2.0 han dado lugar a la Motivación 2.1, donde aparecen ideas como la flexibilidad o el empowerment.

El dinero no es suficiente motivación. De hecho, tal y como lo ve Pink, "el mejor uso del dinero como motivador es pagar a la gente lo suficiente como para quitar el tema de la mesa." Hay medidas que pueden ser motivadoras, pero hay otras que únicamente son de "higiene": su ausencia puede ser desmotivante.

El mecanismo de motivación que hay detrás de la Motivación 2.0, palos y zanahorias, tiene muchos defectos:
  • Pueden eliminar la motivación intrínseca
  • Pueden reducir el rendimiento
  • Pueden machacar la creatividad (podemos estar demasiado centrados en la recompensa)
  • Pueden provocar el hacer trampas, los atajos y el comportamiento no ético
  • Las recompensas pueden ser adictivas
  • Pueden fomentar el pensamiento a corto plazo
  • Las recompensas suponen una señal de que la tarea no es deseable

El consejo que da el autor al respecto de las compensaciones por trabajo realizado es que "cualquier recompensa debería ser inesperada y ofrecida sólo después de completar la tarea".

En la Motivación 3.0 la realización de la tarea proporciona una recompensa intrínseca. Si la tarea es contemplada como un juego, el éxito es seguro. Los tres elementos de la Motivación 3.0 son: Autonomía, Maestría y Propósito.

Autonomía: para sentirnos motivados necesitamos sentir autonomía respecto a la tarea que realizamos, cuándo lo hacemos, con qué técnica y con quien.

Maestría: El deseo a tener el dominio en la realización de una tarea. Hay quien cree que nuestra capacidad es fija y definida cuando nacemos, y otros que piensan que se puede mejorar, y que esa mejora requiere sacrificio y esfuerzo. Como decía Julius Erving (Dr. J) "Ser un profesional es hacer las cosas que te gusta hacer en los días en los que no te apetece".

Propósito: El disponer de un propósito mayor

Hay un par de vídeos muy interesantes sobre el contenido del libro en internet.




Se trata de un libro muy ameno, fácil de leer y muy, muy interesante.

Thursday, October 11, 2012

NoSQL Matters Barcelona Conference

On October 6th 2012 I attended to the NoSQL Matters Conference in Casa Convalescencia, Barcelona (the same venue where ALE2012 took place).
My interest in the NoSQL is twofold:

  1. As UOC Consultant for database subjects I must keep the pace with new trends
  2. At work we've been investigating different alternatives, and soon I'll start working with some NoSQL
Well, and I love learning new things! And there I was with some friends from UOC, Agile Barcelona and Sudoers Barcelona. The conference was organized in two tracks, with sessions on Products, Technical Aspects and Use Cases. I will try to share what I learnt on the sessions I attended.

NoSQL databases

NoSQL is an ill-defined term often interpreted as "Not Only SQL", that includes non-relational databases with focus on scalability and where transactionality is not that important.
There are different categories of NoSQL Databases:
  • Key-Value Stores (cache style, most of them based on Amazon's Dynamo paper) (examples: memcached, Redis)
  • Big Table style (based on Google's Bigtable paper) (examples: HBase, Cassandra)
  • Document database (like key-value, but the value is a document) (examples: MongoDB, Couchbase, Riak)
  • Graph databases (examples: Neo4j, OrientDB)

Products, Technology and Theory

Chris Anderson, co-founder of Couchbase gave, in my opinion, one of the most interesting presentations (rap included). He said Reality is growth. Startups are growth. He used the unit "1 instagram" to measure 75 MAU (Millions of Active Users). And he talked about The Simpsons game being out of appStore due to scalability issues and it was only 1/2 instagram. Scalability is important. And horizontal scalability (easily adding new servers) is the preferred one.

MongoDB expert, Christian Kvalheim, explained the capabilities of the product regarding automatic sharding and balancing. A shard is a horizontal partition.

Matt Heitzenroder from Basho talked about Eventual Consistency (Vogels' paper), the consistency model used in most of NoSQL implementations, far away from the ACID model. He talked about the CAP theorem , that states that from Consistency, Availability and Partition Tolerant, you have to pick two. He suggested PBS site to explore eventual consistency.

Luca Garulli from NuvolaBase presented Graph databases with the following definition: "A graph database is any storage system that provides index-free adjacency". His slides of the presentation Switching from the Relational model to the Graph model are available on slideshare.

In a lot of presentations we heard about languages (Python, Ruby, Java, Erlang, Scala, ...), clouds (Amazon WS), JSon and REST. With this new solutions you need to use all the tricks you know.

Use Cases

We reviewed the transition from relational to NoSQL databases with the experience of Trovit and Telefonica. Dani Solà and Marc Sturlese (Trovit) explained that their need was speeding up the update of Lucene text index to achieve near real-time indexing using Hadoop HDFSHiveHBase and ZooKeeper. Pablo Enfedaque's (Telefonica) story was that they were speeding up the access to their personalization database moving from Oracle to MongoDB. Oracle DBAs complained about resources: if they had the same amount of RAM...

Conclusions

It was useful for me Tobias Ivarsson's "NoSQL for dummies" presentation in Slideshare as an introduction. The organization of NoSQL matters conference was perfect and the contents very interesting. I hope I have the opportunity to practice with any NoSQL implementation.

NOTA (23/10/2012)
En el blog de informática de la UOC hemos publicado un artículo en castellano: El movimiento NoSQL (parte I) y parte II.