La ventanita para la motivación

Tenía la edad de 10 años cuando el artista foguerer del pueblo (el que hacía la hoguera para las fiestas de Sant Joan) usó un local de los bajos de mi edificio para montar la hoguera de ese año. Después de hacer acopio de valor, me ofrecí a ayudarles en lo que pudiera. La mayor parte del tiempo solamente ayudaba a aguantar los listones de madera mientras los cortaban (eso sí, siempre haciendo la presión en el punto exacto necesario). Un día hice lo que para mi fue mucho más que eso, pude pintar un trocito de la hoguera, de 10 cm cuadrados más o menos. Eso para mi fue lo más. ¡Qué contento estaba cuando la hoguera estaba expuesta y yo miraba con orgullo y enseñaba a mi familia mi aportación, ese trocito del monumento que todo el mundo podía admirar!.

La visión global y la aportación personal es algo muy importante para la motivación personal. Sin embargo, dependiendo del tamaño de la empresa y el puesto que cada uno esté haciendo, puede ser muy difícil hacer llegar esa visión a todos. En empresas medianas y grandes, es posible que la única interacción de los desarrolladores con el resultado de su trabajo completado es cuando dejan las nuevas versiones listas para que otro departamento como el de operaciones lo instale. Una vez hecho esto, sólo les queda esperar a que el nuevo sprint empiece y tengan una nueva lista de cosas por hacer.

Aportar esa visión del trabajo realizado y cómo forma parte de algo mayor y más importante es una parte crucial de nuestro papel cómo líderes . Tienen que saber que cada palada de remo suyo hace avanzar el barco. Para ello es necesario que puedan ver al menos por una ventanita las cosas buenas y malas que ocurren en la empresa como resultado de su trabajo y el del resto de compañeros. Existen herramientas como los OKR que usan en Google y sistemas como Hoshin Kanri que ayudan a aportar esta visión y alineación pero cualquier esfuerzo que se haga por parte del lider en esta línea, debería aportar resultados satisfactorios en la motivación del equipo. ¿Tiene tu equipo esa ventanita?

Mi retrospectiva personal de entrada del 2016

Ya estamos a 1 de Enero del 2016. Es tiempo de buenos propósitos igual que el mes de septiembre. Las personas nos ponemos objetivos que muchas veces se quedan en el aire. Una buena forma en la que perduren un poco más y sean más efectivos es hacerlos públicos. El tenerlos escritos también sirve para que podamos evaluar en el próximo año cuántos de estos objetivos se han conseguido.

Yo este principio de año voy a hacer una retrospectiva personal.  Como hacemos en VSN cada final de sprint (periodo de 3 semanas) voy a usar el método llamado la estrella de la retrospectiva. Con esta forma de hacer retrospectiva se identifican acciones que encajen en una de las 5 puntas de estrella que corresponden con aspectos positivos que reforzar y negativos que mejorar.

  • Empezar a …
    • Tener un equipo de colaboradores para AgileAlicante.
  • Hacer más …
    • Actividades y viajes con mi familia.
    • Escribir artículos en mi blog para consolidar y compartir conocimientos.
    • Ayudar a la gente cercana a mi.
  • Seguir haciendo …
    • Deportes que me gustan como el Judo, correr y patinar.
    • Estudiar los temas que me gustan: agilismo, liderazgo, motivación…
  • Hacer menos …
    • Evitar las confrontaciones o negociaciones.
  • Parar de …
    • Estudiar temas que para mi no tienen ningún objetivo personal claro.

 

 

Precaución: el trabajo en equipo puede perjudicar al equipo

Estamos en una época de revolución de los métodos de trabajo. Se está demostrando que un equipo motivado, autoorganizado y con visión de producto es capaz de dar valor al cliente de forma rápida mientras aprende lo que va necesitando. Hemos aprendido a trabajar en equipo, colaborar, estimar en equipo, planificar en equipo…  Prácticas como el mob-programming en las que un grupo de desarrolladores trabajan en un mismo código con un mismo teclado están creando tendencia. Estamos abriendo las oficinas, quitando muros y juntando mesas para que haya comunicación entre todos los miembros, para que se vean y se oigan fácilmente y la comunicación osmótica fluya.

