Archivo de la etiqueta: productividad

Eficacia vs Eficiencia en Scrum

Llevo tiempo dandole vueltas

Ultima mente creo que estoy dando el mensaje incorrecto sobre Agile, que no persigue la eficiencia ya que waterfall es mas eficiente. Todo esto surge de una de las lineas que vi como propuesta del Manifiesto Lean Kanban. No hay sistema teoricamente más eficiente que el waterfall. Cada fase está realizada por un equipo especialista que, sin cambio de contexto, pasa todo su trabajo de una a la fase siguiente. Sin embargo waterfall falla en cuando hay cambios a mitad de proyecto, o cuando hay alguien que no hace perfectamente su trabajo. Cosas que ocurren el 100% de los proyectos. Sin embargo, un equipo que pasa de waterfall a scrum tiene sensación de perdida de eficiencia por las siguientes razones:

  • Reworking. Cada vez que se enseña el software al cliente existe la posibilidad de que toque rehacer algo. Implica cambiar cosas que has hecho en un sprint en el sprint siguiente. También para que el software sea entregable al fin de sprint muchas veces hay que hacer trabajo extra para dejarlo listo.
  • Tener que integrar en cada sprint hace que se tenga que cambiar el contexto continuamente. Si desde el sprint 1 el equipo está peleando con integraciones, a primer momento parece no ser tan eficiente como estar solamente desarrollando. Sin embargo, esto convierte el gran problema de la integración final en una molestia desde el primer sprint.
  • Reuniones de Scrum : planning, daily, review y el refinement. A los equipos a los que se les tradicionalmente se les da una lista de tareas sin mayor explicación, les parece que son innecesarias todas estas reuniones… “Era más productivo cuando se me daba la lista de tareas”.

Sin embargo, aunque no lo parezca Scrum hace que un equipo pueda llegar a ser mucho más productivo. Como indica el titulo del libro de Jeff Sutherland, se puede llegar a entregar el doble de valor en la mitad de tiempo que con metodologías tradicionales. Aunque esto no se consigue por la metra transición a Scrum y mucho menos en el primer sprint. Lo que sí que permite es el marco para que el equipo consiga gran eficiencia. ¿Cómo?

  • Promoviendo que no se haga más de lo solicitado (“make the right think done”). No se debe escribir una sola linea de código que no tenga que ver con el objetivo de la historia de usuario y no se debe hacer una sola tarea o historia que no esté dentro del objetivo de sprint.
  • Protegiendo al equipo de las interrupciones. El equipo está expuesto a interrupciones para hacer burocracia, explicar o documentar su progreso y hacer cosas que no tienen que ver con su objetivo de sprint. El Scrum Master es responsable de proteger a los miembros del equipo.
  • Focalizando las reuniones. Cada reunión Scrum tiene su objetivo y su ventana temporal. Esto hace que las reuniones mismas sean más productivas y permite que durante el tiempo en la que el equipo no está reunido (work time) no tenga que cambiar de contexto por culpa de ellas. Hay que detectar y minimizar o eliminar las reuniones sin foco y que no aporten nada al equipo o producto.
  • Mejorando la comunicación del equipo, haciendo que estén mas coordinados y tengan menos esperas y colisiones entre ellos.
  • Acercando el feedback y testing al momento de desarrollo. Esto hace que la corrección tarde hasta 20 veces menos que si se hubiera hecho semanas después.
  • Permitiendo al equipo pensar de qué modo mejorar a si mismo. Al juntarse en las retrospectivas les permite analizar cómo eliminar los impedimentos y desperdicios (waste) para hacer más y más puntos de historia cada sprint.
  • Permitiendo hacer experimentos de mejora durante un sprint y evaluar si seguirlo o no. Un equipo puede probar algo que parece una locura durante un sprint y evaluar en la siguiente retrospectiva su resultado. De este modo es posible encontrar modos ingeniosos de mejorar la productividad sin poner en riesgo el proyecto.

La proxima vez que explique Scrum, no olvidaré en contar ambas facetas (efectividad y eficiencia). Efectivamente se prima la efectividad ante la eficiencia, pero hay que transmitir que se puede conseguir mucha más eficiencia con equipo Scrum que en equipos tradicionales.

 

 

Las palabras del Daily Standup se las lleva el aire

Esto fue lo que había estado observando en un par de Dailyes. Un desarrollador podía decir a sus compañeros con pleno convencimiento: “Hoy voy a reticular los splines y fluzear los vértices del condensador” y al día siguiente decir que en el día anterior había hecho cualquier otra cosa sin inmutarse lo más mínimo. Lo más normal es que ni uno mismo se acuerde de cuales eran los objetivos que se había marcado el día anterior. ¡¡ Y mucho peor !!! Podía haber fallado completamente en cumplirlos por causas ajenas a su voluntad sin ni siquiera darse cuenta ni saber sus causas.

