El libro de David Anderson, “Kanban,”, cautiva desde la primera página. Con ilustraciones, gráficos y conclusiones, la concisa biografía de Anderson revela la metodología Kanban para los aficionados à la gestión de proyectos saludables. La gestión de proyectos se vuelve intrigante cuando es narrada por el desarrollador del método desde una perspectiva en primera persona.
Acerca del Autor
Según el blog oficial de su empresa, David J Anderson está listado como el presidente de Lean Kanban Inc. Ha sido formador y consultor en gestión desde la década de 2000 y ponente y anfitrión de conferencias desde 2005. Anderson ocupó su primer cargo gerencial en 1991, lo que le brinda amplia experiencia para comparar honestamente Kanban con Waterfall, Agile, Scrum y otras metodologías de gestión de proyectos.
Él creó Kanban para elevar el nivel de trabajo intelectual y creativo. Los objetivos de Anderson incluían la entrega a tiempo, la alineación del trabajo con los objetivos establecidos y la gestión efectiva de las empresas modernas en su conjunto. Usando ejemplos de la vida real de Microsoft, Motorola y Corbis, explicó y demostró los principios, métodos e instrucciones para implementar Kanban en las empresas.
Contenido y Esencia del Libro
“Kanban: The Alternative Path to Agile” está escrito por la persona que inventó Kanban. El libro es tanto interesante como informativo, revelando la delgada línea entre la filosofía Kaizen (mejora continua), la metodología Lean (producción ajustada) y Kanban (un método para conservar recursos humanos y materiales).
Kaizen: Una filosofía y ética de las relaciones entre los trabajadores de fábrica y la administración.
Producción Lean: Un sistema de gestión de proyectos creado en Toyota para eliminar todos los desperdicios de tiempo y recursos en los procesos de la empresa.
Kanban: Un método de gestión de proyectos que limita el número de tareas simultáneas. Si hay personas, herramientas o tiempo limitados, Kanban ayuda a distribuir tareas y proyectos.
Significativamente influenciado por la Teoría de Restricciones, el libro de Anderson cubre extensamente los límites WIP, los cuellos de botella y la capacidad de determinar honestamente la carga máxima de trabajo por unidad de tiempo mientras se mantiene una calidad óptima.
La Teoría de Restricciones, desarrollada por el Dr. Eliyahu Goldratt, es una metodología de gestión para empresas manufactureras. El enfoque sistémico de Goldratt para identificar restricciones en las empresas ayuda a optimizar todo. Según la experiencia de Goldratt, la política de la empresa a menudo se convierte en la principal restricción.
Límite WIP (Trabajo en Progreso): El número de tareas que pueden estar abiertas simultáneamente.
Cuello de botella: Un punto en el flujo de trabajo donde hay una restricción grave en los recursos o capacidades. En los diagramas, se asemeja à la parte estrecha de una botella, con líneas que se ensanchan antes y después de tal situación.
Estereotipos sobre Kanban
Cuando escuchamos sobre Kanban, a menudo imaginamos una pizarra con notas adhesivas, un estereotipo perpetuado por los medios. Simbólicamente, hay una lista de tareas abiertas, en curso y completadas en la pared. Se pueden usar paredes virtuales y software de gestión de proyectos, donde se ingresan listas de tareas, prioridades y otros matices.
En esta metodología, Kanban no es solo una pizarra o notas adhesivas, sino un proceso de control y transferencia de tareas en la pared. Anderson explica quién mueve las etiquetas, por qué y cuántas se pueden mantener en la columna de “en progreso” y por qué limitar este número es importante.
Kanban no es una pizarra con notas adhesivas; las notas adhesivas son simplemente indicadores de la carga de trabajo.
Anderson desarrolló Kanban para evitar comenzar nuevos proyectos antes de completar los anteriores. Por ejemplo, si un desarrollador puede manejar de 3 a 5 tareas à la vez, solo puede asumir una nueva tarea después de haber terminado una.
Agile, Scrum y Kanban
Anderson cree que las metodologías Agile y Scrum son rígidas y estandarizadas. Desde su punto de vista, la gestión de proyectos debe ser individualizada para cada empresa. Por lo tanto, Agile y Scrum, con sus algoritmos de acción normalizados, están desactualizados, al igual que la clásica metodología Waterfall. Kanban, en cambio, se adapta a las características únicas de una empresa, lo que puede ser intimidante para los defensores de la metodología Agile.
Agile: Una metodología flexible que históricamente comenzó el desarrollo de software en el formato de lanzamientos de actualizaciones cada pocos meses. Iteraciones de unas pocas semanas para cada característica aceleran el desarrollo y reducen riesgos.
Scrum: Otra metodología flexible con iteraciones cortas y un control significativo sobre el proceso de programación. Hay sprints — segmentos de tiempo con tareas específicas para completar. Están estrictamente limitados. Hay pendientes — listas de tareas que son distribuidas por el propietario del producto. El propietario del producto no es parte del equipo de desarrollo, pero establece prioridades de tareas.
Waterfall: Un modelo clásico de gestión de proyectos con una secuencia estricta de acciones. A menudo se explica con la analogía de la construcción de un edificio desde los cimientos hasta el techo.
Calidad Literaria
Las reseñas del original en inglés de “Kanban” de David Anderson son similares: todos mencionan que el autor explica:
- Cómo se creó el método, por qué y con quién se desarrolló.
- Quién se beneficia de él y quién lo necesita absolutamente.
- Cómo aplicarlo para obtener resultados.
“Kanban” está escrito en la manera de una buena literatura de negocios. Incluye conclusiones al final de cada capítulo, y todos los capítulos abordan individualmente cada posible pregunta que un lector podría tener en un orden lógico.
El capítulo 20, “Gestión de Problemas y Reglas de Escalación,” me impactó en particular. Distinguir un cuello de botella de una tarea bloqueada es obvio, pero ¿con qué frecuencia confundimos uno con el otro y tratamos de salir de un callejón sin salida? Si una tarea no puede ser resuelta ahora, aborda su causa raíz. Aquí hay una cita del libro:
“Una tarea bloqueada de hecho forma un cuello de botella que restringe el flujo. Sin embargo, no es lo mismo que el cuello de botella descrito en el Capítulo 17 porque no es una restricción de recursos y no es un recurso que espera acceso. De manera similar, un corcho no es un cuello de botella. Para restaurar el flujo de líquido de la botella, simplemente retira el corcho.”
Veredicto
Definitivamente vale la pena leer, será beneficioso para:
- Empresarios que luchan por gestionar tasas de producción en aumento.
- Directores de empresas de TI insatisfechos con Scrum.
- Gerentes senior y líderes de equipo.
- Marketeros obsesionados con los KPIs pero inseguros de su efectividad.
- Equipos de startups que necesitan hacer todo bien desde el principio sin “reinventar la rueda,” ya sea en código, vida o proyectos.