Sin embargo, todo esto tiene un límite. Estudios recientes están demostrando que la colaboración puede llegar a ser excesiva cuando impide conseguir los objetivos personales de los miembros del equipo. Actividades de colaboración (reuniones, responder preguntas, hacer coaching a un compañero, conectar por escritorio remoto para ayudar a un colega, etc …) puede llegar a suponer más del 50% del tiempo disponible de trabajo.

Además, se está demostrando que alrededor del 25-30% del valor añadido en estas colaboraciones es aportado por solamente el 3 ó 5% de los miembros. Son estas personas que están continuamente en reuniones o resolviendo preguntas. Su experiencia les ha convertido en personas indispensables a la hora de tomar cualquier decisión. Y esto desde cierto punto de vista está bien pero se acaba generando un círculo vicioso que hace que cada vez estas personas sean más indispensables y tengan menos tiempo para su trabajo personal.

Igualmente también nuestros adorados espacios abiertos se están convirtiendo en un problema. El ruido de conversaciones, notificaciones de los teléfonos móviles, sonidos de teclado pueden llegar a anular totalmente la capacidad de concentrarse en el trabajo. Según la comunicación osmótica es importante el valor añadido que puede dar una idea tuya que das por haber oído una conversación cercana o lo que puedes aprender de esa conversación. Pero estos hechos muchas veces son tan aislados que no compensa la falta de productividad que genera el no poder entrar en flujo por culpa del ruido ambiental.

La respuesta está en ser generoso  hacia el equipo con el tiempo personal pero también darle un gran valor. Cosas que se pueden hacer:

  • Saber decir que NO.
  • Priorizar las peticiones de ayuda (informativas, persuasivas y de tiempo).
  • Obligarse a tomar tiempo de concentración (pomodoros) con los auriculares puestos para evitar interrupciones.
  • Gestionar bien las reuniones. JGI
  • Gestionar correctamente el email y los sistemas de mensajería interna.

 

Fuentes

https://hbr.org/2016/01/collaborative-overload

http://time.com/money/4160139/collaboration-teamwork-lower-productivity/

https://hbr.org/2015/12/muting-unwanted-noise-in-an-open-office

Sobre la transparencia y los tests hechos por desarrolladores

Hace poco me contaron que un CEO de nuestra competencia vio un vídeo en Youtube diciendo que no teníamos equipo de QA. El vídeo en cuestión es la charla que di para el Lean Kanban South Europe 2015. En esta charla hablaba de cómo usabamos Kanban para reducir el tiempo de feedback entre desarrollo y testing y cómo podíamos responder a requerimientos de proyectos, a soporte y además avanzar en producto.

Mi frase  “No tenemos ningún tester ni equipo de QA” se sacó de contexto y se usó como comentario para crear malestar. En VSN tenemos cerca de los 2000 tests automáticos que se pasan varias veces al día y que incluyen de unidad, de integración y de interfaz. Tenemos procedimientos muy concretos, certificados con una ISO 9001 sobre hacer el test cuando terminamos de desarrollar y además realizamos una batería completa de tests manuales de regresión en la que todo el equipo comprueba de manera transversal todo el producto antes de dar por buena una entrega. Usamos muchas de las técnicas incluidas en las certificaciones internaciones de Agile Testing. El no tener equipo de tests separado cada vez se está adoptando más para conseguir una respuesta rápida al cliente sin bajar en calidad. Además empresas como Atlassian estan descubriendo y demostrando que los desarrolladores pueden ser buenos testers. Piensan igual que yo que cuando los desarrolladores tienen el mismo criterio de calidad que los testers, los productos de alta calidad se CONSTRUYEN desde el principio.

Volviendo al tema de la charla, creo que el hablar sobre cómo trabajamos en VSN es más beneficioso que perjudicial. VSN cada vez está mas presente en charlas y conferencias a nivel nacional e internacional. Aquellos que usan frases sueltas de lo que decimos  y basan su “perfección” en su oscurantismo son los que deberían reflexionar sobre cómo hace las cosas. Nosotros esta reflexión la hacemos cada 3 semanas desde hace más de 6 años de manera contínua y es la que nos permite ser cada vez mejores, piensen lo que piensen otros.

 

