Los tres conceptos básicos que hay detrás de: cascada, agilidad, agilismo, scrum, kanban, cmmi, pmi acp, lean, etc.

Desde los años 80 se han desarrollado tantos modelos de procesos, marcos y prácticas de trabajo para mejorar la calidad y la eficiencia en los proyectos de software, que resulta útil trascender las etiquetas y llegar a la base de los principios que subyacen, y las estrategias con las que los desarrollan; de forma que con tres conceptos (desarrollo, trabajo y conocimiento) y dos modelos de gestión (predictiva y evolutiva) se despeja y simplifica el aparente laberinto de modelos de procesos, marcos o prácticas de trabajo a los que nos referimos: CMM-SW, CMMI, PMBOK, DSDM, Crystal, ISO 15504, RUP, XP, Scrum, ITIL, ASD, PRINCE 2, LEAN, KANBAN, TDD, etc..

 

diagrama_conceptos

Los conceptos que se combinan en los distintos marcos y estrategias son:

1.- Desarrollo

desarrollo

  • Completo: La descripción de lo que se desea obtener está disponible al inicio del proyecto, es completa y detallada, sirve de base para estimar el plan del proyecto: tareas, recursos y agenda de trabajo. Durante la ejecución se gestiona su cumplimiento.
  • Incremental: La descripción de lo que se desea obtener no está disponible de forma completa y detallada al inicio: se complementa y evoluciona en paralelo al desarrollo, que genera el resultado de forma incremental y que se puede gestionar con dos tácticas diferentes:
    • Desarrollo incremental continuo: Empleando técnicas para lograr y mantener un flujo continuo de desarrollo de funcionalidades o partes del producto que entrega de forma continua al cliente.
    • Desarrollo iterativo: El marco de producción emplea técnicas de tiempo prefijado o timeboxing para mantener la producción de incrementos del producto de forma cíclica y continua. Este es el marco de producción empleado en scrum estándar, que define como sprint a cada iteración de desarrollo al final de la cual se produce un incremento del producto.

2.- Trabajo

trabajo

  • Secuencial (cascada): Secuencia las tareas en fases, cada una de las cuales comienza al terminar la anterior y con el resultado que se ha obtenido en ella. El ejemplo más habitual es el ciclo de cascada definido en Ingeniería del software con las fases de requisitos, análisis, diseño, codificación, pruebas e implementación.
  • Concurrente: Solapa en el tiempo los diferentes tipos de tareas. Siguiendo con el ejemplo de ingenería de software, la definición de requisitos, el análisis, la codificación y el despliegue del resultado se realiza y revisa de forma simultánea y continua.

3.- Conocimiento

conocimiento

Principal conocimiento empleado,  protagonista de la calidad del resultado.

  • El conocimiento o know-how protagonista de la calidad del resultado se encuentra en mayor medida en los procesos y la tecnología empleada. “La calidad del resultado depende de la calidad de los procesos empleados“.
  • El conocimiento o know-how protagonista de la calidad del resultado se encuentra en mayor medida en el conocimiento tácito de las personas que lo consltruyen.

 

Gestión predictiva

gestion_predictivaModelo de gestión de proyectos cuyo objetivo es ofrecer resultados predecibles: desarrollar el producto previsto en el tiempo previsto e invirtiendo los recursos previstos. Emplea una estrategia de desarrollo completo con prácticas de planificación tradicional los principales referentes en el desarrollo de conocimiento para este tipo de gestión son PMI e IPMA y los modelos desarrollados (CMMI, ISO 15504, SPICE entre otros) emplean ingeniería secuencial y producción basada en procesos.

 

Gestión evolutiva

gestion_evolutivaModelo de gestión de proyectos cuyo objetivo es la entrega en el menor tiempo posible un producto mínimo viable, e incrementar su valor de forma iterativa y continua. Emplea una estrategia de desarrollo incremental, que puede obtener con tácticas iterativas o de mantenimiento de flujo continuo, y un modelo de trabajo de fases solapadas. Puede emplearse con producción basada en procesos (ingeniería concurrente) o con producción basada en personas (agilidad).

Es importante esta distinción porque sin ella se generan situaciones confusas que llegan a considerar agilidad a la simple aplicación de un marco de desarrollo estándar de scrum (ciclo de incremento iterativo con roles y artefactos definidos), o al simple uso de técnicas de gestión visual kanban para mantener un flujo continuo de tareas.
Safe Creative #1307145429864

Scrum Manager y Scrum Alliance: dos estilos diferentes de hacer Scrum

dos_estilos_de_scrum_scrum_manager_590

 

