Este marco da forma al mapa de situación propuesto por Scrum Manager desde sus tres principios(1) que consideran el ámbito de aplicación de Scrum, más allá de la gestión y seguimiento de proyecto, y se basa en principios de gestión antes que en la implantación de prácticas, y con carácter global para toda la organización.
Hoy no resulta fácil componer un criterio profesional solvente en gestión ágil de proyectos.
La sobrecarga informativa sobre nuevos modelos, marcos, procesos, métodos… en artículos, blogs, foros, cursos, charlas, webinars, libros, etc. puede terminar confundiendo más que aclarando.
Este post expone los conceptos subyacentes para comprender y situar mejor los diferentes modelos o metodologías.
Planifica el proyecto de inicio a fin. Estima el esfuerzo y tiempo necesario para su ejecución completa.
La meta es entregar el producto completo en el plazo y con el coste previsto
Tiene por objetivo la previsibilidad: conocer cuánto va a costar el proyecto (en tiempo y recursos) y gestionar su desarrollo para entregar en la fecha prevista con los costes previstos el trabajo encargado por el cliente.
Comienza el desarrollo del sistema con una visión general del objetivo y información inicial detallada suficiente para la primera entrega, pero no para todo el proyecto. A partir de ahí se van construyendo y entregando de forma continua partes parciales disponiendo en cada momento de la información necesaria para cada una.
Para mantener un ritmo de entrega continuo y sostenido, la gestión de proyectos evolutiva emplea dos patrones:
Avance incremental del proyecto basado en “pulsos de tiempo” o “timeboxing”.
Las entregas parciales (incrementos) se realizan en ciclos de tiempo breves (Sprints o iteraciones) de duración prefijada, normalmente entre una semana y un mes y medio. Al inicio de cada ciclo se estima cuánto trabajo se puede realizar y qué parte del proyecto se realizará
Entrega continua de funcionalidades al ritmo que se van produciendo, manteniendo un flujo continuo, sin tiempos muertos ni cuellos de botella.
Mejor que pensar en las diferencias entre scrum y kanban es considerar que la diferencia real estriba en gestionar el desarrollo constante del producto de forma iterativa o continua (¿cíclica o fluida?):
El fondo de la cuestión es: generar incrementos en ciclos temporales (“time-boxing”, “sprints” o como queramos llamarles) o de forma continua, funcionalidad a funcionalidad.
Porque al considerar que ésta es la diferencia, no nos perdemos en discutir si este método permite o no determinada técnica, o cómo debe llamarse al que combina técnicas de otros.
Estimaremos las tareas o no según creamos oportuno. Con el mismo criterio decidiremos si las registramos en una pila priorizada o en tarjetas adhesivas sobre un tablero. O si hacemos reuniones retrospectias cada x tiempo, al terminar una historia o una release. Si representamos el avance de un sprint con tarjetas adhesivas en lugar de con un gráfico burn-down, etc.
Con kanban, ¿hay que estimar las tareas?
¿En la reunión diaria hay que poner en la tarjeta kanban el esfuerzo que le queda?
¿Hay reunión diaria en kanban?
¿Puedes hacer scrum y cambiar una historia del backlog por otra a mitad de sprint?
¿Puedes ajustar el flujo con otras variables que no sean el WIP?
¿No estimar las tareas dilata la ejecución o reduce el efecto de la ley de Parkinson?
¿El rol de Scrum Master puede asumirlo lider técnico?
¿Hace falta un Scrum Master en un equipo ágil maduro y experimentado?
¿Hay roles en Kanban?
¿Podemos llevar varias cadencias kanban solapadas?
¿El sprint backlog es en realidad un WIP?
¿Puedo hacer scrum si el equipo no es multidisciplinar?
En definitiva la cuestión es si deberíamos considerar o no a scrum, a kanban o a cualquier otro, como métodos definidos, y por tanto actuar en nuestros proyectos según establezca el que hayamos adoptado.
Pues bien, es normal adoptar métodos definidos para gestionar sistemas de producción relativamente simples o de complejidad conocida y modelable, y sin embargo en la gestión de sistemas complejos resuelve con mayor solvencia el conocimiento tácito de un gestor experimentado. Se trata de la misma diferencia que hay entre la producción industrial y la producción ágil, trasladada a la gerencia: “preferimos las personas a los métodos”.
Con este criterio, hay dos posibles patrones de gestión: uno técnico, basado en la implantación del conocimiento profesional explícito, y otro experto, basado en el conocimiento tácito desarrollado con la experiencia profesional.
Para la gerencia técnica el fin es el método: conocerlo a fondo para implantarlo en la empresa.
Para la gerenica experta un método es un elemento más en su inventario de conocimiento y prácticas que conforman las piezas con las que la persona es capaz de construir la solución de gestión más adecuada a cada realidad.
Un gestor técnico estimará las tareas de los sprints de un proyecto si usa el “método scrum” y no las estimará si usa el “método kanban”.
Un gestor experto conoce ambos métodos, ha adquirido conocimiento de la experiencia en diversos proyectos, con distintos equipos y personas y sabe que según la combinación de tamaño del equipo, talento y motivación, la estimación puede ser contraproducente y favorecer la ley de Parkinson o por el contrario ser una buena práctica para combatir procrastinación o disipación. De igual forma un gestor técnico no contemplará la posibilidad de hacer sprints si usa kanban (y probablemente no comprenderá a quien lo haga).
En el último viaje a San Francisco conocí ingenieros tanto de Google y de Apple, como de pequeños proyectos y startup’s (La gente de Apple cuenta muy poquito por las cláusulas de confidencialidad de sus contratos).
Aunque son empresas y equipos diferentes,sus formas de trabajar tienen dos cosas en común, que prácticamente ni se las cuestionan:
La primera: sus prácticas y métodos dan forma a principios ágiles: Trabajan desde una visión conocida y compartida por todo el equipo, no desde requisitos detallados. Avanzan de forma iterativa e incremental en incrementos cortos y breves, tomando feedback continuo…
La segunda: Pasan de metodologías y dogmas ágiles.
Y es que fijarse en la forma (en las prácticas) y no en el fondo (en los principios) es mirar al dedo y no a la luna a la que señala. La agilidad sin flexibilidad acaba siendo un dogma paradógico: enseñar cómo deben organizarse los equipos “auto-organizados” (?). Es como aquello del “prohibido prohibir”
Me recuerda las conclusiones de Jared M. Spool en su conferencia de edui 2009:
Scrum es el término dado por Nonaka y Takeuchi al método de desarrollo de nuevos productos realizado con equipos reducidos, multidisciplinares, que trabajan con comunicación directa y empleando ingeniería concurrente, en lugar de ciclos o fases secuenciales.
Esta forma de trabajo logra niveles de eficiencia y valor en el producto superiores a los obtenidos con ingeniería secuencial y producción basada en procesos. En los 80, Nonaka y Takeuchi analizaron esta forma de producción, observando cómo trabajaban los equipos de las empresas tecnológicas que lograban mayores niveles de eficiencia y valor en sos productos(“New New Product Development Game“): Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.
Diez años más tarde Ken Schwaber presentó en OOPSLA (1995) la descripción de la implementación de Scrum para software que él empleaba en el desarrollo de Delphi.
Las implementaciones de Scrum para desarrollo de software se vienen enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken. Ahora es muy raro que alguien configure un campo de Scrum con los controles originales (paquetes, cambios, riesgos, soluciones…) el Backlog único ha evolucionado a Backlog de producto y Backlog de Sprint. También es habitual usar un backlog estratégico o “Epics” de producto. La evolución añadió a la reunión de revisión de sprint, otra de inicio; y más tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre, etc.
También la prácticas se han enriquecido. En 2001 apareció el gráfico burndown, más tarde empezó a ser habitual el uso de estimación de póker, luego tableros de control visual kanban…
Para dar una visión de retrospectiva, este es el “paper” de Ken Schwber presentado en 1995 su implementación de Scrum en OOPSLA: “SCRUM Development Process ” y este otro su artículo del mismo año “Living on the Edge” en el que describía su implementación de Scrum para Software.
Como adelanto, esta sería la traducción de la “metodología” y su fases:
Los primeros en observar diferentes implementaciones de SCRUM para el desarrollo de nuevos productos con alto rendimiento fueron Takeuchi y Nonaka (1) en Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, y Hewlett-Packard.
Coplien ha seguido y documentado un enfoque similar para el desarrollo de software en Borland, logrando la mayor productividad con C++ (1). Recientemente, Jeff Sutherland ha aplicado un enfoque más refinado de SCRUM en Smaltalk, y Schwaber en el desarrollo de Delphi.
…
Llamamos a este enfoque metodología SCRUM (véase Takeuchi y Nonaka, 1986) por el uso del término SCRUM en rugby –la formación cerrada que forman los delanteros para realizar el avance-
…
Scrum es una metodología para mejora y mantenimiento de un sistema existente o la producción de un prototipo. Se asume la existencia de diseño y código en su mayor parte orientado a objetos, basado en librerías y clases. SCRUM gestionará la reingeniería completa posterior de sistemas heredados.
…..
SCRUM comprende las siguientes fases:
Scrum Manager es una visión de scrum amplia y flexible: la original de Nonaka y Takeuchi, diferente a la implantación concreta de la Scrum Alliance.
Scrum Manager y Scrum Alliance no son lo mismo. Las características de flexibilidad, globalidad, y síntesis entre la agilidad y el conocimiento anterior (CMMI, 15504…) así como la difusión abierta, y condicionada a la calidad son aportaciones de Scrum Manager, o cuando menos, otra forma de interpretar los entornos de trabajo que Nonaka y Takeuchi llamaron “campos de scrum(1)” hace 25 años, y de compartirlo y difundirlo.
Convencidos de que es un error monopolizar el concepto de campo de scrum. De que se encorseta y se empobrece al trocar los principios básicos(2) por prácticas determinadas de sprints, backlogs y reuniones; y de que se podían aportar mejoras sustanciales a lo carísimo del modelo “comercial” de formación scrum, y al criticado certificado scrum master, Claudia y el que suscribre nos decidimos a no sólo hablar de alternativas, sino a construirlas.
Y como, “¿Cuál es la diferencia con Scrum Alliance?” o “¿Qué aporta?”, son preguntas frecuentes, cuando no críticas, 
estas son, contadas con brevedad y objetividad, las razones y mejoras aportadas con Scrum Manager:
1.- MEJORABLE: El enfoque de Scrum en el área de gestión de proyectos está bien, pero un “campo de scrum” implica también al área de programación o desarrollo de producto y también a la gerencia y dirección de la organización.
APORTACIÓN: Scrum Manager contempla tres áreas de conocimiento: Proyecto, Producto y Gerencia.
2.- MEJORABLE: La formación de Scrum Master sólo muestra las prácticas scrum de la Scrum Alliance.
APORTACIÓN: Scrum Manager presenta una síntesis de conocimiento entre procesos y agilidad: un enfoque objetivo mostrando la agilidad como antítesis de los procesos y las posibilidades que la síntesis de los dos conocimientos da a un gestor: como “criterios de gestión” en lugar de “recetas de actuación”.
3.- MEJORABLE: La formación de Scrum Alliance tiende a hacer olvidar el concepto original de campo de scrum y monopolizar scrum como las prácticas que ella misma define, empobreciendo las posibilidades de implementación de cada campo de scrum de la forma más adecuada a cada organización.
APORTACIÓN: Flexibilidad. Es un principio de Scrum Manager: adecuar las prácticas ágiles a la empresa, y no al revés.
4.- MEJORABLE: Los certificados de la Scrum Alliance se obtienen sólo por pagar los 1.000€ o más que vale el curso de 2 días. Puede acudir una persona sin entender inglés a un curso scrum manager dictado en inglés, no entender nada y sin ningún examen ni comprobación lograr la certificación Scrum Master.
APORTACIÓN: Un modelo enfocado en la formación, que permita incluso lo contrario: poder aprender y obtener un certificado acreditando que se sabe, de forma gratuita. (http://www.scrummanager.net/ok). Los certificados de Scrum Manager requieren un examen y actualmente un 20% de los presentados los suspenden y no obtienen la certificación.
5.-MEJORABLE : Servicios profesionales presenciales (franquiciados) centrados en el negocio, que exigen una tasa de franquicia para dar formación, generando como consecuencias: a)encarecimiento de los costes normales de un curso presencial, b) formadores más centrados en el negocio que en los resultados de los alumnos.
APORTACIÓN: modelo partnership de Scrum Manager sin canon de entrada ni cuota de mantenimiento. Concesión otorgada y mantenida por la valoración de calidad de los cursos (http://scrummanager.net/qa). Consecuencia: los formadores tienen como principal interés ofrecer formación de calidad, (la valoración media de los cursos presenciales actualmente es > 8 ) y el modelo garantiza que un formador que no ofrece calidad no puede trabajar con Scrum Manager.
6.-MEJORABLE: Modelo de certificación “parco”. Me explico: con dos días de formación, (aun suponiendo que sea de calidad y con examen) ya se es “ágil certificado” (?), sin marcar ningua apreciación de grado. Un profesional puede, además de conocer del scrum rígido de la Scrum Alliance, saber también de gestión de equipos, producto, recursos humanos, cultura ágil, o de prácticas de programación ágiles: integración continua, TDD, etc… Decir que una persona es Scrum Master, no es decir mucho de cuánto sabe de agilidad.
APORTACIÓN: Modelo de certificación con puntos de autoridad. La certificación Scrum Manager va vinculada a un grado de autoridad, que es proporcional a las áreas de conocimiento acreditadas.
He intentado sintetizar, y escribiendo un poco a vuela pluma. Seguro que me dejo cosas, pero creo que en conjunto este es el mapa general de razones y diferencias entre Scrum Alliance y Scrum Manager.
(1) “Moving the Scrum Downfield” – The New New Product Development Game. (Hirotaka Takeuchi and Ikujiro Nonaka. 1986)
(2) Built-in instability – Self-organizing project teams – Overlapping development phases – Multilearning – Subtle control – Organizational transfer or learnig.
En Scrum, a diferencia de los modelos de procesos, (CMMI, ISO15504…) la calidad del resultado no depende de la calidad el proceso, sino de las personas.
Si una pianola no suena… es una mala pianola.
No ocurre lo mismo con los pianos.
Implantar un campo de Scrum para un único equipo de 4 a 8 personas, que trabaja en el desarrollo de un único sistema es un “caso de libro”. No hay más que “copiar y pegar” las prácticas tradicionales de scrum de Ken Schwaber y Jeff Sutherland.
Pero en las empresas en las que nos movemos son bastante habituales los entornos multiproyecto, y “equipos” mínimos de tres, dos, o incluso una persona, y como flexibilidad consiste adaptar las prácticas a nuestra circunstancia y no al revés, os comento una práctica, de invención propia, que me está funcionando razonablemente bien, y que me ha dado por llamar “cajas kanban” o “kanban boxes”, que parece que inglés siempre mola más 
Mantiene los principios de “time boxing “, Seguimiento diario del avance, comunicación directa y visual, pero no hace dependiente el avance iterativo de ciclos temporales o “sprints” sino simplemente de nuevas funcionalidades, y es válida para entornos multi-proyecto, y también más aconsejable que el ciclo Scrum clásico para equipos muy pequeños (3 personas o menos)
¿Qué es una caja Kanban o una Kanban Box?
La descomposición y estimación de una funcionalidad o historia de usuario en las tareas que la componen, con un formato visual y simple (Kanban) y un indicador de avance diario ágil:
Y a partir de aquí, en función de cómo es nuestro equipo y los proyectos en los que estamos, vendría la gestión ágil: el arte de lo posible: cuál es el mayor valor que puede entregar el equipo de la empresa, con los criterios de prioridad de los responsables de producto, en el menor tiempo posible. Un ejemplo de uso:
1.- Las diferentes pilas de producto se priorizan entre los diferentes “propietarios”, y teniendo en cuenta la capacidad de desarrollo. del equipo total de la empresa…
2.- …se van “encajando” las historias más prioritarias, y por tanto las próximas que van a entrar en producción.
3.- Cada caja constituye en sí un incremento para construirse de forma completa y operativa, y queda encolado a la espera del próximo “slot” para entrar en desarrollo.
4.- Al entrar al tablero Kanban de desarrollo, se calcula la velocidad prevista en función de la personas(s) que se la han asignado y a diario se actualizan las tareas y los indicadores de avance: el teórico y el real.
Ej: la caja tiene un tamaño de 35 puntos. Se la han asignado 2 personas y por la media de velocidad en la empresa (p. ej.: 4 puntos persona /día) la velocidad prevista de avance serían 8 puntos /día. Cada día se borran 8 puntos de la barra de velocidad teórica, y se actualiza la barra de velocidad real con los puntos que realmente queden por hacer.
Para la comunicación en los puntos 1 y 2: priorización de la pila general de la empresa entre los diferentes propietarios, y descomposición y valoración de las tareas, respetad los principios ágiles de comunicación directa (socialización) y conocimiento y aportación conjunta del equipo a la visión del producto, estableciendo reuniones de características similares a las de inicio de sprint del ciclo clásico de scrum con los criterios de momento y participantes más adecuados según cada empresa.
Espero que os sirva de idea… Bienvenidas las sugerencias y mejoras!
Uno de cada tres programadores, o gestores que trabajan directamente en proyectos de programación usan metodologías ágiles, y las han incorporado por propia iniciativa, no por instrucciones “corporativas”. La implementación se produce “motu proprio” en equipos que trabajan en la misma planta o en el mismo edificio. La metodología más empleada, con mucho, es Scrum; y la mayoría de los que las emplean hablan bien de ellas, y creen que han mejorado la comunicación en el equipo, la velocidad en el cierre de versiones y la flexibilidad en el diseño.
Estas son las principales conclusiones de uno de los pocos estudios realizados sobre una muestra de técnicos, significativa (492 encuestas anónimas). Lo realizó Microsoft hace 2 años entre su personal de EE.UU, Europa y Asia, para analizar el grado de “contagio” de agilidad que estaba teniendo la empresa, la opinión de los técnicos y los resultados.
Prácticas ágiles empleadas
Grado de satisfacción por el uso de prácticas ágiles
