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.

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.

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.

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 HDFS, Hive, HBase 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.

In English, Amigo

It was sad for me when some friends from Agile-Barcelona community didn't attended to ALE2012 because it was in English. Next week we'll have Rachel Davies in our Coaching Dojo, and there wasn't the enthusiastic response it deserved, I guess because it's in English.

I am lucky to be working in a company where I need to speak English every day, and being exposed is the best way to learn and practice a language. So, organizing events in English in Agile-Barcelona will be the best way to contribute to our improvement.

And thinking about our weakness got me to wonder if contributing on books translations makes good or bad. For my friends who have not had the opportunity to start learning English, having the books translated is the only way to have access to them. For my friends who understand English, having the book translated is an opportunity to be lazy: they won't go out of their comfort zone.

I've decided to help the ones who can not get to the original source. I'm trying to contribute in the translation of two very interesting books: 

• Commitment is a graphic novel by Olav Maassen, Chris Matts and Chris Geary from which you can learn about Real Options. 
• In Who Is Agile, by Yves Hanoulle you can learn about some agilists around the world, agile communities, events, etc.

You can get in touch with me if you want to contribute to the Spahish or Catalan translations.

I've realized that I have to use English more often in this blog, that I won't blog only in English. I will write in English, Catalan or Spanish, whichever I find more appropriate or I feel like. Just because I can.  

ALE2012 energy continues in xALEc

We all agree on the energy we found in ALE2012  in Barcelona. All that crazy-wise people. We were discussing on how to continue with that spirit, waiting until ALE2013, and one of the ideas was xALEc: eXtreme ALE Club.

What's xALEc

Franck Depierre had an amazing idea after ALE2011: perform an on-line Open Space. We have all the tools out there for free, we only have to use them.

Since November 2011 we are meeting every Monday at 21:00 GMT+1. We use a shared document (The xALEc Dashboard) to suggest topics and take record of the meetings. Recently we've created a Facebook group named "xALEc" and a Facebook page. There you can find a description of xALEc written by Tonino Lucca.

I tend to pronounce xALEc as a word, making "x" sound as "sh", and pronouncing ALE similar to the french allez with the final "c". Others pronounce it like x-ALE-c (this time ALE pronounced as the beverage). You can use your own pronunciation.

Technology

We are using Google+ Hangouts, which is a video chat that works from the browser after installing a plug-in. We tend to use the camera and, despite it is not needed, is very useful. It helps also for non native English speakers. We also share documents in the same view and, sometimes, even the whole screen.

We use to publish the link to the hangout on Twitter, using the #xALEc hashtag.

We can have open hangouts (anybody can join) or we can close them to registered people. We try to adapt.

For some people, having to register to Google+ is an inconvenient. If we find better tools, we can use them. Google+ Hangout allows a maximum of 10 participants.

Rules

So far we've used a single Hangout, a single room in an Open Space, but we could use any number of rooms as needed, and we could use the Law of Two Feet (virtually).

Experience

We've had very interesting events about specific topics: DSDM Atern, with Matthew Caine;  Who is Agile, with Yves Hanoulle; Code Retreats, with Adi Bolboaca. But some unplanned hangouts were also great. Check the notes in the doc.

You can read the presentation of xALEc and the description of the first xALEc session that Franck posted in his blog.

Make it better

If there's something you think should be improved, you can reach me and make suggestions. Maybe you don't like Mondays, or the time, or maybe just the name or the technology. Make it better.

ALE2012: when it's over, it's over

The ALE 2012 event was held in my city, in Barcelona. I had the opportunity to attend an international event and I was excited and scared, but I'm completely satisfied.

I've met incredible people, full of energy, eager to share, and I've learnt a lot of things:

• You can deliver working software every hour. You may have horrible bugs, but you'll fix them. (side note: you need a very, very skilled team to achieve this).
• xALEc events every Monday had a purpose. It was like meeting old friends. Thanks Franck, Tony and Kjell.
• It was fun meeting in person Yves, Oana, Jurgen or Adi.
• You can connect Agile and music (thanks Marc).
• Kids don't care about language, but only about you.
• People can have contradicting opinions. Great discussions that make us grow.
• Some hippy and new age things fit particularly well in Agile. "People over..." opens a lot of doors. This is not intrinsically bad.
• I've learnt about responsibility.
• There's nothing more energizing than having a kid on stage.
• My English is just enough for these events. No reason to worry about it.
• I've learnt about facilitation techniques, core protocols, software excellence, retrospectives... 
• I've been able to share this experience with my boss. Lucky me.
• I'm GLAD I've started learning these things and I want to learn more.

I've learnt a lot of things but I wan't to keep the emotions more than the thoughts.

Thanks to all the agilists who brought their families. I didn't dare bringing my children, but was amazing having kids in the event.

I feel a little bit guilty having enjoyed the show, while my friends organizing the event were holding it on their shoulders. Thank you Saket, Jaume, Catia and Michael. And the volunteers. You are ALEsome.