¿Qué motivadores consideras más importantes en tu vida?

Me encantó el libro Workout de Jurgen Appelo. Expone claramente por qué deberíamos tener otra perspectiva del management, con más gente que se auto-dirija y menos directores. Esto permite un incremento de productividad, creatividad y motivación que no se pueden conseguir fácilmente con métodos tradicionales.

Una herramienta que voy a empezar a usar es la de “Moving Motivators“. Con este ejercicio, uno evalúa distintos motivadores y se ordenan de derecha a izquierda según  tienen más o menos importancia para el/ella. Estos motivadores son:

Curiosidad. Ver cosas novedosas, fuera de lo común. Aprender cosas nuevas cada día

Aceptación. Ser miembro de un equipo como uno más tal y como es y con lo que hace. Formar parte de los éxitos y ser reconocido cuando se hacen bien las cosas

Maestría. Llegar a ser un experto de una tecnología o técnica mediante estudio o experiencia y poder compartirlo con otros

Poder. Poder tomar las decisiones que tienen que ver con la forma de trabajar y el entorno. Expresar autoridad.

Libertad. Poder hacer cosas sin preguntar y ser creativo. No depender de aprobaciones de otros o normas estrictas.

Relaciones. Relaciones sinceras y abiertas con otras personas. No trabajar sólo.

Orden. Estabilidad, concreción, determinismo, sin sobresaltos, con procedimientos y opciones claras

Objetivos. Poder cumplir objetivos personales o profesionales.

Status. Tener un posición importante y respetada por el resto.

Moving motivators right to lefty
Tarjetas con los motivadores puestos en orden. Más importante a la derecha, menos importante a la izquierda.

Esta semana empezaré a usarlos y haré un experimento cuyos resultados quiero compartirlos dentro de poco.

 

 

Ten un Maestro Elodin en el equipo de desarrollo

“Words are pale shadows of forgotten names. As names have power, words have power. Words can light fires in the minds of men. Words can wring tears from the hardest hearts.” 
Patrick Rothfuss, The Name of the Wind

En VSN hemos contratado hace unas semanas a un escritor técnico. Su misión principal es escribir los manuales que incluiremos y estarán enlazados desde nuestro software para consultar rápidamente.  Pero su colaboración hacia el equipo de desarrollo está yendo mucho más allá.

“Every time you write a comment, you should grimace and feel the failure of your ability of expression.”
Bob Martin, Clean Code 

Muchas veces es difícil encontrar la palabra adecuada para esa variable, método o clase cuando estamos desarrollando. Para no quedarnos parados indefinidamente pensando acabamos añadiendo un comentario que explica su uso.

En el caso de manuales ocurre lo mismo respecto al software que documentan, existen por la incapacidad del software de ser autoexplicativo. Para que no hiciera falta manual, cada botón, etiqueta y elemento del interfaz debería indicar por sí mismo y de modo preciso qué es y para qué sirve sin tener que consultarlo en un manual. Esto implica que el equipo de desarrollo debe encontrar el nombre perfecto en cada ocasión, lo cual es una tarea nada fácil. En los libros de Rothfuss el encontrar el nombre perfecto de las cosas es la habilidad de los llamados maestros nominadores, como el Maestro Elodin.

Ahora tenemos la suerte de que David Branco, nuestro escritor técnico, esta cumpliendo este rol. Siempre tiene para nosotros la palabra precisa que necesitamos para poner el nombre a un nuevo tipo de almacenamiento, el texto de una etiqueta o del botón que estamos añadiendo para que exprese de modo preciso su misión. Ya tenemos nuestro Maestro Elodin.

Optimiza el uso de tu memoria (mental)

¿Cuantas cosas sabes hacer a la vez? ¿y hacerlas realmente bien? ¿Y además en un tiempo aceptable? Antes de responder a estas preguntas, me gustaría que conocieras cómo funciona nuestra mente.