Otra cosa que había observado es que a veces se llega a los Dailyes sin tener claro cuáles van a ser los objetivos para ese día. Frases como “En cuanto termine esto ya veré con qué me pongo” o “Ahora miro el Kanban a ver que será lo siguiente”. En VSN hacemos los Daily standup a las 10 de la mañana, lo suficientemente pronto como para que sea el disparo de salida del día y lo suficientemente tarde como para que todo el mundo tenga claro ya en qué va a trabajar. El problema de no tener totalmente claros los objetivos para el día puede hacer que se acabe trabajando en las cosas urgentes y poco importantes que siempre surgen. Lo importante y no urgente se acaba retrasando hasta que es demasiado tarde. Además esto provoca que se acabe el día con la sensación de que aunque no se ha parado ni un momento,  no se ha hecho nada útil.

Eisenhower Matrix
http://www.gsdfaster.com/blog/wp-content/uploads/2015/02/eisenhower-matrix.jpg

Para evitar estos problemas, hemos llevado a cabo un experimento que por el momento está saliendo muy bien. Para el Daily todos llevan preparada un pequeña hoja (10cmx10cm) con la fecha y su objetivo (o máximo 2) para el día.  Usando estas pequeñas hojas leemos  lo que nos pusimos como objetivo el día anterior, si lo hemos cumplimos o no (y por qué) , cuál o cuales van a ser los objetivos para el día y qué bloqueos pueden ocurrir o qué necesidades vamos a tener para cumplirlos. Los Dailyes son ahora más productivos porque no se divaga con cosas que no tienen que ver con esos objetivos principales. Reuniones, tests, atenciones a soporte dejan de ser centro de conversación a no ser que hayan sido la razón para no cumplir lo importante.

TarjetaObjetivos

En el resto del día esa pequeña hoja encima de la mesa recuerda a qué se debe aferrarse. Conseguir este objetivo con la ayuda de herramientas como la técnica Pomodoro, reduciendo interrupciones, revisando el correo a horas fijas, gestionando correctamente las reuniones y automatizando lo automatizable… es otra historia.

 

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

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.

 

Antipatrón, midiendo el esfuerzo

<ironic>

Es muy dificil encontrar una métrica que evalúe el rendimiento de los miembros del equipo por separado. Cualquier libro moderno de gestión de personas recomienda evaluar al equipo globalmente pero nosotros, los buenos jefes de equipo, tenemos que recompensar a los que se están dejando el pellejo y localizar a los que no tienen suficiente compromiso con el proyecto.

Una cosa que hacemos bien en España, y por eso somos de los países más competitivos, es nuestra orientación al esfuerzo. Si no dedicamos mil horas diarias a algo y nos dejamos hasta la ultima gota de energía de nuestro cuerpo, un trabajo no está bien hecho. Otros países “más modernos” prefieren buscar formas de hacer el trabajo más comodamente… ¡Nenazas!

El esfuerzo es algo muy dificil de medir. Lamentablemente, las leyes de privacidad nos impiden usar electrocardiogramas en los trabajadores. Con ellas podríamos obtener de manera muy fiable el ritmo de trabajo de cada uno.

Afortunadamente hay otras formas más legales:

Medidor de sudor. Es una sencilla banda adhesiva que se pone en la frente de los trabajadores. Esta banda tiene un pequeño chip y un emisor bluetooth. La banda obtiene el nivel de sudoración en tiempo real y lo envía al servidor central. Cada día los trabajadores tienen que cambiar la banda adhesiva ya que queda (debería quedar) llena de sudor. Es importante tener consumibles  disponibles para que no haya trabajador sin banda. El único problema es que  cada persona sudora de manera distinta y el dispositivo es difícil de calibrar.

Medidor de sudor
Medidor de sudor

Dinamómetro de nalgas. Este es el más fiable  Es un sencillo dispositivo que se coloca entre las nalgas de cada trabajador. Mide la presión ejercida durante el trabajo por su parte trasera y se envía igualmente por bluetooth. A más presión recibida, mayor esfuerzo es el que está efectuando el trabajador. El dinamómetro es personal y cada trabajador debe ser responsable de su limpieza diaria.

Dinamometro de nalgas
Dinamometro de nalgas

Los datos recibidos del esfuerzo son monitorizados en tiempo real. De este modo, nosotros como jefes podemos alentar o castigar a esos trabajadores que no tienen los valores esperados. Se puede definir un máximo y mínimo para que el sistema genere una alarma en tiempo real. Todos los valores son almacenados por un servidor y pueden servir para una recompensa en retribución variable o ascensos. Igualmente, si los datos no son buenos, si por ejemplo no ha ocurrido ninguna presión de nalgas en un mes, con estos datos se dispone de una herramienta objetiva para un despido.

Naturalmente usando este sistema hay que evitar cualquier cambio que suponga una reducción en el esfuerzo. Iría en contra de nuestra política de recompensar el esfuerzo. Las metodologías ágiles son totalmente contraproducentes ya que se ha demostrado que su uso continuado puede bajar el nivel de esfuerzo global. Hay que evitarlas a toda costa.

</ironic>