No traiga problemas, traiga soluciones

Supongo que, al igual que yo, habéis leído y escuchado muchas veces la frase: No traiga problemas, traiga soluciones. Teóricamente pensada para empoderar (palabra tan moda últimamente) a la gente y, especialmente, a los trabajadores. Te implicas, te manchas y buscas una solución a un problema que hayas detectado.

Pero creo que esta frase es peligrosa y puede venir acompañada de un problema y efecto colateral peor.

No todos los problemas son fáciles de solucionar. No todas las personas tienen en sus manos la capacidad y conocimiento de encontrar soluciones a un problema. Y, obviamente, no todas las personas tienen la capacidad de escuchar a que otros les traigan problemas y sus soluciones. Esto puede derivar a una situación de ver un problema y, como no tengo la solución, no lo aviso y comunico. Si no puedo traer problemas, sino que tengo que traer soluciones, pero ni tengo solución ni tengo las vías para traerla, pues mejor me quedo callado en mi sitio. Y esto puede terminar siendo un problema mayor de problemas detectados que no son comunicados ni solucionados.

Por eso, yo creo que es mejor fomentar la cultura de Traiga todos los problemas que encuentre, ya buscaremos las soluciones juntos. Obviamente si quien detecta el problema, tiene la solución, pues o que la aplique o la comente. Pero si no es así, siempre es mejor comunicar los problemas detectados y luego ya buscar la solución correspondiente. Y así es como yo he intentado siempre trabajar.

Mob programming

Hace unos días leí un artículo que hablaba sobre Mob Programming, lo que atrajo mi atención ya que era la primera vez que leía algo sobre algo llamado así. ¿Y qué es eso? ¿Una nueva metodología? ¿Una nueva técnica?

Mob Programming es el hecho de que un grupo de programadores se sientan juntos, preferentemente en una habitación, con un único ordenador y un trozo de código. Así todo el grupo junto puede discutir, diseñar, programar un trozo de código del proyecto. Y, por lo tanto, todo el equipo está concentrado en solucionar el mismo problema. Sería algo así como el pair programming pero con más de dos personas involucradas.

A simple vista podría parecer que es una de las formas de trabajo más ineficientes. Todo el equipo trabajando sólo en una tarea, perdiendo su tiempo en sólo una cosa cuando podría estar trabajando en tareas diferentes (como de costumbre). Pero, por el contrario, es una forma muy útil y eficiente de trabajo. Naturalmente, usada con moderación.

En mi días trabajando en Papa Pear, solíamos usar esta técnica, aunque nosotros lo llamábamos PapaDojo (Papa de Papa Pear y Dojo por los Coding Dojos). Solíamos hacerlo una vez por semana, todo el equipo de desarrolladores en una sala de reuniones, un único ordenador y un único problema a discutir. Unos cuantos días antes se escogía un tema, una persona lo preparaba y avisaba al resto del equipo, así la gente interesada podía decidir si asistir o no y prepararse el tema.

¿Qué tenía esto de interesante? Nuestra idea era, una vez por semana, todo el equipo compartía código y tecnologías que se usaban. Con varios objetivos: conseguir conocimiento compartido de las tareas que se estaban implementando, ser capaces de conocer otras tecnologías o lenguajes con los que no tratabas en tu día a día (IoC, C++, Action Script, Unit Testing,...), afrontar todos juntos un refactor de código importante,... Y, así, a largo plazo conseguir beneficios como: todo el equipo tener conocimiento (en profundidad o superficial) de todo el proyecto (no sólo de la parte en la que cada uno estaba trabajando), todas las tecnologías y lenguajes usados en el proyecto (facilitando el cross-development de nuevas implementaciones), afrontar un refactor/mejora importante de código que podría ser grande para sólo una persona,... y, naturalmente, team building.

No pienses que Mob Programming es algo ineficiente ya que, a largo plazo, es una técnica que ofrece grandes beneficios tanto para el equipo como para el proyecto.