El cerebro está compuesto de bloques de memoria de cortisimo plazo o de trabajo, de corto plazo y de largo plazo. Cuando realizamos un trabajo utilizamos una combinación de todos estos bloques a la vez. Por ejemplo, un desarrollador de software necesita tener en la mente el lenguaje de programación a usar, el diagrama conceptual del proyecto que está modificando, el objetivo de la funcionalidad que está desarrollando y en la zona de cortísimo plazo el algoritmo que se está escribiendo en ese momento. Un ingeniero de soporte puede tener el sistema del cliente, los detalles del problema en cuestión y el producto del cual está dando soporte. Un comercial puede tener detalles del producto que vende y detalles del cliente al que quiere vender.

Bloques de memoria de un desarrollador concentrado
Bloques de memoria de un desarrollador concentrado

Contínuamente tenemos que reemplazar estos bloques. Esto puede ser  por una interrupción que provoca un cambio de contexto y necesitas modificar tu memoria de más corto plazo. Pero también puede ser cuando cambias a desarrollar otro programa, otra historia de usuario u otra funcionalidad, incluso por un cambio de lenguaje de programación. Cada cambio requiere que uno o más bloques de memoria se reemplacen. Y ese reemplazo tarda tiempo. Si es memoria a corto plazo puede tardar incluso más de 15 minutos pero si es memoria de medio plazo como el lenguaje de programación se puede tardar días en sustituirlo completamente.

Cambio de tarea en otro lenguaje de programación
Cambio de tarea en otro lenguaje de programación

Hasta que un bloque es completamente sustituido, el bloque tiene una mezcla de distintos contenidos. Es el momento en el cual se toman decisiones incorrectas y se cometen fallos. Es cuando lo justificamos a que no estamos completamente concentrado y se producen frustraciones.

Para tomar mejores decisiones, realizar un trabajo de mejor calidad y más rápido hay que reducir el WIP. WIP significa trabajo en curso (Work In Progress) y hay que intentar que como máximo se tenga una tarea en la cabeza,  o una característica nueva a la vez por equipo, o una incidencia de soporte a la vez. Ya existen herramientas como Kanban, GTD y la Técnica Pomodoro para ayudarte a enfocarte en una tarea o con un mínimo de trabajo a la vez. Pero ninguna de estas técnicas ayuda a decidir con qué tareas ponerse o qué trabajo empezar una vez se ha terminado para minimizar el reemplazo de la memoria de trabajo.

Para ello propongo hacer una lista de los 5  elementos que más se tienen en cuenta a la hora de realizar una tarea . En el ejemplo del desarrollador de sofware, haríamos esta lista:

  • El tipo de tarea a hacer: desarrollo, administrativo (emails, imputar,…) , test, formación…
  • El lenguaje de desarrollo a usar
  • La estructura del programa a modificar
  • El framework o API que se usa: ASPNET MVC, Backbone, Angular,…
  • Las características del cliente que usará la funcionalidad

Para cada característica distinta a la de la tarea que se ha terminado se suma un punto. Si hacemos un tipo de tarea completamente distinta tendríamos 5 puntos porque seguramente necesita reemplazar todos los bloques de memoria. Si es del mismo programa pero hay que cambiar de lenguaje es un punto por el cambio de lenguaje y seguramente otro por el cambio de framework llegando a 2 puntos. Cada vez que se elige una nueva tarea hay que evaluar los puntos de lo que podemos empezar dentro de las que tengan igual prioridad. Idealmente se elegirá una tarea del mismo lenguajes, del mismo programa, con el mismo framework y para el mismo cliente. De este modo reducimos el número de bloques de memoria a reemplazar consiguiendo un resultado con mejor calidad, en menor tiempo y sin frustraciones.

 

Cómo el stress afecta a la calidad del software

El uso de las metodologías ágiles en el desarrollo de software ha supuesto un antes y un después en relación a la calidad de los productos. Webs, aplicaciones, juegos, son cada vez más elaborados, imaginativos y más seguros.

Uno de los principios ágiles habla de ritmo sostenible (sustainable pace). La interpretación más aceptada es la de jornadas de trabajo de 40 horas semanales. Está más que demostrado empíricamente que las horas extras en desarrollo de software está linealmente relacionado con un incremento en los bugs cometidos.

Bien, pues aquí tenemos la razón.  La culpa la tiene el stress.

