laberintoLeo en el libro "Kanban y Scrum, obteniendo lo mejor de ambos de Henrik Kniberg y Mattias Skarin" o en "Kanban" de David J. Anderson, cosas como:

  • Scrum prescribe roles, kanban no. Scrum trabaja con iteraciones de tiempo fijo, kanban con cadencias (simples, múltiples o dirigidas por eventos).
  • Scrum limita el wip por iteración, kanban limita el wip por estado del flujo de trabajo, los equipos de scrum son multidisciplinares, en kanban pueden ser de especialistas.
  • Scrum no permite cambiar tareas del sprint, en kanban la tarea puede alterarse hasta entrar en flujo. En scrum la pila de producto debe tener la longitud de al menos un sprint. En kanban se debe atender al ritmo de arrastre de las tareas.
  • Es scrum se deben estimar las historias y las tareas, y calcular la velocidad Kanban no mide tareas ni velocidad.
  • Scrum necesita una pila de producto priorizada. Kanban la siguiente historia del cliente.
  • Scrum prescribe reuniones diarias, kanban no.
  • Scrum emplea diagramas burndown, kanban no.
  • Los tableros scrum se resetean al final de cada sprint.

etc.

La sensación de orientación con tanta sobrecarga informativa (y desinformativa) en artículos, foros, webinars, libros, posts... para cosas tan simples me recuerda a la que me quedaba de crio después de girar vueltas y vueltas mirando al cielo.

Y es que al final se nos va la atención de lo que tenemos que conseguir, y nos centramos en cómo lo tenemos que hacer, olvidándonos de que en agilidad el habíto no hace al monje, y el éxito no depende del principio de ingeniería de procesos “la calidad del resultado depende de la calidad del proceso”.

Con lo sencillas que son las cosas simples:

Gestión de proyectos predictiva - evolutiva

Hay dos patrones en gestión de proyectos (por la forma de entrega del resultado): predictivo y evolutivo (que no ágil). Y la diferencia es simple: el predictivo conoce al principio todo lo que el cliente necesita, planifica la ejecución, predice cuando lo va a entregar y cuánto va a costar. Trabaja para cumplir la previsión y entregar el producto de forma completa.
El evolutivo comienza construyendo y entregando una parte mínima y útil para el cliente lo antes posible, y sobre ella desarrolla el producto de forma continua.

Agilidad e ingeniería concurrente

La gestión de un desarrollo evolutivo puede a su vez:

  • Basar la calidad del resultado en ingeniería de procesos y organizar el trabajo con criterios técnicos de gestión (rol de gestor de proyecto).
  • Basar la calidad del resultado en el conocimiento tácito de las personas que trabajan de forma autoorganizada.

En el segundo caso estamos hablando de aplicar agilidad, y en el primero ingeniería concurrente.

Por otra parte la gestión evolutiva (tanto si se basa en agilidad como en ingniería concurrente) puede:

  • Emplear ciclos de entrega breves (time boxing, sprints o iteraciones) entre una semana y uno o dos meses. Para gestionar el avance continuo en pequeños ciclos se usan técnicas que estiman cuánto del trabajo que el cliente va definiendo se puede realizar en cada ciclo o sprint, evitanto así desfases largos y detectando rápidamente posibles problemas y retrasos (prácticas scrum).
  • Regular un flujo de trabajo continuo sin tiempos muertos ni cuellos de botella, que permite recibir las descripciones de las partes del producto con la misma cadencia, e ir entregándo el resultado (prácticas kanban).

 

Scrum - Kanban

laberinto de modelosSi entramos en el laberinto de modelos, marcos y métodos definidos buscando agilidad (y no ingeniería concurrente) acabamos con más dudas que soluciones.

"Si en mi equipo quiero usar kanban pero tengo que (o quiero) estimar las tareas para registrar la velocidad por razones organizativas de mi empresa, o porque se me ha ocurrido que..."

"Si mi empresa gestiona proyectos simultáneos con una organización de oficina de proyectos y encaja mejor el establecimiento de roles, pero sin embargo quiero trabajar con kanban en lugar de con scrum... ¿debería hacer scrumban?. Y eso ¿qué es lo que es? ¿O lo que voy a hacer es scrumbut y soy un mal gestor?."

laberinto de modelosSi hacemos "reset" a esta inercia de aprender modelos, para no pensar que ahora además de los de procesos y gestión predictiva (ISO 15504, Moprosoft, CMMI, PMI, Spice..-) hay otros que son para gestión ágil.

Si no consideramos scrum como método sino como prácticas para gestionar incrementos basados en "timeboxing".

Si consideramos que Kanban es lo que es (o lo que originalmente era): Aplicación de información o gestión visual en el propio en torno físico en el que se trabaja: una técnica desarrollada y empleada por la manufactura Lean.

Desaparecen las paredes del laberinto, y con ellas la búsqueda equivocada (para quien quiere agilidad y no ingeniería concurrente) del camino modelo correcto.

Se podría decir algo como que la ingeniería concurrente prefiere el conocimiento explícito de los modelos al tácito de las personas, y funciona lo de "implantando este método daré al cliente lo que necesita" y con la agilidad ocurre al contrario.

lean agilidad ingenieria concurrente

Bookmark and Share

Escribir un comentario


Código de seguridad
Refescar