Después de varios años aplicando metodologías ágiles en nuestro trabajo, nos resulta muy enriquecedor compartir con nuestros clientes nuestra experiencia en el uso de las mismas.
En algunas reuniones que tuvimos con varios de ellos vimos cómo se entusiasmaban con la idea de empezar a implementar cambios pero se encontraban con las dudas y miedos lógicos de los equipos que quieren iniciarse en este campo. La complicación, en muchos casos, es tener que repartir las tareas diarias entre la resolución de incidentes de sus propios usuarios internos y el desarrollo planificado de mejoras o modificaciones en las aplicaciones.
Más allá de recomendar que en estos casos recurran "a su profesional de confianza" quien sabrá guiarlos en la adopción de nuevas metodologías, nos pareció interesante compartir un artículo publicado por Vikram Gupta en InfoQ, donde en un reportaje al Dr. Arne Roock - trainer y coach de Lean y Kanban (inglés) en it-agille de Alemania - twitter - nos presenta un "quick-start guide" sobre la implementación de Kanban.
Dejamos aquí un resumen del artículo en español y el link a la versión original - en inglés - del artículo Implementing Kanban in practice.
Decisión de cambiar
El punto inicial que el Dr. Roock destaca para los equipos que están evaluando empezar a implementar Kanban es que el equipo debe estar convencido y de acuerdo en la necesidad de cambiar. Agrego aquí que esa convicción es crucial para lograr cualquier cambio, independientemente de qué herramientas se estén evaluando. Además, según indica el Dr. Roock, el equipo debe acordar qué tipo de cambio quiere hacer- un cambio Revolucionario, es decir, algo radical que de vueltas todo "patas para arriba"
- o un cambio "Evolucionario", algo gradual, duradero y natural, que es para lo cual Kanban está pensado.
Objetivos
En el reportaje al Dr. Roock éste aclara que para tomar Kanban como base de un cambio "evolucionario", existen 3 objetivos principales que deberían lograrse:- Predictibilidad y mejoras en las entregas
- Visibilidad de las tareas a realizar, del trabajo completo
- Feedback Interno: observar, discutir y mejorar
Primeras consecuencias del cambio
Según la experiencia que el entrevistado ha tenido, algo normal en los equipos que se están iniciando con Kanban es que al tener a la vista la dimensión total del trabajo puede aparecer como primer preocupación la cantidad real de tareas que están "En progreso" (Work in Progress), es decir, tareas sin terminar. Este es un punto importante a partir del cual se puede comenzar a administrar mejor el trabajo.Otra cosa que suele suceder es que al mejorar en el punto anterior, las tareas se empiezan a acumular en la columna de "Testing", para lo cual no siempre la mejor solución es incorporar nuevos testers, reacción normal de los equipos con este problema. Tal vez mejorar la calidad del trabajo que llega a Test, automatizar algunas tareas o hacer que algunos desarrolladores hagan ese trabajo pueden ser soluciones alternativas con mejores resultados.
Herramientas
La mayoría de los equpos que trabajan con Kanban tienen por lo menos algunas de estas prácticas:
- Daily stand-up meetings o "reuniones diarias"
- Retrospectivas
- Kaizen meetings
Una de las herramientas que más destaca es la Pizarra (Kanban Board), que podemos ver en este ejemplo:
(imagen tomada de http://commons.wikimedia.org/wiki/File:Simple-kanban-board-.jpg)
Ante la pregunta sobre cuáles deberían ser las columnas que formen parte de esa pizarra, el Dr. Roock dice que éstas DEBERIAN REFLEJAR LA FORMA REAL DE TRABAJO. Con lo cual, en el caso de equipos de desarrollo, por lo menos se necesitan dos, una para Desarrollo y otra para Testing.
El riesgo de tener mucha granularidad en las columnas (muchas columnas) hace que la pizarra deje de ser transparente. Para explicar esto el Dr. Roock refiere a la llamada regla de 3x3: "si se está parado a 3 metros de la pizarra, en 3 segundos debería verse fácilmente cómo va el trabajo". No se puede leer el detalle de cada tarea, pero se puede ver dónde se están apliando los papeles y dónde la gente se quedó sin cosas para hacer. Cuantas más columnas tenga la pizarra, esa visión general empieza a perderse.
La importancia de las Tareas En Progreso (WIP)
En scrum se manejan, en general, una cierta cantidad de historias que, si no se terminan en el sprint en curso pasan al siguiente, teniendo en cuenta el tiempo restante y la velocidad a la que se mueve el equipo. En Kanban esto es diferente, aunque el principio es el mismo. En Kanban se deben poner límites a los WIP - establecer una cantidad de tareas - por columnas, por swim lane o por persona. El truco está en balancear la demanda contra la capacidad, no se debe aceptar más trabajo del que se puede completar.Cómo tratar las urgencias ("expedites")
Cualquier error que aparece en una aplicación que está en ambiente de Producción en Kanban es llamado expedite o urgencia. Si no se los atiende en forma inmediata el costo de dejarlos puede ser muy alto. En este caso una urgencia puede romper el límite establecido para los WIP. Este tipo de imprevistos debe resolverlo el equipo como tal y estar atento a la cantidad de urgencias que surgen para evaluar qué se puede hacer para achicar el costo de tener que afrontarlos.Expansión de la práctica
Al momento de decidir la implementación de Kanban el Dr. Roock aconseja "empezar con las cosas sobre las que el el equipo tiene control" que en general están más relacionadas con temas de desarrollo. No es aconsejable involucrar en la pizarra tareas que corresponden o dependen de otros equipos. No hay que tratar de evangelizar, la mejor manera de expandir la práctica, según el Dr. Roock, es lograr resultados y hacerlos visibles.La idea primaria de Kanban es empezar de a poco con lo que se tiene, de a un equipo por vez, para después ir evolucionando.
Uno de los principios más importantes al empezar con esta práctica es respetar los roles actuales, los procesos y responsabilidades. Es decir, mantener los títulos, roles y responsabilidades, al menos al inicio. A medida que se va avanzando en la práctica y los miembros van ganando confianza en la forma de trabajo, se pueden introducir otros tipos de cambios.
Equipos distribuidos
(imagen http://barcelona.agile-spain.org/page/2/)
Me pareció muy interesante este esquema que sugiere el Dr. Roock. Se trata de tener un responsable en cada equipo que refleje los cambios de la pizarra que se dan en el otro equipo. Esto suena a hacer "doble trabajo", y lo es, pero por otro lado ayuda a mantener a los eqiupos comunicados no solamente para la tarea de mover los tickets.
La idea de la pizarra física ya no es tan sostenible en el caso de tener más de 2 equipos distribuidos y con grandes diferencias horarias. Aquí sí recomienda usar herramientas electrónicas además de aumentar el "ancho de banda" en la comunicación entre los miembres de todos los equipos . El objetivo principal deber ser la construcción de confianza, cosa que es más difícil de lograr a la distancia.
Buscar horarios comunes y nunca dejar de hacer las reuniones diarias, aunque sea con un solo miembro que represente a alguno de los equipos, son otras de las cosas que aconseja el entrevistado.
Consejo final
Según el Dr. Roock, lo que se trata de lograr con Kanban es entender el trabajo en sí y la manera en la que lo estamos haciendo. Este es el valor básico que tiene Kanban. SIn tener una idea clara de estos puntos es muy difícl mejorar. Con lo cual, no hay que tratar de aplicar Kanban "según los libros" sino, tratar de entender por qué son necesarios los límites a los WIP, por qué es necesaria la transparencia en el trabajo a hacer, entre otras cosas que nos permite ver Kanban.Esperamos que este artículo sea de utilidad para aquellos que están empezando o evaluando la idea de un giro importante en la forma de llevar adelante el trabajo en equipo.
Para quienes quieran seguir entendiendo mejor Kanban, este otro artículo en español me pareció muy claro y merece ser leído Kanban como herramienta visual.
Twittear Seguir a @3p_ar