El stress envía hormonas a la sangre para preparar al cuerpo y la mente para la situación amenazante. Durante miles de años, para los humanos, las situaciones amenazantes tenían que ver con peligros físicos de animales depredadores, posibles accidentes o peleas entre tribus y estas sustancias preparaban al cuerpo para afrontarlas. Sin embargo en la época de la información y para trabajadores del conocimiento tienen precisamente el efecto contrario.

Estas dos simpáticas hormonas son la famosa adrenalina, que produce un incremento en el ritmo cardíaco, la presión de sangre y la respiración; y glucocorticoides como el cortisol. Bueno, pues estos últimos producen entre otros, unos efectos muy perjudiciales a la memoria de corto plazo y la memoria de trabajo.

La memoria de trabajo es la parte del cerebro en la que almacena los datos que tenemos que combinar, comparar y analizar para resolver los problemas. Nuestra memoria RAM. Tipicamente un cerebro  normal mantiene y trabaja con 7+-2 chunks o bloques de datos simultáneamente para resolver los problemas. Los glucocorticoides reducen este número por lo que la mente se ve limitada a trabajar con menos datos y menos alternativas para intentar resolver ese diseño o ese código que hay que hacer que funcione.

Los militares han hecho muchos estudios relacionados con la reacción de las personas en situaciones de stress (ver referencias). En un estudio se demostró que el stress tenía el efecto positivo de reducir el tiempo de reacción, sin embargo esto tenía el efecto colateral de crear un mayor número de falsas alarmas y errores que las surgidas en condiciones de tranquilidad. Es decir, estresados fallamos más que una escopeta de feria. Mantenemos nuestra atención en la parte negativa del problema para intentar resolverla lo cual nos impide mirarlo desde fuera, afrontarlo lateralmente para poder ver otros ángulos y encontrar mejores soluciones.

En otro estudio se demostró que las personas, en situaciones de stress experimentamos una percepción superficial de la realidad, poniendo nuestra atención sólo a una pequeña parcela del problema a la hora de tomar una decisión o encontrar una solución. En este estado de alta tensión tomamos decisiones basadas en un conjunto incompleto de información y tomamos atajos basados en experiencias pasadas.

En resumen, tenemos que un desarrollador o u trabajador en general cuando está estresado reduce  su memoria de trabajo, no es capaz de tener visión lateral y creativa y toma atajos para resolver el problema lo más rápidamente posible sin pensar en más allá que el alcance de su problema… Conseguimos al DESARROLLADOR BOMBA. Preparaos para bugs por doquier, deuda técnica acumulandose, software de baja calidad y clientes decepcionados.

Todo esto se puede evitar manteniendo el ritmo de trabajo a un ritmo mantenible. Respetando la capacidad del departamento de desarrollo mediante sistema PULL con Kanban o de compromiso de equipo en el  sprint de Scrum. Respetando la definición de DONE sin saltarse por la presión y manteniendo un ambiente de trabajo animado y relajado. Todo esto no debe ser un lujo, sino un requerimiento.

 

 

 

 

 

 

 

 

 

 

Referencias

 

http://en.wikipedia.org/wiki/Effects_of_stress_on_memory

http://en.wikipedia.org/wiki/Short-term_memory

http://en.wikipedia.org/wiki/Working_memory

http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

http://the-programmers-stone.com/wp-content/uploads/2007/10/StressAndPerformance.pdf

http://www.researchgate.net/publication/259781769_Impact_of_Overtime_and_Stress_on_Software_Quality

¿Le compramos un I5 ó un I7 al nuevo desarrollador?

Quizá alguna vez te has visto envuelto en una discusión parecida. Entra un desarrollador nuevo o hay que renovar el ordenador de uno de los desarrolladores y toca pedir uno. Entonces la persona encargada de compras puede intentar ahorrar y puede preguntar cosas como “¿Con un I5 es suficiente, no?”

Voy a intentar explicar un poco por qué es muy peligroso ahorrar en cosas de este tipo:

Imaginemos una empresa de desarrollo normal, una PYME, con unos gastos medios de 100.000 € al mes. Este gasto incluye equipo de comerciales, administración, marketing, operaciones y por supuesto desarrollo.Incluye tanto gastos en personal como gastos de instalaciónes y gestión. La cantidad de pasta que necesita la empresa para producir y vender  su producto, en nuestro caso software, son 100.000 euros mensuales.

