Archivo de la categoría: Agile

A vueltas con el Manifiesto Lean Kanban

Hace un par de semanas vi este tweet de David J Anderson, creador de Kanban para desarrollo de sofware. Sé que hace tiempo que viene dandole vueltas a tener un manifiesto Lean Kanban y no sé si este será finalmente el que tomen pero sí tiene muchos puntos para reflexionar. Empieza así:

I believe in…
Empirical Process over Defined Process
Kanban, Scrum y otras metodologías ágiles están basados en el empirismo: transparencia, inspección continua y adaptación. Definir los procesos es necesario para estandarizar el trabajo y buscar mejores formas de hacerlo pero la situación real de cada momento es lo que manda.

System Thinking over Analytical Thinking
System Thinking se caracteriza por visualizar cualquier trabajo u operación como una serie de pasos interconectados que forman un flujo. Una vez definido y estandarizado este flujo de trabajo es posible ser ejecutado por más personas sin depender de un análisis concienzudo de cada petición de cliente por parte de dirección. Permite escalar una organización, buscar la mejora contínua y el empowerment de los que trabajan en ella. 

Effectiveness over Efficency
A esta le estuve dando muchas vueltas. Siempre se piensa en la eficiencia como algo que hay que perseguir pero, ¿es realmente lo más importante?. Pensando en cualquier sistema adaptativo, lo primero que hay que conseguir es un resultado de la manera más simple y lo antes posible con los medios y los conocimientos que se tienen en el momento de empezar. Por ejemplo, si el cliente piensa en tener un coche dentro de un año, nosotros le entregamos un monopatín en dos semanas. Realmente no es la forma más eficiente de trabajar ya que podríamos empezar a construir el coche sin tener que rehacer nada, pero podríamos fallar completamente buscando la forma más eficiente desde el primer momento. La eficiencia se busca poco a poco, historia tras historia, iteración tras iteración. Hazlo ya, vuélvelo a hacer de forma más eficiente, hazlo otra vez de forma aún más eficiente, y otra y otra…
Flow Efficiency over Resource Efficiency
Tradicionalmente se ha intentado aprovechar mejor los recursos individuales que ocuparse en el flujo completo de valor, desde la primera fase hasta la última. La gente de backend haciendo servicios a todo trapo sin que posiblemente los de front end tengan tiempo de integrarlos a tiempo. Es como si yendo un grupo de amigos en varios coches a un concierto cada coche fuera lo más rápido que pudiera sin pensar en el resto de amigos. Hacer esto no sólo no sirve para nada porque el coche más lento es el que define a qué hora entrarán sino que provocan problemas de sincronización que hace que vayan aún más lentos.
Small Batches over Big Batches
Trabajar en pequeños lotes tiene una serie de ventajas: se entrega antes trabajo terminado y se obtiene feedback antes, se obtiene progreso basado en software funcionando más contínuo, emergen los problemas antes, se reduce el stock de trabajo sin entregar, se puede controlar mejor la calidad… ¿Qué más razones necesitas?
Pull System over Push System
Base del sistema Lean. No hacer más trabajo de lo que necesitan las fases posteriores. Por ejemplo, no enviar a testing más de lo que puede manejar, no planificar más historias de las que se pueden desarrollar, etc.. Y por supuesto no hacer más producto de lo que pide el cliente.
Emergence over Command and Control
Las empresas están aprendiendo a cambiar su estilo de dirección reduciendo capas de jerarquía. En lugar de intentar dirigir todo top-down, se deja espacio a los trabajadores a que seas sus propios managers y resuelvan ellos mismos los problemas. De este modo se puede conseguir que empresas grandes y pequeñas respondan rápidamente a los nuevos retos que requiere la sociedad digital.
Problem Focus over Solution Focus
Es facil empezar a pensar en soluciones teniendo en consideración solamente la superficie del problema, los síntomas. Sin embargo hay que analizar más el propio problema, buscando las causas raices del mismo mediante técnicas como 5Whys o Fishbone. Una vez encontrado y estando centrados en el problema raíz ya podemos buscarle soluciones.
Omission Error over Commission Error
Preferimos quedarnos cortos y tener la posibilidad de hacerlo bien en un segundo paso que hacer algo erroneamente y tener que corregir, arreglar, deshacer y volver a hacer. Lo segundo generá más retrabajo que lo primero. Por ejemplo, sacamos de alcance la parte de una historia de usuario que no está clara para desarrollarla más adelante con máyor información.
Products Development over Project Execution
Cuando desarrollamos software es facil centrarse en los requerimientos del proyecto (plazo, cliente, necesidades solicitadas,..) sin pensar que estamos realizando un producto que tiene una vida mucho más larga que el propio proyecto, que puede usarse por varios clientes o incluso que el mismo cliente puede solicitar cambios grandes en el futuro. Esto hace que debamos prestar atención a factores como la calidad de código, la adaptabilidad y una buena elección de la tecnología.