I want another ALE now!

Learning with LEGO

Last week we gathered together in Barcelona members of the team that use to work from Brazil, Ukraine, so we thought it would be a good idea to do some team building activity, and it would be even better if we used the opportunity to show the values of Agile and Scrum to the members who never had used them before.

So, I prepared a game. Two teams of 4 and 5 people each, working collaboratively to build a city using LEGO, with a backlog containing the buildings the be built and a Product Owner available to refine requirements.

I used Alexey Krivitsky's paper, Scrum Simulation with LEGO bricks enhanced with ingredients from Agile42 and my friend Saket.

They organized in two teams, having at least one non Spanish speaking person in each group, and I explained the backlog, the parts of the city to be built or drawn.
Then they estimated the work to be done using swimlane sizing and story points, and did a release planning, planning three sprints ahead.

From then on, the worked against the clock. We did three sprints each of them with 3 minutes plan, 7 minutes work and 3 minutes review.

In the first review the team have not realized they were expected to show "a city", and were arguing the requirements until they understood they were working to build what the Product Owner needed, and they had him available to ask questions if needed. After some User Stories not accepted, finally they succeeded and did a great job.


We included an extra retrospective in the end, and all the process was about 2 hours.

I used the happiness door technique to get feedback from the experience and I cannot be more satisfied :-)

What I learned:

• In this game it's important to have a tight schedule and a visible timer.
• It's a good tool to explore the behavior of the team under stress.
• It's a very effective way to learn Scrum values and build a team.
• They decided to nominate an Scrum Master within one team, but in the retrospective they pointed out that it's role was not used at all.
• The language (almost all were non-native English speakers) was not an issue.
• We run to build, instead to plan and talk, and it's hard to correct this behavior.
• It's easier to build what you think, working on assumptions, than to ask. But far as effective.

Estic llegint: The White Tiger

De Aravind Adiga. 2008. Publicat per Atlantic Books. 321 pàgines

Una novel·la ambientada a l'India que explica, en primera persona, com un ciutadà amb poques expectatives es converteix en un pròsper emprenedor.
Mostra una India desequilibrada, cruel i injusta. Una gran lectura.

He anat prenent notes durant la lectura.

Diu que la India està plena d'homes "mig cuits" per què no han pogut finalitzar l'escolarització i que justament aquests són la bona base per l'empreneduria. A la pàgina 10 diu:

Fully formed fellows, after twelve years of school and three years of university. Wear nice suits,join companies, and take orders from other men for the rest of their lives.
Entrepreneurs are made from half-baked clay.

A la pàgina 110 apareix un indianisme que ja havia comentat en parlar de Shibboleth en aquest blog. 

I did the needful in a few precise words.

I a la pàgina 292 fa un elogi del yoga pels emprenadors:

[...] an hour of deep breathing, yoga, and meditation in the morning constitutes the perfect start to the entrepreneur's day. How would I handle the stresses of this fucking business without yoga, I have no idea. Make yoga a must in all Chinese schools – that's my suggestion.

Definition of Done and Acceptance Criteria

It is always useful to share a common vocabulary in a team, and some terms lead to confusion, as it happens with Definition of Done and Acceptance Criteria.

In an agile project the work to be performed is described in User Stories, for example:

“As a premium user I want to check the special offers addressed to me so that I can purchase them”

Every User Story can have a set of “conditions of satisfaction”, things that must be satisfied in order to consider the User Story finished:

• The premium user can list the special offers addressed directly to him
• Each offer has a price, and it’s shown in the user’s currency
• If the list is empty the user is notified about it and he can see the conditions
• Every item has link so it can be purchased

These conditions are the Acceptance Criteria and are set per User Story, and are meant to remove ambiguity. In Scrum terminology they are the Product Owner's expectations.

The Definition of Done (DoD)  is a term used in Scrum but can also used in other methodologies. DoD is a set of conditions that every developer must satisfy in order to say he has completely finished with a User Story, so that it’s potentially shippable. It's a statement on quality, and it’s meant to avoid “Technical debt”. You cannot say “it’s done, just some documentation pending”.

Every team defines their own requirements for Done. The obvious one is “all Acceptance Criteria pass” but other teams must choose some of the following:

• All code has been reviewed (if not pair-programmed)
• Code has been deployed using Continuous Integration
• Documentation updated
• Systems Administrators notified about changes
• Training manual updated
• No pending bugs
• Performance tests passed
• All code under version control
• All code needs to have automatic acceptance test
• Business Analyst accepted
• Unit Tests pass
• Code coverage over 70%

If a User Story is not done, it must pass to the following sprint.

In Scrum you can have a Definition of Done for a User Story, for a Release and for a Sprint Planning.

Definition of Done is a team commitment on quality. Acceptance Criteria sets the minimum validations to check on a User Story completion.