Captura de pantalla 2014-11-01 a las 23.18.00

 

Ahora vamos a pensar en qué departamento es el cuello de botella, es decir, qué equipo es el que determina qué cantidad de producto llega al cliente final. Lo normal en una empresa de desarrollo de software que va más o menos bien es que el cuello de botella sea el equipo de desarrollo. Si se desarrolla más rápido cuando se tiene un proyecto para un cliente, se cobrará antes y se podrá empezar antes con otro proyecto. Si se desarrolla producto, contando con una buena elección de producto y características, se cuenta con que cuanto más se desarrolle, mejor es el producto y más vende.

Captura de pantalla 2014-11-01 a las 23.30.26

La Teoría de las Restricciones nos dice que la productividad total de una empresa está limitada por la productividad del cuello de botella. Si el cuello de botella, en nuestro caso el departamento de desarrollo, incrementa un 1% su productividad, es la empresa completa la que incrementa su productividad un 1%. Lo mismo ocurre al contrario, si la productividad decrece un 1%, es la productividad de la empresa al completo la que decrece.

Teniendo en cuenta que para conseguir esa productividad, esa cantidad de producto vendido al cliente, la empresa gasta 100.000 € al mes, es lógico pensar que cada 1% de productividad le cuesta 1.000€ al mes a las arcas. Un 1% de productividad perdido por una herramienta de bajo coste, en nuestro caso un ordenador barato, alargada por la vida útil del mismo, digamos 2 años, resulta en 12.000€ de productividad perdidos. Todo por haber comprado un portátil de 400€ del Media Markt.

Después detodo esto…,  ¿Empezamos a hablar de discos duros SSD?

Wastes o desperdicios en desarrollo de software

Me he propuesto hacer el ejercicio de identificar qué desperdicio Lean está asociado a cada lastre de una retrospectiva y cual se elimina o reduce en cada motor. Para saber de qué estoy hablando con motores y lastres entra aquí

Para que no vayas buscando en la wiki o páginas aparte cada lastre voy a resumir cuales son los 7 +1 wastes en desarrollo de software

1. Esperas. Esperas por recibir un detalle de un requerimiento, esperas para tener un build completo, esperas a que se completen los tests, esperas hasta que lo que has desarrollado lo prueba el cliente y te dice si es lo que quería, esperas a que un compañero te resuelva una pregunta que no te deja continuar…

2. Sobreproducción. Hacer programas que nadie necesita y nadie usará nunca.

3. Sobreingeniería. Es parecido al anterior. Desarrollar funcionalidades que no se han pedido sólo por aprovechar el tiempo en algo. Por ejemplo, preparar un sistema para millones de usuarios cuando es una panadería local.

4. Stock. Sí, en desarrollo también existe el stock. Stock de análisis de historias que nunca llegan a desarrollarse, stock de desarrollo que nunca se completa o se prueba, stock de funcionalidades que nunca llegan a deploy. Cada uno de estos stocks ocupan espacio en complejidad, y hace más difícil nuevos desarrollos sin que haya dado valor.

5. Transporte. En desarrollo de software el transporte está relacionado con el cambio de contexto. Cada vez que tienes que pasar contenido de la memoria a largo plazo a  la de corto plazo hay trasaporte. Ejemplos son cambios de historias en el mismo día, cambios de lenguajes de programación, cambios de rol del programador.

6. Movimiento. Es movimiento de personas tanto en espacio físico (para preguntar, pasar a otro ordenador, etc..) como movimientos virtuales (entrar en una ruta de directorios compleja, muchos clics para resolver un problema o hacer una acción)

7. Defectos. No creo que haya discusión en esto. Cualquier defecto en diseño, desarrollo o test provoca trabajo extra. Cuanto más se retrasa el momento del defecto a su descubrimiento y resolución, mayor suele ser ese trabajo extra o coste.

y el +1. Talento. Cada vez que uno realiza un trabajo que puede hacer otro, desaprovechando el talento o conocimientos que nadie más tiene, es un desperdicio.  Muchas veces ocurre por aliviar un cuello de botella pero hay que evaluar el sobrecoste de ese desperdicio de talento para buscar otras formas de gestionarlo.