Bueno, lo sería si sólo nos importa la tecnología, pero ¿qué hay sobre la idea? , ¿tiene sentido? ¿Necesitas toda esta tecnología para validar tu idea o podrías implementar una aplicación mucho más sencilla para ese cometido? Intenté obtener respuestas a estas preguntas pero fue realmente complicado porque, o bien estaban muy ocupados desarrollando su idea, o bien pensaron que mis preguntas eran estúpidas y no merecían una respuesta. Se enamoraron de la tecnología y se olvidaron de lo más importante, ayudar a los refugiados.

Ésto no es una crítica a un equipo que derrochaba talento sino una reflexión sobre cómo los técnicos podemos perder el foco y poner nuestros prioridades por encima de las de la compañía o las del cliente. Sin embargo tengo que reconocer que el formato del evento pudo conducir a la gente a preocuparse más por la tecnología que por ayudar a la gente. En cualquier caso, éste es un comportamiento que he visto algunas veces a lo largo de mi carrera y es peligroso. No programamos ordenadores sino que solucionamos problemas.

Para mi, liderar gente no consiste en alinearlos y ayudarlos a conseguir los objetivos del equipo, para mi es mucho más. En mi opinión el fin ultimo es ser reemplazable.

Hace algún tiempo tuve la oportunidad de construir un equipo para desarrollar un nuevo producto. Tenía que hacerlo con gente de dentro de la compañía, gente a la que no conocía, gente sin experiencia en las tecnologías y practicas que íbamos a usar. Al principio tome una postura más, llamémosle, dictatorial. Algo como esto:

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” ― Jim Barksdale

Poco a poco el equipo fue ganando confianza y experiencia pudiendo moverme a un estilo de liderazgo más agile. Dando al equipo más libertad y responsabilidad. Pero la parte interesante de esta historia fue que algunos miembros del equipo no pararon ahí, se convirtieron en autentico líderes. Todo el mérito fue suyo, lo único que yo hice fue no impedirlo.

Esta clase de liderazgo es en la que yo creo y a la que me refería, uno dónde todo el equipo (o algunos miembros de el, eso esta bien también) lidera. Me gusta construir esta clase de equipos y trabajar formando parte de ellos.

Los errores

En mi opinión uno de los errores más importantes fue no conseguir que una ONG respaladara el evento, tanto apoyándolo con su nombre como participando en él. No teníamos gente que hubiera estado en el terreno y se notó. Me gustaría justificar qué hizo que no pudiéramos conseguir ese apoyo pero a día de hoy no lo sé. Por otro lado, hablando de cosas que dependieron de mí, la asistencia. A pesar de enviar un email dos semanas antes del evento y otro el día anterior tuvimos un absentismo cercano al 50%, está claro, no cobrar es un error. Aunque sea algo simbólico hay que cobrar para que sólo se apunte gente realmente interesada.

El evento

5 equipos se encargaron de dar vida a 5 ideas de entre las 22 propuestas. Trabajaron durante la tarde del sábado y todo el domingo y al final presentaron el resultado ante compañeros e invitados.

• MeanIt – Una plataforma donde voluntarios pueden ofrecer bienes y servicios para refugiados.
• Morewithless – Movimiento para involucrar a compañías a proveer un mecanismo para que sus empleados donen parte de su salario a causas sociales.
• Refubot – Bot para enviar alertas a través de redes sociales.
• Newlife – Plataforma para gestionar donación de tierra y hogares en desuso a refugiados que pueden darle una segunda vida.
• SocialArcade – Campaña de crowdfunding para financiar la construcción de tres máquinas arcade cuya recaudación irá destinada a proyectos sociales.

La verdad es que este tipo de eventos se viven de una forma muy distinta desde la organización, mucho más preocupado de que todo salga bien, de comunicar todo lo que se está haciendo y de ayudar a los equipos a sacar adelante sus proyectos. Aún así, me alegró ver viejos amigos y conocer gente nueva comprometida y con ganas de ayudar a los demás.

El post evento

Esta es la fase en la que estamos ahora, 5 equipos trabajaron durante dos días pero aún no hemos ayudado a nadie. Sinceramente soy incapaz de juzgar si las ideas desarrolladas son buenas o malas, por eso mi cometido ahora es darle visibilidad para que sean otros, los que saben de esto, quienes decidan si algo de lo que se hizo aquí puede ser útil. Hacerlo todo bajo licencias libres es sólo el primer paso, si nadie sabe que existe difícilmente podrán reutilizar el conocimiento que se generó durante estos dos días.

Conclusión

Después de todo el trabajo que supone organizar un evento como este, trabajo que aún no ha terminado, no te quedan muchas ganas de meterte en otra. Pero sería desperdiciar todas las lecciones aprendidas y darle la espalda a una causa importante. Habrá que replantearse algunas cosas e intentar subsanar los errores cometidos pero tarde o temprano cogeremos la oferta de la ESEI y empezaremos con la organización de la siguiente edición, estoy seguro.

Agradecimientos