A few days ago I read this article regarding Mob Programming (sorry, it's in spanish) which get my interest because it was the first time I read about a thing with that name. What was that about? A new methodology? a new technique?

Mob Programming is the fact that a group of programmers sit all together, preferably in a room, with only one computer, with only one piece of code. All the group can discuss, can design, can program a piece of code of the project. Therefore, everybody is completely focused in solving the same problem. Something like pair programming but with more than two people involved.

One first impression might be that it is one of the most inefficient ways of work. All the team working in the same task, wasting their times in only one thing while they could be working in different tasks (as usual). But, on the contrary, it's a very useful and efficient (in long term) way of work. Used with moderation, of course.

In my days in Papa Pear we used to use this thing but we called it PapaDojo (Papa for Papa Pear, and Dojo because of the Coding Dojos). We used to do it once a week, the whole developers team in a meeting room, one computer and only one problem to discuss. A few days in advance we picked one topic, one person prepared it, notify to the rest of the team so the people interested could decide to attend or not and prepare the topic.

And, why was this very interesting? Our idea was to, once a week, all the team shared the code and the technologies to use. The aims were multiple: reach share knowledge of the tasks being implemented, being able to know other technologies or languages you don't deal with in your daily basis (IoC, C++, Action Script, Unit Testing, ...), face all together an important refactor to do, ... And in a long term the benefits are multiple, as well: the team may have a knowledge (in deep or superficial) of all the project (not only the parts each one is working on), all the technologies and languages used in the project (easing the cross-development of features), face a refactor/improvement of code that for only one person can be huge,... and, of course, team building.

Don't think Mob Programming is inefficient, in long term will provide you lot of benefits for the team and the project.

Product Owners vs. Product Executors

Van a ser casi dos años desde que empecé a trabajar en King y en todo este tiempo he aprendido muchas cosas. Una de ellas ha sido poder experimentar otra forma de trabajar, de organizarse y de gestionar equipos. Parte, probablemente, facilitado por usar una metodología de trabajo agile, parte promovido por la filosofía de la empresa.

Hasta el momento, en todas las empresas que había trabajado, tenían una organización y métodos de trabajo clásicos. Con estructuras piramidales, donde hay jefes y donde los miembros de un equipo eran Product Executors. Es decir, miembros que se dedican a ejecutar órdenes en el desarrollo y evolución del producto, sólo ejecutan decisiones tomadas. El jefe o departamento de turno deciden el qué, el cuándo y el para cuándo y el equipo, en general, sólo tiene poder para decidir el cómo. Poco margen de decisión le puede quedar al equipo, más allá de cómo se desarrollará tecnológicamente el producto/proyecto (a veces ni eso)

Ahora, no es que tengamos jefes, que los tenemos. No es que no tengamos organigrama, que también lo tenemos. Y no es que nadie tome decisiones, que se toman. Pero el equipo tiene mucho peso en las decisiones y cada miembro del equipo de desarrollo es, en parte, también un Product Owner. El equipo tiene la figura de Product Owner que es el responsable de marcar la ruta de trabajo, de estudiar al cliente final, de conocer qué se quiere. Pero al final es el propio equipo quien decide qué se implementa (todo el mundo tiene la libertad de convocar reuniones para definir nuevas cosas), el cuándo se implementa algo (se hacen reuniones regulares donde el equipo planifica qué se hace y qué no), para cuándo estará cada cosa implementada (si el equipo decide que no estará para la fecha esperada se acepta la decisión del equipo o se negocia un menor alcance del producto) y el cómo.

Esto redunda en muchos beneficios para el equipo y, por consiguiente, para la empresa. Porque los miembros del equipo trabajan más motivados y sienten al producto como suyo propio. No son meros ejecutores de órdenes, si no que se involucran en las decisiones y, principalmente, se respeta cualquier decisión que sale desde el equipo. Los miembros están más implicados en el desarrollo y éxito del producto/proyecto.

Pero, obviamente, esto no es tan fácil de implementar. Para su éxito, se requiere una alta dosis de confianza de la empresa en el equipo, en su trabajo y en sus decisiones. Característica que no siempre (y, especialmente, en este país) se suele dar.

It's almost two years since I started working at King, and during all this time I've learned lot of things. One of them, being able to experience another way of working, organising and managing teams. Most likely, provided by using an agile methodology, but also promoted by the company culture.

All the companies I've worked for so far had a classic organisation and work methods. Pyramidal hierarchies, with typical bosses and where the team members were Product Executors. I mean, the members could only execute commands, already taken and agreed decisions. The boss or corresponding department decided the what, when, by when and, usually, the team could only decide how.

I don't mean we don't have bosses now, because we do have. I don't mean we don't have hierarchy, because we do have as well, or nobody takes decisions, because they are taken. But the team has too much to say when taking decisions and each team member is, kind of, a Product Owner. The role of Product Owner exists within the team, who is the person responsible of making the roadmap, study the final user, know what he/she wants. But, in the end, it's the own team who decides what is going to be implemented (everybody in the team has the freedom to organise meetings in order to specify and define new features), the when it's implemented (there are often meetings where the team plans what to do and what not to do), by when a feature is to be implemented (if the team decides that something can't happen for an expected date, the team decision is accepted or a smaller product scope is negotiated) and the how.

This results in many benefits for the team and, therefore, for the company. Because the team members will be working much more motivated and feeling the product as their own. They are not just command executors, but they are involved in the decision taking flow and, specially, any decision taken by them is respected. Resulting in a team totally get involved in the development and success of the product/project.

But, obviously, not everything is too easy to implement. For its success, this requires a high amount of trust from the company in the team, in its work and decisions. Something that usually (specially in Spain) doesn't happen.