jueves, 28 de enero de 2016

¿Dónde situar y qué son Scrum, Kanban, Agilidad, Lean y Lean IT?

En mis cursos hay una diapositiva heredada que muestra un gráfico sobre el que doy respuesta a esta cuestión.

El gráfico muestra como se solapan: Lean viene de la manufactura Lean japonesa y Lean IT es una extensión posterior para el desarrollo de software. Agile (Agilidad) nace y aglutina prácticas que se basan en el Manifiesto Ágil, sus valores y principios interseccionan con Lean y Lean IT. Kanban es una herramienta nacida en la Manufactura Lean, herramienta que Agile y Lean IT han adoptado, y Scrum, que es un marco basado en el Manifiesto Ágil, incorpora Kanban con su tablero o Scrumboard.

Lean

Lean es una filosofía de gestión empresarial que proviene de la manufactura Lean con una serie de principios para lograr calidad, velocidad y alineamiento con el cliente. Lean habla de eliminar todo lo que no añada valor y trabajar solo en aquello que tenga valor y sea necesario hacer a tiempo en ese momento. Pone énfasis en el sistema como un todo, tener la perspectiva del todo para comprender el sistema y poder optimizarlo.

Lean IT

Lean IT es la extensión de la manufactura Lean que aplica sus principios a las Tecnologías de la Información (IT). Se centra especialmente en comportamientos y actitudes, y da una importancia vital a la mejora continua orientándola hacia el cliente y buscando la máxima eficacia. Aunque los principios de Lean estén bien establecidos, su extensión a IT está en sus inicios. Mary y Tom Poppendieck establecieron en 2003 los principios (eliminar el desperdicio, construir con calidad, compartir conocimiento, diferir el compromiso, entregar rápido, respetar a las personas y optimizar el todo).

Agile (Agilidad)

Agile se refiere a todas aquellas prácticas y marcos de trabajo que se basan en los postulados y principios del Manifiesto Ágil. El Manifiesto fue una reacción en 2001 a las metodologías tradicionales que por su pesadez paralizaban proyectos, para enfocarse en lo que realmente hay que hacer, teniendo en cuenta que los realizan personas como trabajadores de conocimiento. Cubre métodos de desarrollo en los que requisitos y soluciones evolucionan a través de la colaboración y equipos autoorganizados y multifuncionales. Promueve la planificación adaptativa, el desarrollo evolutivo, la entrega continua, la mejora continua, y abraza el cambio para absorberlo de forma flexible y rápida.

Kanban

Kanban es una herramienta de gestión visual creada por Taiichi Ono que controla de modo armónico la fabricación de sólo los productos necesarios en la cantidad y tiempo necesarios, es uno de los pilares del sistema de producción de Toyota. Aplicado a TI es un sistema de mejora de procesos basado en un sistema de arrastre con restricciones al trabajo en proceso y visualización del flujo, con el que se puede construir un producto de software, gestionar un sistema de mantenimiento o incidencias y en general gestionar de forma visual cualquier flujo de trabajo.

Scrum

Scrum es un marco de trabajo creado en 1993 por Jeff Sutherland y presentado en su primera versión en 1995 por Ken Schwaber en la OOPSLA'95 (Object-Oriented Programming, Systems, Languages & Applications), describe un proceso de estrategia de desarrollo incremental basado en los principios del Manifiesto Ágil. En el proceso se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección por Jeff Sutherland tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.
Las tres dimensiones críticas variedad, variabilidad
 y el volumen determinan cuál es el enfoque
(Agile o Lean) mas adecuado
¿Cuál es el enfoque más adecuado a aplicar en una situación dada?

Como hemos visto, Agile significa un alto nivel de maniobrabilidad y la característica clave de una organización ágil es la flexibilidad. No debe de confundirse con Lean, que trata de hacer más con menos y que implica un enfoque just-in-time con "cero inventario" y la eliminación de los desperdicio.

Se necesita Agile en entornos poco predecibles, donde la demanda es volátil y la variedad/variabilidad es alta. Agile puede ser definido como la capacidad de una organización para responder con rapidez a los cambios en la demanda, tanto en términos de volumen y variedad. Lean tiene sentido cuando la demanda es predecible, la variedad/variabilidad es baja y el volumen es alto.