Las dos iniciativas (Scrum Alliance y Scrum Manager) desarrollan y difunden marcos de Scrum para trasladar al sector TIC la forma de trabajo ágil, iterativo e incremental identificada en 1986 por Nonaka y Takeuchi (1) en la industria de manufactura electrónica y tecnológica, y que bautizaron como “avance en campos de scrum” por la similitud con el avance en formación “scrum” de los equipos de rugby.

Y cada iniciativa lo aborda con un estilo diferente.

El modelo de Scrum Alliance (Scrum Master) se basa en prácticas concretas que se deben realizar en un marco definido de artefactos, roles y reuniones. El avance evolutivo del trabajo se realiza a través de iteraciones (“sprints”).

El modelo Scrum Manager se basa en los principios de Scrum(4) Relativiza por tanto la importancia de las prácticas y permite flexibilizar las implementaciones adecuando el modelo de prácticas y distribución de roles/responsabilidades a las características de cada organización. El avance evolutivo del trabajo, por el carácter flexible del modelo, funciona tanto con iteraciones como con desarollo continuo,(2) según las circunstancias de cada proyecto.

La flexibilidad del modelo Scrum Manager requiere mayor experiencia y madurez profesional de las personas que trabajan con él (Se basa más en el valor de las personas que en las prácticas empleadas).

Estas iniciativas ofrecen también estilos diferentes de difundir el conocimiento de Scrum.

La diferencia entre estos dos enfoques nos permite considerar cuál resulta más adecuado en cada caso: si Scrum Master(3),  o  Scrum Manager en función de los diferentes criterios profesionales y las circunstancias de cada proyecto.

(1) New New Product Development Game, Takeuchi & Nonaka 1986.

(2) Incremento iterativo o continuo.

(3) El modelo Scrum Master lo ofrecen tanto scrumalliance.org como scrum.org, que es la escisión en 2008 de la Scrum Alliance de Ken Schwaber por desavenencias económicas. El modelo Scrum Manager se ofrece en scrummanager.net

(4) Scrum Manager contempla el concepto de espiral continua de conocimiento de Nonaka y Takeuchi (Hitotsubashi on Knowledge Management), sin fijar por tanto un marco de prácticas definido, sino una evolución y adaptación desde los principios de la agilidad.

Gestión ágil en toda la organización (Scrum Management)

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.

 

Estructura Scrum Management

  Continue reading “Gestión ágil en toda la organización (Scrum Management)”

Preferimos conceptos a metodologías

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.

Concepto 1: Gestión de proyectos predictiva y evolutiva

Modelos de gestión de proyectos

Gestión de proyectos predictiva

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.

Gestión de proyectos evolutiva

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.

 

Concepto 2: Ingeniería concurrente y agilidad

 

Agilidad e ingeniería concurrente

Ingeniería concurrente

  • Desarrollo basado en procesos: la calidad del resultado depende de la calidad del proceso.
  • Trabajo gestionado.
  • Ciclo de vida: evolutivo e incremental con solapamiento de fases.

Agilidad

  • Desarrollo basado en personas: la calidad del resultado depende del conocimiento tácito de las personas implicadas.
  • Trabajo autogestionado.
  • Ciclo de vida: evolutivo e incremental con solapamiento de fases.

 

Concepto 3: Incremento iterativo o continuo

Incremento

Para mantener un ritmo de entrega continuo y sostenido, la gestión de proyectos evolutiva emplea dos patrones:

Incremento iterativo

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á

Incremento continuo

Entrega continua de funcionalidades al ritmo que se van produciendo, manteniendo un flujo continuo, sin tiempos muertos ni cuellos de botella.

 

Preferimos conceptos a metodologías

¿Scrum vs Kanban o iterativo vs continuo?

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.

 

Gestión técnica y gestión experta

Técnica y experienciaCon 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).

 

Los mejores equipos no siguen metodologías

En el último viaje a San Francisco conocí ingenieros tanto de Google, como de pequeños proyectos y startup’s.

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 “autoorganizados” (?).  Es como aquello del “prohibido prohibir”

Me recuerda las conclusiones de Jared M. Spool en su conferencia de edui 2009:

  • Los mejores equipos no tienen una metodología ni siguen un dogma.
  • Los equipos con problemas a menudo intentan seguir una metodología, sin éxito.
  • Los mejores equipos exploran nuevas técnicas de trabajo de forma continua.
  • Los equipos con problemas tienen un repertorio de técnicas fijo y limitado.

Así era la primera implementación de Scrum para Software

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.
…..

FASES DE SCRUM

SCRUM comprende las siguientes fases:

Continue reading “Así era la primera implementación de Scrum para Software”

Scrum Manager: Alternativa Hispana sin Complejos

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.