Presupuestar historias de usuario sueltas

En la charla del viernes 27 de Mayo sobre Scrum en mundos imperfectos salió el tema de cómo presupuestar a clientes basado en historias de usuario. En ese momento no tenía una pizarra y no pude explicar cómo pienso que es la mejor forma de hacerlo por lo que voy a dejarlo plasmado en este artículo.

Lo primero es conocer la capacidad del equipo de desarrollo en puntos de historias durante un sprint. Ese sprint puede ser de una a cuatro semanas.Lo ideal es tener ya la capacidad de unos cuantos sprints para tener una media. Para nuestro ejemplo, en Baylor Enterprises, vamos a decir que la capacidad de desarrollo son 45 puntos por un sprint de 3 semanas. No está nada mal 😉

SalidaPuntos

Lo segundo es conocer qué costes tiene la empresa en ese sprint. Estos costes son la entrada necesaria en euros para producir los puntos de historia. Para calcularlo sumamos sueldos de desarrolladores, administración, alquileres, electricidad,… Puedes sumar todos los gastos mensuales y hacer una regla de 3 para conocer los relativos al sprint. Para la Baylor Enterprises, mi multinacional, los gastos totales relativos a un sprint son 10.000 Euros.

Como imagino que no trabajas en una ONG, querrás que la empresa tenga beneficios, por lo que tenemos que aplicar un multiplicador a los gastos, y entonces obtenemos los ingresos deseados por sprint. Como CEO de Baylor Enterprises, decidí aplicar un multiplicador de 1,2 y así  obtener 12.000 Euros de facturación deseada por sprint.

Facturacion

Ya lo único que nos queda hacer es dividir ese beneficio deseado por sprint por los puntos de capacidad. Esa división nos dará los ingresos deseado por punto de historia. Como en Baylor Enterprises queremos una facturación de 12.000  € por sprint y generamos 45 entonces 12000/45 = 667 € por punto de historia. Ya tenemos nuestro número mágico.

Ya puedes presupuestar para los clientesuna historia de por ejemplo  2, 3 ó 5 puntos.  Sólo multiplicando el número mágico de beneficio por punto por la estimación en puntos realizada. Para un Epic con varias historias hay que sumar los puntos de todas las historias que constituyen el Epic.

Nota: Si llega un momento que se consigue subir la capacidad del equipo sin que lleve a un mayor gasto tenemos 2 buenas opciónes: Mantener el mismo precio consiguiendo más beneficio para la empresa en cada desarrollo o bajar el precio por punto de desarrollo consiguiendo mayor competitividad.

Charla sobre Scrum en mundos imperfectos

El viernes 27 de Mayo estuve dando una charla sobre Scrum en mundos imperfectos como parte de las actividades de AgileAlicante. Fué en las instalaciones de Sistel en Alicante, ofrecidas gustosamente a la comunidad para la celebración del evento.

Hablé de los requerimientos que tiene Scrum y que hacen que sea un framework hyperproductivo. Sin embargo estos requerimientos no son siempre fáciles de conseguir pero ello no quiero decir que cualquiera no pueda beneficiarse del agilismo y usar parte de lo que propone Scrum.