There are some practices to include Acceptance Criteria in the development process, like BDD (Behavioural Driven Developmen) and ATDD (Acceptance Test Driven Development), but that’ll be another day.

El secreto del éxito de los freelance

No soy un artista, ni un freelance (autónomo) pero soy un fan de Neil Gaiman y cuando vi en el blog de Olaf Lewitz que había dado un discurso a unos graduados en arte, me puse a mirar el vídeo.
Para mi ha resultado tan inspirador como el discurso de Jobs o de Guardiola que ya comenté en este blog.

Me quedo con el secreto de los freelance:

La gente consigue un trabajo porque... consigue un trabajo. Pero siguen trabajando porque:

• Su trabajo es bueno
• Es fácil trabajar con ellos
• Entregan el trabajo a tiempo

Y lo mejor de todo es que no necesitas las tres. ¡Con sólo dos ya está bien!

Tolerarán si eres desagradable pero haces un buen trabajo y entregas a tiempo.

Te perdonarán que entregues tarde si tu trabajo es bueno y les gustas.

Y no tienes que ser muy bueno si entregas a tiempo y es agradable trabajar contigo.

Sobretodo, disfrutar y cometer errores interesantes.

Make Good Art. 

Agile Estimating and Planning

De Mike Cohn. 2005. Publicado por Prentice Hall. 368 páginas

Aunque ya tiene unos años, sigue siendo la referencia en la estimación y planificación de proyectos ágiles.
Es muy probable que la mayoría del material que presenta ya te haya llegado de alguna manera u otra, pero resulta muy útil acudir a la fuente.

La planificación de los proyectos tiene los siguientes beneficios:

• Reduce el riesgo
• Reduce incerteza
• Ayuda a la toma de decisiones
• Establece confianza
• Transmite información

Todos los interesados en el proyecto han de saber que las estimaciones se van haciendo más precisas a medida que avanza el proyecto, y eso se puede expresar gráficamente con el cono de incertidumbre. Las estimaciones, por tanto, deberían expresar esta incerteza, por ejemplo indicándolas como un rango. Por otro lado, una estimación no es lo mismo que un compromiso.

En los proyectos ágiles se estiman funcionalidades y no actividades, y se recomienda estimar en tamaño y no en duración. La medida se puede hacer en puntos de historia o en días ideales.

Para ayudar a planificar, puede resultar interesante medir la velocidad del equipo, que se entiende como el número de puntos de historia que un equipo puede resolver durante una iteración.

La planificación ágil tiene las siguientes características:

• Se centra en la planificación, no en el plan
• Estimula el cambio
• Resulta en planes fáciles de cambiar
• Se extiende durante todo el proyecto

El autor recorre otros aspectos muy interesantes de la estimación y de la planificación, como las épicas y los temas, las estimaciones en equipo, la escala de estimación, el planning poker, el modelo de Kano de satisfacción del cliente, la planificación a diferentes niveles, las técnicas de DSDM, los buffers de funcionalidades y de calendario, y algunas herramientas visuales de planificación.

El autor le da valor a la planificación, que ya de por sí es un tema espinoso, pero si en el contexto del proyecto/empresa se trata de una necesidad, esta puede ser una lectura interesante.

La Técnica del Pomodoro

Cuando tenemos que trabajar en algo que requiere mucha concentración muchas veces sucede que tenemos interrupciones. A veces son distracciones del exterior (una llamada, alguien que nos habla) pero otras veces la distracción viene de nuestro interior (soñamos despiertos, nos acordamos de otro problema, consultamos el correo de forma compulsiva). Culpamos las distracciones externas y nos aislamos en una sala, para conseguir la misma falta de productividad: nuestras distracciones internas matan nuestro trabajo.

La Técnica del Pomodoro es un método de gestión del tiempo diseñado para superar las distracciones internas y permitir que nos enfoquemos en la tarea a desarrollar.

El método es muy sencillo. El tiempo de trabajo se divide en intervalos de 25 minutos (llamados timeboxes o “pomodoros”, la palabra italiana para “tomate”). Después de cada pomodoro te tomas un descanso de 5 minutos. Después de cuatro pomodoros te tomas un descanso más largo de 15 a 30 minutos.