Gracias a Microsoft, Quobis y la ESEI por su colaboración financiando el evento. La comida que sobró se donó a la Asociación Vida Digna y el dinero recaudado, unos 200 euros, se donarán a Proactiva Open Arms . Gracias a todos lo que respondieron a la llamada, y también, por supuesto, a Sonsoles, Carlos y Edo por su entrega y ayuda.

Enlaces de interés

• Seguimiento en twitter
• Resultado
• GitHub
• Fotos

Si me preguntas cual fue mi mayor error como CTO te diría que fue gestionar demasiado a mi equipo. Creo que lo llaman micro-management. No es una excusa pero de un día para otro me hice responsable de muchas personas y proyectos y perdí el buen juicio. Quería controlar todo, asignar cada tarea, hacer seguimiento de todo el trabajo en curso, estaba al tanto de cualquier problema. Todo eso, todos los días hasta que no pude más.

Me dí cuenta de que lo estaba haciendo mal, cometí el error más frecuente que todo el que empieza con Agile comete, no confiar en tu equipo. No tienes que preocuparte de si están trabajando duro o si sus decisiones son las buenas o… no, no, no, debes enfocarte en la calidad del producto y en cumplir los objetivos. ¡Déjales equivocarse! Si toman malas decisiones, si el código es de mala calidad, la cadencia de entrada se verá afectada porque hacer cambios será más costoso y el todo estará contaminado de errores, el equipo lo notará y tu también. Juntos tendréis que buscar soluciones. Si el equipo no es capaz de encontrar un ritmo sostenible tendrás que ayudarlos. Tendrás que estar a su lado cuando fallen y entreguen cero valor al resto de la compañía o al cliente. Pero nada más.

Algunas cosas importantes: debes compartir una visión común con tu equipo, debes acordar un objetivo común para la iteración, debes proveer soporte para cada problema y, lo más importante, debes trabajar con profesionales no con niños que fingen serlo. Créeme, ésto será lo más difícil, pero sin ésto conseguir una relación de confianza con tu equipo es imposible y ésta es la base de todo lo demás.

Casi seguro que tu desarrollo es muy dependiente de esta persona, el resto de miembros no sienten el código como suyo (propiedad colectiva del código), se rompen cosas con frecuencia debido a efectos laterales, las decisiones de diseño no se toman en equipo, etc. Malo cuando la aplicación es pequeña pero cuando crece y la complejidad aumenta puede ser catastrófico, una bomba de relojería a punto de estallar. La complejidad que una persona puede manejar es limitada, tarde o temprano tú solo-man se verá sobrepasado. Los bugs serán cada vez más frecuentes e introducir cambios más lento, el resto del equipo empezará a cansarse de encontrar cambios en el código con los que no está de acuerdo y empezarán a marcharse.

Aunque te pueda parecer que la situación descrita no es para tanto y que es tolerable como profesionales, nuestro compromiso no debería ser hacer equilibrios sobre lo tolerable sino ofrecer lo mejor para resolver el problema sin malgastar el dinero de nuestros clientes o nuestra empresa.

Sé profesional, juega en equipo.

Los peores product owners que he tenido fueron aquellos con un perfil técnico.

Si tuviera que señalar el mayor error que nos hizo fracasar con Refly diría que fue convertir un proyecto que nos gustaba y queríamos hacer en un producto que nadie pedía. De hecho, cuando descubrí devdocs.io debimos abandonarlo, y no porque la competencia sea mala sino porque cumplia de sobra con nuestras espectativas iniciales.

De todos modos no me arrepiento, fue un tiempo en el que aprendí muchísimo sobre startups, productos y equipos. También me hice un experto en todo este mundillo de la documentación de proyectos software y su posterior consulta y sigo pensando que hay hueco, tal vez algún día.

Lo hicimos lo mejor que supimos y creamos una aplicación de la que estar orgullosos pero no era un producto. Sin tiempo ni ingresos y con otra gente proporcionando un servicio similar creo que lo mejor es decirle adiós pero algún día volveremos.

Pepe sostiene que la daily, esa reunión en la que se hacen las tres dichosas preguntas, es una de las más importantes de Scrum y yo me pregunto ¿cómo ha conseguido que funcione? Pero antes de que me des la chapa sobre cómo la haces en tu empresa déjame que te cuente a qué me estoy refiriendo.

La mécanica de la daily es muy sencilla pero… que levante la mano el que crea que la daily es para que todo miembro del equipo sepa que están haciendo los demás. Si ese es el problema que estás resolviendo en esta reunión, créeme, tienes otros. Si hay buena comunicación, si el tablero está actualizado, si todo el mundo usa el tablero… en fin…