Hubo 15 apuntados (llenado el aforo) y como me gusta a mí, la conversación posterior fue muy interesante. Los asistentes comentaron sus dudas y problemas, sobre todo relacionados a la estimación y el presupuestar a clientes en base a proyectos, sprints o incluso historias separadas. Al no tener pizarra no puede explicar bien cómo propongo hacerlo pero haré un artículo en breve sobre ello.

Las diapositivas de la presentación puedes verlas aquí.

Quizá repita más veces el formato de mini-evento para que la comunidad AgileAlicante se conozca un poco más y que no quede solamente el University Day de Octubre.

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.

 

Sentándose un día con un desarrollador

En Lean cuando hablamos de Gemba, significa que los que están a cargo de un equipo o una empresa se paseen o estén donde realmente ocurre la acción. En las plantas de producción tradicionales estos lugares son los pasillos donde se elabora el producto. En desarrollo de software el Gemba sólo se puede realizar sentándose con el propio desarrollador.

Sin embargo, lo normal es que cuando un líder, jefe o responsable se acerca para ver cómo está trabajando el desarrollador, éste se ponga en modo inspección y empiece a explicar qué está haciendo y cómo lo lleva. Lo que ocurre en ese momento es el Principio de Incertidumbre, lo que se quiere estudiar cambia su comportamiento solamente por observarlo. También es normal que el líder, después de esta más o menos breve explicación se levante y vuelva a su puesto dejando que el desarrollador continúe para no interrumpirle más.

¿Es esto suficiente? ¿Se pueden saber así los problemas reales con los que se enfrenta y ayudarle a realizar mejor su trabajo? Mi respuesta es que no. Para hacer un autentico Gemba hace falta que el desarrollador trabaje como si no estuvieramos ahí. Para ello tenemos que ponernos en pair programming y sentarnos al menos un día completo con él para que «se olvide de las cámaras».  Trabajando juntos de este modo empezaremos a conocer sus problemas con el  framework, la arquitectura, lo que le cuesta un cambio de requerimientos, de datos de entrada, etc … . También en esas condiciones son en las  que podemos hacer coaching y enseñarle cómo organizar mejor el código, mejorar en TDD para desarrollar con mejor calidad y ayudarle a ser más productivo y ágil.

¿Cuánto tiempo hace que no te sientas un día completo con un desarrollador?

¿Incluyo el trabajo de documentación en la estimación de historia?

Esta es una duda que nos surgió este sprint y que seguro que surge en más de un equipo. Aquí viene mi análisis.

Opción 1) Si todo el trabajo del escritor técnico está incluido en la capacidad del equipo o es un porcentaje fijo y no  realiza historias aparte de documentación.

En este caso, todas las historias tienen su parte de documentación, más pequeña o más grande. En este caso, en circunstancias estables, el equipo al completo desarrolla a una velocidad estable. Es importante valorar bien la parte del manual en las historias de desarrollo porque podría pasar el no llegar a completar el número esperado de historias, ya que la parte del manual que corresponde se había infravalorado.

Si la documentación NO forma parte de la definición de DONE de la historia. Como se puede realizar la documentación en otro sprint, tendríamos que revisar el tamaño estimado de esa historia cuando no se va a realizar en ese momento la documentación.

 

Opción 2) Si sólo una parte variable del trabajo del escritor técnico afecta al trabajo del equipo.

En este caso recomiendo no incluirlo, ya que impediría obtener la capacidad de la parte del equipo que sí que aportan el 100% de su tiempo. Podría pasar que distintos sprints en las mismas condiciones se tuvieran velocidades distintas dependiendo de si tienen más o menos trabajo en el manual. Haría más difícil la planificación por la variabilidad de esta velocidad del equipo.

Si la documentación SÍ está incluida en la definición de DONE, recomiendo una doble estimación, la del tamaño del desarrollo y de la propia documentación. En este caso, el equipo que está en el desarrollo del producto puede planificar cuántas historias desarrollar en base a su velocidad como equipo y el escritor técnico tener en cuenta su aportación y tenerla en cuenta a la hora de planificar su propio sprint junto con otras historias propias.

 

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.

 

 

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.

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>