domingo, 24 de enero de 2016

¿Qué tal Redmine como software para gestionar proyectos con Scrum?

Recientemente me he incorporado como Scrum Master en un proyecto en el que el equipo está distribuido en tres localizaciones distintas de Sevilla y Madrid. Como herramienta para gestionar las pilas, las tareas, el tablero de Scrum y el gráfico burndown decidimos probar con Redmine. Esta es una herramienta para la gestión de proyectos que incluye un sistema de seguimiento de tareas junto con seguimiento de incidencias para el que Emilio González ha creado un plug-in para Scrum. Entre las características del plugin se puede leer:
Lo que no me gusta:
  • Las historias de usuario de la pila de producto, al igual que las tareas, tienen demasiada información, por ejemplo incluyen horas estimadas, horas pendientes y horas restantes o faltantes... hay mucho desperdicio desde el punto de vista de la agilidad. Se nota que el plugin se acopla a un sistema de gestión de proyectos pensado para el control. Estoy convencido de que Redmine madurará mucho en lo que respecta Scrum en los próximos años y que estas cosas se refinarán.
  • El tablero de Scrum, aunque está muy bien resuelto, se corta con más de 3-5 historias y por tanto requiere de scroll. Esto reduce la visión agregada del mismo y reduce la visión del todo y del avance del sprint.
Refinamiento de la pila de producto en Redmine
Lo que me gusta:
  • Tanto la pila de producto (derecha en la imagen inferior) como las pilas de sprint (izquierda imagen inferior) se muestran en una única pantalla incorporando la funcionalidad de drag&drop para priorizar y mover historias entre una y otra pila. También permite dividir la pila de producto en releases, como se puede ver. Todo ello resulta en una gestión de pilas muy ágil y user-friendly.
Pila de producto y sprints
  • Se trata de un tablero de Scrum muy bien resuelto, permite personalizar los estados (columnas), asignando automáticamente esos estados a historias y tareas que recorren el tablero.
  • A diferencia de iceScrum el tablero permite que cualquiera con los privilegios suficientes pueda mover los post-its, haciendo posible así su uso para las reuniones diarias.
  • Cuando se terminan todas las tareas de una historia de usuario esta se mueve automáticamente a la columna terminada.
  • En la parte superior tiene un carril de impedimentos a los que se puede asociar una o varias tareas.
  • Permite asignar colores a los post-its según la persona asignada, haciendo así más fácil la lectura de quién está haciendo qué.
Tablero Scrum y burndown
  • El gráfico burndown permite seleccionar las horas a representar, aunque las únicas útiles son las horas restantes o faltantes, que deben ser resultado de las reestimaciones de lo que queda por tarea en curso previas a cada reunión daria.
Para la situación del proyecto en que participo este software está dando buenos resultados, las reuniones diarias, previa reunión presencial para establecer confianza, funcionan muy bien. Dada su naturaleza deslocalizada las cosas ocurren más lentas, una típica reunión diaria dura entre 10 y 15 minutos, pero tengo admitir que el resultado está muy en la línea de una reunión presencial.

Nicolás Martín, un asistente a mi cursos, propone el plugin para Redmine Agile Plugin, que no solo cubre Scrum sino también Kanban, no sólo tiene tableros, sino también entre otras burndown y diagrama de flujo acumulativo.
Burndown con Agile Plugin, este es configurable para que los fines de semana cuenten como no laborables y la linea ideal se mantenga plana, en este caso representa sábado y domingo. ¡Gracias a Nicolás por la captura!

lunes, 18 de enero de 2016

¿Cómo han de ser los directivos de una compañía ágil?

El autor posando como líder lean-ágil :-)
Para responder a esta pregunta me viene como anillo al dedo haber pasado por un curso de SAFe reforzado por uno de Management 3.0, ya que en ambos se describe, entre otros, cuáles han de ser las habilidades de los directivos para la gestión ágil de una compañía.

"Un directivo ágil no debe de crear reglas,
debe de crear restricciones"