Comienzas el día escribiendo en un papel la lista de tareas a realizar. Para cada pomodoro que dedicas a la tarea, escribes una X en la lista. Si te das cuenta que has tenido una interrupción del interior, marcas con un apóstrofe ('). Si tienes una interrupción del exterior tienes que parar el pomodoro y volver a empezar. El timebox es indivisible.

El relativo corto tiempo dedicado a una tarea te permite mantener el foco. Los descansos cortos te permiten mantener el flujo. Mientras estás en el timebox de descanso, deberías hacer algo que no tuviese nada que ver con la tarea, y si se trata de una actividad que requiera caminar o moverse, mejor.

Hay equipos que trabajan en pomodoros sincronizados. Hay entornos en los que si alguien alerta que está en un pomodoro, nadie le interrumpirá.

Hay más detalles de la técnica (como estimar las tareas y aprender de las estimaciones) y explicaciones del porqué de la duración de 25 minutos, la preferencia por un temporizador de verdad y el valor del sonido del tic-tic. Puedes encontrar el libro de Francesco Cirillo (que creó la técnica en los 90) en la página web de la Técnica del Pomodoro.

Switch

How to change things when change is hard
De Chip Heath y Dan Heath. 2010. Publicado por Crown Business. 305 páginas

En nuestro cerebro funcionan dos sistemas continuamente. El primero es el lado emocional, que es la parte instintiva, que siente el dolor y busca el placer. El segundo es el lado racional, el que toma decisiones, analiza y se preocupa por el futuro.

Una buena analogía para representar esta dualidad es un elefante para el lado emocional y su jinete para el lado racional. El jinete sabe donde quiere ir y trata de que el elefante le obedezca usando las riendas. Pero si el elefante no quiere ir, la situación se complica.

El libro presenta una serie de técnicas para conseguir cambios en el comportamiento de personas y de organizaciones. Cambios como que el hijo ayude en las tareas domésticas, ir al gimnasio con regularidad, que los estudiantes lleguen a clase a la hora o que los trabajadores sigan las normas de seguridad. Para conseguir esos cambios no es suficiente con entender sus beneficios y hacer una formación, eso solo instruye a nuestro lado racional. Los autores proponen una serie de técnicas para dirigir al jinete, para motivar al elefante y para dar forma al camino.

Una de las técnicas para dirigir al jinete es buscar los puntos brillantes. Si estamos tratando de arreglar algo que no funciona, buscar qué es lo que sí funciona o ha funcionado para entender el porqué. Está muy relacionado con la terapia centrada en soluciones: ¿cuál sería el primer signo que verías si un día te despiertas y tu problema se ha resuelto?

Una de las técnicas para motivar al elefante es encoger el cambio, buscar un objetivo menos ambicioso para tener un éxito más cercano.

Y hay toda una serie de reflexiones que van apareciendo a lo largo del libro:

Los hermanos Heath dicen que hay personas con una mentalidad fija y personas con una mentalidad de crecimiento. Las personas con una mentalidad fija creen que su conjunto de habilidades es estático, que pueden mejorar un poco, pero reflejan cómo eres en esencia. Con esta mentalidad se evitan los desafíos (por miedo a que las habilidades no sean suficientes) y no se acepta la crítica.
Las personas con mentalidad de crecimiento piensan que las habilidades son como músculos, que se pueden construir con el ejercicio. Con esta mentalidad eres capaz de aceptar desafíos y no te importa el fracaso, porque si fallas simplemente has de entrenar más. Podemos dar a nuestros hijos una mentalidad de crecimiento si nuestros comentarios en lugar de ser "¡qué listo que eres!" o "¡qué bien juegas a fútbol!" son "¡estoy orgulloso de cómo te has esforzado!" o "¡cómo se nota que has hecho caso al entrenador!"

Lo que parece resistencia muchas veces es falta de claridad. A veces no se sigue el comportamiento adecuado porque no se sabe cómo hacerlo o porque hay demasiadas opciones.

El autocontrol es un recurso limitado, si has gastado tu autocontrol para evitar comer chocolate puede que no lo tengas para no tener un discusión.

Las personas tendemos a ignorar la situación que hace que otros se comporten de una forma determinada. Esta tendencia se llama el error fundamental de atribución. Pensamos que se comportan por "como son" en lugar de por "la situación en la que están".

En la web de los autores, previo registro gratuito, pueden descargarse una serie de PDFs con un resumen de las técnicas del libro. También tienen disponible el primer capítulo.

Libro imprescindible.

Diseño ágil con TDD

De Carlos Blé Jurado (et al.) 2010.  Publicado por Lulu. 309 páginas

No tenía ni idea de que existiese algún libro en castellano sobre TDD (Test Driven Development, desarrollo dirigido por tests) y fue una sorpresa encontrar este trabajo.
Un libro bajo la licencia de Creative Commons (gratuito), que se puede descargar directamente de la web Dirigido por Tests y también puedes comprarlo en papel desde la pàgina de Lulu.

Yo he tenido la suerte de leerlo en papel, en una edición firmada que tenían en Omatech.

Los autores realizan una introducción magistral a los tipos de tests, a los frameworks, a los dobles y a todo lo que necesitas para realizar un desarrollo dirigido por tests, con un pequeños repaso de Orientación a Objetos y los principios SOLID. Gracias a la lectura a mi me ha quedado clara la diferencia entre Dummies, Fakes, Stubs y Mocks.

Además la lectura se acompaña con una buena colección de ejemplos prácticos escritos en Java, C# y Python. La fuente que se utiliza para mostrar el código resulta un poco cutre, pero se puede leer.

El libro de Kent Beck es una excelente introducción TDD pero no logra suficiente profundidad. No sería justo decir que Diseño ágil con TDD es una buena alternativa si no sabes inglés, es un buen libro de TDD por sí mismo, con contenido práctico de calidad.

Aplicación de metodologías ágiles en un departamento de Sistemas

A raíz de un mensaje que apareció en el grupo de Agile Spain se propuso hacer una serie de encuentros locales para hablar de la aplicación de metodologías ágiles en los departamentos de sistemas. En Barcelona tuvimos ayer (20 de marzo de 2012) un encuentro organizado conjuntamente entre Sudoers-Barcelona y Agile Barcelona.

Contenido de la reunión

Asistimos nueve personas, con una participación similar de los dos grupos y comenzamos explicando Scrum y Kanban para compartir un mismo lenguaje. A continuación dos compañeros explicaron sus experiencias a la hora de aplicar Scrum y Scrumban en sus departamentos y surgieron ideas muy interesantes.

• Se habló de utilizar GTD (Getting Things Done) y cada día por la mañana resolver primero las tareas del Inbox que suponen dos minutos, y no tener en cuenta peticiones llegadas después de las 12AM. En este sentido, se comentó la existencia del libro llamado Time Management for Sysadmins de Limoncelli, que parece que es un clásico entre Sysadmins.
• Se habló de usar una bandera o un escudo, que marque la persona del equipo que ese día hace soporte a los usuarios. De esa manera se deja más tiempo al resto del equipo.
• Se comentó la importancia de medir, para poder tener una idea de lo que se puede resolver durante un periodo de tiempo, e ir adquiriendo experiencia en este sentido.
• Se propuso la idea de utilizar la técnica del Pomodoro para conseguir mayor productividad en el equipo.
• Se discutió el problema de la priorización y de la importancia de tener un Product Owner.
• Se habló de la documentación y del uso de Wikis. Además se propuso validar la documentación de tareas, por ejemplo haciendo que otro compañero la use.

Surgieron algunos temas que no hubo tiempo de tratar en profundidad como por ejemplo la convivencia de metodologías ágiles con ITIL, la dependencia entre tareas, cómo conseguir mejorar el truck factor o la comunicación entre desarrolladores y administradores (DevOps). Estos temas, y otros, pueden tratarse en futuras reuniones.

Conclusiones

Nos dimos cuenta que la realidad del mundo de sistemas no es muy diferente de la del mundo del desarrollo.

Convivimos con el mismo tipo de problemas:

• Nos gustaría tener tiempo para enfocarnos a resolver el trabajo.
• Necesitamos ayuda por parte del negocio para determinar la priorización de tareas.
• Y los problemas derivados de las interacciones y la comunicación, entre el equipo y con los usuarios y clientes.

Las metodologías ágiles pueden ayudar a detectar los problemas, pero no dan directamente la solución.

Ponen el foco en las personas y sus interacciones, y hacen que los miembros del equipo no puedan esconderse detrás de sus pantallas. 

Introducir transparencia en un equipo pude generar tensiones que hay que gestionar.

He mordido la manzana

Llevo unos diez años utilizando GNU/Linux en el escritorio, últimamente Ubuntu. De cara al desarrollo de aplicaciones es perfecto: lo tiene todo y gratis. Y para el resto, no he echado nada de menos: editar textos, grabar DVDs, editar imagenes, escuchar música, ... Únicamente necesitaba Microsoft Windows cuando tenia que arrancar iTunes o el software de Blackberry.

Nunca he tenido un Mac, aunque siempre los he considerado muy sexys. Hasta no hace mucho era el tipo de máquina que usaban los diseñadores, pero cada vez veo más desarrolladores usándolas y elogiándolas. Y he pensado que estaría bien probar.

Me da miedo caer en la adicción y perder la objetividad, y caer en la trampa del ecosistema despiadado de Apple que te crea dependencias y te obliga a pagar por ellas. Seguro que seré capaz de estar alerta.

Llevo mis primeros minutos con esta máquina, sin haber traspasado toda mi vida Linux a este nuevo entorno. Me está costando cada paso, como me pasó en mis primeros pasos con Linux. No he sido capaz de editar un documento TXT definiendo la codificación UTF-8, y la única herramienta que he encontrado, TextMate, es de pago.

Será un proceso y será muy beneficioso. Es imprescindible no dejar de aprender y de probar. Y será divertido.

Por cierto, justo después de la compra he leído el post de Carlos Blé,  ¿De verdad necesitas estar a la última?, con el cuál estoy totalmente de acuerdo. Hay que ser consciente de porqué tomamos nuestras decisiones.

Una nova aventura

El 15 de març de 2010 vaig començar a Omatech, tot i que cada dia de feina el passava a Thomson Reuters, l'antiga Prous Science on ja havia treballat quan era a Oracle. Demà, dos anys després, passaré a formar part de Thomson Reuters amb un nou repte.

La meva estada a Omatech ha estat un somni i una sort. El fet que l'Agustí, el Miki i l'Otto siguin amics ajuda una mica, però la manera que tenen d'enfocar els negocis, la gent i la vida, és tota una lliçó. I es reflecteix en l'ambient que he respira a l'oficina. Quin equip, quin entusiasme, quin nivell! I sempre amb ganes de millorar, que és el més important. Els d'Omatech sabeu que aquí teniu un amic.

Demà comença una nova aventura. Bé, potser no tan nova, perquè d'entrada seguiré fent el mateix, però amb l'esperança de participar en l'aplicació de metodologies àgils en un entorn molt complex.

Bona sort

Leancamp Barcelona. Wow!

I've just returned from the Leancamp held in Barcelona and I needed to write some lines. When I registered for this event I wasn't sure what was that about, but the idea of Lean and that the guys from Agile Barcelona where eager to attend was enough for me. Moreover, I was convincing other friends to attend (and I succeeded on that, I have to say).

I thought I needed to prepare myself for the event and I decided to read The Lean Startup (the book that inspired the movement). What a great book full of ideas! Once read, I knew a little more what I was going to find, and finding among the speakers Angel Medinilla and Alex Barrera I was sure It was going to be amazing. And it has been so.

Opening session. Picture by @leancamp

Leancamp is an unconference, and it means something like an Open Space: there are a lot of parallel tracks and you can attend to the ones you like most. But the most important part is the Law Of Two Feet: if you feel you cannot bring anything to a session or the session cannot bring anything to you, you are responsible of using your two feet and go somewhere else.

Morning talks. Picture by @nickycast

With such a bunch of interesting people it has been very difficult to choose among the sessions but I'll try to share my experience.

Introducing the Lean Startup
The first session I attended was given by Rob Fitzpatrick introducing the Lean Startup ideas using a concrete start-up in London which links big companies with street artists. Low funding, invest on User Experience, use money when needed, question everything, build metrics on your own questions.
It's been an exciting talk, but 25 minutes has been too short for his message.

Human Side of Lean
Angel Medinilla knows how to handle time, even though his hangover. He has explained the history of NUMMI, a General Motors plant that was recovered when run by Toyota people. Then he went on to a Japanese poem about three warlords and a bird that didn't sing. The furious Nobunaga, the  persuader Hideyoshi and quiet Tokugawa.

"If a bird doesn't sing, kill it", said Nobunaga.
"If a bird doesn't sing, make it sing", said Hideyoshi.
"If a bird doesn't sing, wait for it to", said Tokugawa.

Angel says that lean is more like Tokugawa (and, by the way, Tokugawa won).
Afterwards Angel defined "corporate culture": the way we do things around here. And he said that for it to work people needs two things: a noble cause, a purpose and shared values.
Great Talk!

Bumble Bee-ing
The third session I have been a Bumble Bee in the sense of Open Space Technology: I've used my two feet and I've gone to different groups: User Experience, Aikido and starting a start-up. It's been interesting merging the concepts behind Aikido and Lean. I've been translating some Aikido concepts to Judo, my own background, and everything works the same way.

Aikido and Lean. Picture by @CarlosTheSailor

Metrics
Fourth session has been  with a guy with a hat named Andreas Klinger, who is CWTFO of LOOKK. He's shared with us the lessons learned with metrics, measuring users accessing his site. He said to focus on Retention, because the good measure is User Happiness, and it's the best way to measure it. He explained a the concept of cohorts that's used in Lean Startup (a group of people based on some attribute) and in the end he went to AARRR: the sound of looking at metrics. No, but he explains it better with his slides on slideshare.
He didn't managed time, but the talk was very, very good.

Scrum + Kanban
Again with Angel Medinilla we started to talk about Kanban. First of all he played with us and we performed the game of writing names (good exercise to understand "one project at a time"). He went to the 5 principles of Lean:
1.Value for your customer  (anything else is Waste). If you don't want more of this, it is waste.
2. Stream
3. Pull
4. Flow
5. Kaizen

Then to the principles of Kanban:
1. Value Stream
2. Visualize Work
3. Limit WIP
4. Flow
5. Improve

This time I took profit of the talk because of my previous knowledge on the subject, but it was hard to fit all that stuff in 25 minutes (game included).

Visual Thinking

Esther Gons (@wilg) was running this talk that I was expecting so much, but it ended up just explaining Andreas Klinger LOOKK story. Interesting, but not that much. I'll read The Back of the Napkin, which is on my reading backlog anyway. 

Learning, Knowledge Management and Innovation

Pic by @CarlosTheSailor

Again with Angel Medinilla, but this time on a more practical session: tools and techniques for sharing and creating knowledge. And just Wikis don't work, he says. The most important thing, we know it, is the interaction between individuals.

Retrospectives. Talking about Kaizen (continuous improvement) and Haisen (continuous reflection), and the importance of having a plan after a retro.

Pairing. Not only pair programming, but anything. He suggested Pair PowerPointing. Share mistakes and learn from failure.

Lab time. Invest a fraction of the team time on labs, to learn and improve. Angel suggested his blog just for Lab suggestions (I'll try to find the proper link).

Brainstorming. And first of all, learn about how to do it.

And the audience suggested other interesting things.
Slack.
Go analog!. And the link http://manualthinking.com/
Lightning talks. And Pecha Kucha presentations (20 seconds for 20 slides).
Demos.

A lot of interesting stuff!

And That's all
This is the first of the three great Lean-Agile events going to be held in Barcelona. ALE and Scrum Gathering are coming to town on August and October. I'll be informing.

Other Links and Reviews

• Collection of links about the Leancamp Barcelona by Abraão Lourenço (@alourenco) 
• Notes about the Leancamp talks Oriol Pascual (@onsustain) attended. Very different experience from mine. Worth reading.
• LeanCamp pictures by Maye MacSwiney
• Video of Aikido session with Medinilla and Barrera.

The Lean Startup

How Today's Enterpreneurs Use Continuous Innovation to Create Radically Successful Businesses
De Eric Ries. 2011. Publicado por Crown Business. 336 páginas

Eric Ries define una startup como "una institución humana diseñada para crear un nuevo producto o servicio bajo condiciones de extrema incertidumbre", sin entrar en detalles respecto al tamaño o al sector. Entiende que hay emprendedores dentro de compañías ya establecidas (intrapreneurs), e incluso que puede haber en el sector público.

El Lean Startup es una aproximación para desarrollar startups exitosas, utilizando de forma más creativa el talento y el capital, inspirados por los principios del Lean Manufacturing.

No conviene perder demasiado tiempo en estudios de mercado, sino poner en marcha el producto lo más rápidamente posible (un MVP, Producto Mínimo Viable). Propone crear experimentos, que ya son el producto, de manera que puedas obtener información de su aceptación cuanto antes. El objetivo del experimento es aprender y validar el aprendizaje.

Una vez tienes tu proyecto en marcha evaluar si vas por el buen camino: perseverar o pivotar. Y pivotar no es abandonar, sino hacer un cambio aprovechando lo aprendido hasta el momento. Parece ser que la idea de pivotar se ha vuelto tan conocida que hasta en el New Yorker le dedicaron la viñeta.

El salto de fe, la hipótesis de valor y la hipótesis de crecimiento, el ciclo Construir-Medir-Aprender, las vanity metrics, los split-tests, los tipos de pivot, los mototres de crecimiento, la historia de los sobres,... Este libro contiene tantas perlas y está escrito de una forma tan brillantemente estructurada que lo convierte en una lectura muy recomendable.

Este mismo sábado, en La Salle deBarcelona, habrá un encuentro relacionado con Lean Startup, el Leancamp, con mucha gente interesante y muchas ganas de aprender. Nos vemos allí.

Is The Lean Startup just Mud-Throwing Practice?

I'm reading The Lean Startup book (you should read it as well) and the author suggests that you should release your web as soon as possible despite it's not complete. This way maybe you engage some early adopters. After releasing something you can watch if your assumptions were right and adapt accordingly.

When reading this it came to my mind an old post by Jakob Nielsen (a usability guru) dated from 2000: The Mud-Throwing Theory of Usability. Moreover, I remember watching him in London explaining it theatrically. His theory suggested that some people were building sites like throwing mud at the wall and see if it sticks.

He, in 2000, advocated for some usability practices, just a minimum (paper-prototyping and testing with few users), before releasing anything. Does it contradict The Lean Startup ideas? Not at all, I would say.

In 2000 usability and user experience weren't as known as they are now and Jakob Nielsen was just making them widespread (and selling his services). Currently developers and designers have assumed the importance of users. When Eric Ries (the author of The Lean Startup) suggests to release as soon as possible, he talks about the MVP, Minimum Viable Product, and without usability tests it could not be "viable".

How much to invest in those tests would depend who you ask. Keep it Lean.

Las cinco disfunciones de un equipo

De Patrick Lencioni. 2002. Publicado por Empresa Activa (Urano). 215 páginas

El autor presenta sus ideas de cómo transformar un equipo que no funciona en forma de fábula: una empresa que no funciona contrata a una directora general para conseguir que sus ejecutivos funcionen como equipo. A través de esta historia el autor explica lo que él considera que son los cinco problemas que tienen los equipos.

La novelita (175 páginas del libro), aunque al final tiene diálogos imposibles, tiene buen ritmo y es entretenida. Justo después el autor ha añadido la explicación de las cinco disfunciones y sugerencias para corregirlas.

Las cinco disfunciones de un equipo (según el autor) son:
1. Ausencia de confianza. Los miembros del equipo deberían conocerse bien y confiar unos en otros.
2. Temor al conflicto. Los conflictos son productivos y no hay que huir de ellos.
3. Falta de compromiso. Una vez se toma una decisión, todos la aceptan como si fuese suya.
4. Falta de responsabilidad. Todos los miembros del equipo deben pedir cuentas a los que no funcionan.
5. Falta de atención a los resultados. Hay que dejar claros y perseguir los resultados colectivos.

Qué quieres que te diga. Después de haber leído el Management 3.0 todo esto es muy Management 1.0. Habla de recompensar al equipo económicamente por los resultados, de fijar plazos de entrega para que el equipo funcione o de presionar al equipo. Y continuamente habla del "líder".

Nada empowering, ni auto-organización, ni nada por el estilo. Estamos de acuerdo en la diferencia entre "grupos de personas" y "equipos", y también acepto las dos primeras disfunciones, pero poco más.

Además, puede que las ediciones de "Empresa Activa", todas iguales, te predispongan en contra de un libro, y puede que sea mi caso. Si has leído alguno que ya no te ha gustado, empiezas condicionado.

Pragmatic Programmer

from journeyman to master
De Andrew Hunt y David Thomas. 1999. Publicado por Addison-Wesley Professional. 352 páginas

Me habían recomendado mucho este libro y justamente era la propuesta del Club de Lectura de Agile Barcelona, así que lo inicié con muchas ganas. No en vano es una de las primeras influencias del movimiento de Software Craftmanship.

A lo largo de 7 capítulos, los autores presentan 70 consejos (tips)  para el desarrollo de software.

Los dos primeros capítulos son fantásticos, propios de esos libros de informática que sabes que no caducan. Pero a partir del tercer capítulo la sensación ha sido "lo he leído diez años tarde".
Sin desmerecer el contenido, que es estupendo, gran parte de las ideas que se presentan ya las tenemos más que asumidas: pruebas unitarias, control de versiones, uso de texto plano, etc.

El consejo que más me ha gustado ha sido el 4, "No vivir con ventanas rotas": reparar los pequeños fallos que van quedando en el código para evitar que otros desarrolladores piensen "puedo hacer esta chapuza, ya que he visto esa otra por ahí".

Los cuentos de la sopa de piedras (ser un catalizador del cambio) y de hervir ranas (nadie se da cuenta de los cambios si vienen poco a poco), también son inspiradores, así como el consejo de good enough software (saber cuándo parar), como un pintor que sabe cuándo dejar de poner pintura.

Los dos primeros capítulos también incluyen como consejo 11 el clásico DRY, Don't repeat yourself, una definición de ortogonalidad, y el consejo de utilizar balas trazadoras (tracing bullets) para tener feedback rápido del cliente. Comentándolo con @jaumejornet, @eidrien y @albertcumplido en el club de lectura, no todos entendimos lo mismo por "balas trazadoras". Los autores presentan la idea en contraposición con la idea de "prototipo": un desarrollo exploratorio construido para posteriormente ser desechado. En ese caso yo entiendo una bala trazadora como el resultado de una iteración en metodologías ágiles. Sin más misterios.

El capítulo tres hace una defensa del uso de ficheros de texto plano y de la línea de comandos. Me recordó mucho la lectura de En el principio fue la línea de comandos (también en inglés) de Neal Stephenson, aunque en otro contexto.

En este capítulo también habla de control de versiones, dominar un editor de texto y "rubber ducking": cuando estás tratando de resolver un bug y estás atascado, comentar tus progresos en voz alta (a un patito de goma). A veces, sólo con tratar de explicarlo te das cuenta de algo que no habías tenido en cuenta. En una empresa en la que trabajé a esto le llamábamos "efecto Furby".

En los capítulos 4, 5 y 6 habla de aserciones, diseño por contrato, la Ley de Demeter, diseñar siempre para concurrencia, diseñar para las pruebas y programar por coincidencia. Esto último es el clásico "si funciona, no lo toques".
En estos capítulos también le dedica una sección a hablar del coste de los algoritmos, con aquello del O(n log(n)), aunque me ha parecido un poco fuera de lugar.

Cuando habla de refactoring propone utilizar la metáfora de la jardinería en lugar de la metáfora de la arquitectura a la hora de hablar del desarrollo de software. Muy interesante.

En el capítulo 7 se ríe de la expresión "recogida de requerimientos" y sugiere que se trata más de "excavar a por los requerimientos". También sugiere separar los requerimientos de las políticas de negocio, porque estas últimas pueden cambiar. Y en el consejo 57 dice que algunas cosas es mejor hacerlas que describirlas (por ejemplo "describe cómo hacerte el nudo de los zapatos").

En el capítulo 8 trata de resumir todo lo descrito en los capítulos anteriores poniéndolo en contexto.

He encontrado que es un libro muy interesante y recomendable, pero tenía las expectativas demasiado altas.