La daily persigue objetivos más elevados. Por un lado, por supuesto, está uno de los motivos recurrentes en todas las reuniones, hacer equipo. Sin embargo, como muy bien dice Pepe en su charla, la daily es la reunión que se preocupa del sprint. Si vamos a la velocidad prevista, si tenemos bloqueos y cómo los resolvemos pero, sobre todo, es la reunión en la que la autoorganización del equipo debería brillar. Es cuando un miembro se dirige a otro y le pregunta cómo puede estar tardando tanto con esa tarea y se ofrece para ayudar. Es cuando se detecta un bloqueo que no se puede superar y el equipo decide lo que va a hacer para no afectar al sprint. Es cuando nos damos cuenta de que el tamaño de una tarea es demasiado grande y negociamos con el cliente recortar funcionalidad. En definitiva es cuando el equipo al completo toma el rol del detestado jefe de proyecto.

¿Sabéis cuántas veces he visto una daily funcionar así? Cero. Y es más, me pregunto: si tengo un equipo tan bueno que es capaz de hacer así las dailys ¿por qué no probamos a quitarlas y les damos el superpoder de hablar cuando necesiten?

He tenido mejores conversaciones delante de un panel Kanban que en una daily. Porque el panel kanban se centra en la imágen completa, bloqueos, wip, cadencia de entrega… mientras que la daily se centra en las personas y hace falta tener un equipo muy maduro para que esa interacción funcione como yo espero.

Desde hace un tiempo he vuelto a enfocarme más en la parte técnica de agile que en la parte metodológica pero sigo teniendo mi opinión, lo siento por los Pepes del mundo

Pero hoy no vamos a hablar de Agile, al menos no de forma directa. Hoy vamos a hablar de un par de cosas que para mi son importantes cuando decido pasar a formar parte de la familia de una nueva empresa.

La primera es trabajar en remoto. Se puede trabajar en remoto pero no es fácil. Durante los dos años que estuvimos con Refly y ahora en Quobis he trabajado y trabajo en remoto. En mi opinión trabajar de esta forma requiere una constante comunicación y una total transparencia. Esta última es la segunda de mis razones.

Ambas exigen un cambio cultural a nivel empresa y un cambio mental de todas las personas que componen la organización. Incluso cuando no se está en remoto hay que seguir trabajando de la misma forma y la información debe seguir estando disponible para cualquiera que la pueda necesitar. Y aunque todo esto puede parecer un gran reto tecnológico la verdad es que las herramientas están ahí fuera, el problema como casi siempre son las personas. Tendemos a ir hacia lo fácil, hacia lo que estamos acostumbrados y, aunque no seamos conscientes, nos resistimos al cambio.

El riesgo es acabar teniendo islas de una o varias personas. Nada que no pueda ocurrir también en un entorno de trabajo presencial, todos hemos conocido al típico bandolero. De hecho, las estructuras típicas de las empresas que se empeñan en mantener tu culo pegado a su silla favorecen la creación de islas.

Yo no sé si todo el mundo puede o quiere trabajar de este modo pero si parece que cada vez hay más gente haciéndolo y que esta opción seguirá aumentando. Por mi experiencia con Refly os confirmo que puede funcionar muy bien pero también que si no funciona lo hará a lo grande. Existen términos medios pero probablemente sea porque no es un modelo totalmente distribuido, sino que es un modelo basado en islas y bandoleros.

No se por qué, pero DIP, IoC y DI son términos que normalmente se confunden y se usan indiferentemente. No me preocupa, en la práctica parece que el concepto ha asentado y que todos lo tenemos más o menos claro. Pero cuando se propone aplicar estos conceptos en un proyecto para poder inyectar mocks en los tests me doy cuenta de que, tal vez, vale la pena pararse un poco y recapacitar.

Dependency inversion principle (DIP) es un principio de diseño que nos habla sobre acoplamiento, específicamente sobre no acoplar nuestro código a implementaciones concretas si no a abstracciones. Una forma de conseguirlo es aplicar Inversion of Control (IoC), un concepto muy genérico que no se aplica sólo a las dependencias y que queda resumido en el Hollywood principle: “no nos llames, nosotros te llamaremos”. Y con todo esto llega Dependency Injection (DI), un tipo específico de IoC que nos ayuda a conseguir DIP. Claro, ¿verdad?

Lo importante de todo esto es que aplicando estos principios y técnica conseguimos un código menos acoplado y más testable, no al revés. No usamos todos estos conceptos para poder hacer tests unitarios. Ya lo se, parece lo mismo pero no lo es. Si empiezas a introducir estos cambios en tu código de forma puntual para poder hacer algunos tests, terminarás con un código plagado de puertas traseras, contaminado por los tests. Sin embargo, si dejas que los tests te alumbren el camino y te señalen esos malos olores, podrás volver al dibujo completo y decidir qué cambios quieres incluir en tu diseño, terminarás con un código más desacoplado y consistente.

Cuando escribes código partiendo de las pruebas tomas decisiones inconscientes: cómo será tu api, qué devolverá este método o aquel, qué recibe en la llamada… La atalaya de las pruebas es muy buena para este tipo de decisiones ya que las tomas desde el punto de vista de quién usará tu API. Sin embargo, en mi opinión, hay algunas decisiones, como aplicar un patrón arquitectónico, que deben ser conscientes, evaluadas y razonadas porque las pruebas nos tienen que guiar pero a veces hay que modificar la ruta y el GPS eres tu.