El perfil de directivos ágiles ha de ser el de líderes con habilidades sociales que desarrollan a las personas a su cargo y están focalizados en el pensamiento sistémico, donde estos marcan la estrategia y son resolutores de problemas, piensan y actúan a largo plazo, toman la perspectiva del sistema desde el todo y son removedores proactivos de impedimentos. Una de sus funciones principales es ser buenos comunicadores para comunicar los problemas que hay que resolver y el porqué. En definitiva, como comenta Cristina Ramos en su artículo sobre los decálogos del líder ágil, un facilitador del flujo.

"Sólo dirección puede cambiar el sistema,
si la dirección no tiene mentalidad ágil, la compañía no ejecutará agilidad"

Lean Thinking nos dice que los directivos lean deben de tener el compromiso de invertir continuamente en sus empleados y promover una cultura de mejora continua, su esencia es:

"Building people, then building products"

Y recordemos a Carl Buechner:
"La gente olvidará lo que digas y hagas,
pero nunca olvidarán como les has hecho sentir"

Sólo los directivos pueden hacer posible el cambio:
Responsabilidades de los directivos ágiles para que Scrum
cumpla con CMMI nivel 5 - diapositiva de Jeff Sutherland
Desbloquear la motivación intrínseca de los trabajadores es comprender que las personas que ficha una empresa vienen motivadas y simplemente se trata de poner el foco en crear un entorno que los mantenga motivados. Una clave está en hacer que las personas piensen y se focalicen en problemas reales, y darles el espacio para que los resuelvan. Hay que confiar en las personas, eso las hará autónomas y motivadas. Junto a la autonomía y a la autoorganización hay que darles los recursos necesarios para que puedan realizar su trabajo, y aire para poder absorber la variabilidad y las sorpresas de su día a día.

Descentralizar la toma de decisiones resulta en centralizar las decisiones estratégicas y poner la toma de las demás decisiones, que suelen ser frecuentes, allí donde está la información. La toma de decisión impacta directamente en el flujo de trabajo, toma de decisión en el lugar equivocado provoca demora y por tanto va en contra del flujo.

Y ligado con esto, resaltar que en agilidad la base para determinar el sueldo o salario de los trabajadores debe de ser según la capacidad de toma de decisiones, y no según la capacidad para cumplir ordenes.

Miguel, mi jefe dijo un día a un un gerente de la empresa que estaba cocheando:

"No me importa lo que haga Alex,
lo que me importa es que siempre esté allí donde más valor aporte"

sábado, 16 de enero de 2016

¿Cómo se va refinando la pila de producto?

Refinamiento: estimar, añadir, repriorizar, retirar y dividir
Como parte del flujo continuo de análisis de las historias de usuario, Scrum se complementa con la reunión de refinamiento para mantener actualizada la pila de productoEs una reunión paralela al sprint, propia del Propietario del Producto, en la que este junto con el equipo trabaja en el refinamiento de la pila de productoSu objetivo es garantizar que, antes de comenzar el siguiente sprint, las historias de usuario susceptibles de entrar estén "listas" (DoR) para ser tratadas en la próxima reunión de planificación de sprint, es decir, con un nivel de detalle y una estimación de esfuerzo suficiente para que el equipo pueda comprometerse. 

A pesar de no formar parte del proceso formal de Scrum, es una reunión en la que Ken Schwaber recomienda al equipo reservar un cinco por ciento de cada sprint para esta actividad. Que el equipo dedique un tiempo por sprint a esta actividad y alejándolos de la codificación por un rato, permite que piensen en algo diferente y les ayuda a su regreso a centrarse más efectivamente en sus tareas. Por otro lado las conversaciones sobre las historias próximas es una forma muy efectiva de hacer partícipe al equipo de los problemas que habrán de resolver en la próxima reunión de planificación de sprint, dándoles así margen para resolver posibles impedimentos y dependencias.

Los objetivos de la reunión son que:
La reunión puede implicar cualquiera de las siguientes actividades:

miércoles, 6 de enero de 2016

¿Qué métricas tomar en Scrum?

La información es la materia prima para la toma de decisiones y la que puede ser cuantificada nos puede dar criterios objetivos para la gestión y el seguimiento, por tanto métricas bien elegidas nos permiten proyectar y tomar decisiones. Pero hay que elegir muy bien las métricas, no son un fin en si mismas, son costosas y añaden burocracia. Cada medida debe de tener un porqué, aportar valor o significar pérdida de valor si no se toma y aplica.

Las personas ajustamos nuestro comportamiento a las métricas que se utilizan para medir el sistema con el que trabajamos, ajustamos de forma automática nuestros esfuerzos para maximizar esas métricas. Por tanto hay que pensar muy bien que métricas tomar incluso desde el punto de vista de la naturaleza humana, por ejemplo:
  • Si premiamos a nuestros programadores por el número de lineas de código obtendremos códigos largos y poco optimizados, con más posibilidad de bugs y menos mantenibilidad.
  • Si penalizamos a nuestros programadores por el número de bugs generados obtendremos una muy baja productividad, ya que la mejor forma de no generar bugs es no escribir código.
La velocidad, medida por excelencia:
estimar tamaño, medir velocidad y derivar duración
En Scrum la métrica por excelencia es la velocidadla medida de la capacidad del equipo por sprint, por tanto es la medida con la que el equipo entrega valor. Es una métrica alineada con el Manifiesto Ágil en el sentido de que la mejor medida de avance es el software funcionado, y esta se mide una vez entregado el incrementoLa velocidad no puede predecir el futuro, sólo dice lo que ya ha sucedido y ofrece una sugerencia de lo que se puede esperar en el futuro. Desde el punto de vista de la naturaleza humana es un métrica que crea un impulso sano en poner el esfuerzo en la mejora de la velocidad. Pero también aquí hay que tener cuidado, la velocidad es propia de cada equipo y específica para ese producto/entorno/cliente concretos, nunca debemos de comparar velocidades entre equipos ni hacer benchmarking con la misma.

Otras posibles métricas de un equipo ágil, que se deben de recoger al final del sprint, cuando el equipo haya finalizado y entregado el incremento, son las recogidas en las métricas de SAFe:

Funcionales
Calidad

domingo, 3 de enero de 2016

¿Cómo hacer que los equipos Scrum autogestionen sus dependencias?

En productos que requieren varios equipos trabajando en paralelo es necesario gestionar las dependencias entre los trabajos que realizan los mismos. 

La pila de producto de este tipo de proyectos grandes suele tener suficientes epics e historias de usuario con un alto grado de certidumbre que permiten planificar varios sprints. Con el nivel de granularidad que tienen seguramente presenten pocas dependencias entre si, hecho muy deseable ya que eso permite gestionar la pila de producto más fácilmente. Pero cuando llega el momento de la planificación de release o la planificación de sprint, en el último momento responsable, cuando se realiza la descomposición en historias más pequeñases cuando aparecen las dependencias.

Tratándose de planificaciones con equipos trabajando en paralelo son necesarios eventos tipo Release Planning de SAFe o The Big Room de Mike Cohn. Este tipo de eventos son eventos en que están presentes todos los equipos y en que planifican de forma conjunta la próxima release o los próximos sprints.
Tablero de release con las dependencias visibles
Cada equipo elige una serie de epics y/o historias de usuario de un tablero con la parte prioritaria de la pila de producto a construir, y luego los descompone junto con el propietario de producto en historias de usuario estimables y acometibles en sprints. Estas las planifican para los próximos sprints identificando riesgos y resolviendo dependencias inter-equipos de forma verbal negociando con los equipos involucrados.

Cuando se identifica una dependencia uno de los miembros busca el equipo que va a construir la historia de la que son dependientes y se pone de acuerdo con este para que ambos planifiquen las dos historias dependientes en sprints secuenciales. De esta forma el equipo con la historia con dependencias da prioridad a la misma y toma el compromiso de finalizarla en el sprint planificado.

Finalmente los equipos trasladan sus historias planificadas a un tablero de release y hacen visibles las dependencias mediante colores y cuerdas entre historias. En la imagen del ejemplo de arriba las historias naranjas son historias con dependencias hacia ellas, y las amarillas historias de las que no depende ninguna. Es muy importante que cuando se establezca una dependencia con una cuerda estén presentes los miembros, o al menos uno, de ambos equipos, ya que establecer una dependencia de forma unilateral hace que no se establezca el compromiso necesario del otro equipo.