Agile Coach: Nuevo rol y competencias en el Agilismo

Imagen tomada de Jonathan Kessel-Fell

Las transformaciones digitales (1), las transformaciones ágiles (2) y las implementaciones de Scrum (3) han traído consigo la necesidad de nuevos roles y perfiles de profesionales. En Scrum se requieren los roles de Scrum Master, Product Owner y Development Team, y en éste y en los proyectos de transformación se suele necesitar la figura de un Agile Coach.

¿Qué es un Agile Coach? Un Agile Coach es un experto en agilidad con las competencias para lograr que una organización progrese en la implementación de sus procesos y proyectos ágiles, guiando a su personal y equipos de trabajo por el cambio cultural y estructural que normalmente esto involucra.

¿Cuál es el perfil profesional de un Agile Coach? Un Agile Coach es un experto en el uso de metodologías ágiles (Scrum, XP, Kanban, Lean, Management 3.0, entre otras), lo que le permite comprender los principios y valores ágiles, así como el propósito y aplicación de cada una de sus técnicas y herramientas, las dificultades, dudas, temores y otras barreras por los que pasa el personal que se inicia y busca convertirse en un agilista. Por otra parte, guiar al personal por el camino del agilismo, es una tarea compleja donde además de la experiencia técnica son necesarias las habilidades de un coach profesional que busca que el individuo saque todo su potencial y dé lo mejor de sí mismo, y para ello debe contar con habilidades de facilitador, formador, mentor y coach.

¿Cuáles son las habilidades de un Agile Coach? Comencemos con las habilidades de un Facilitador que cuenta con estrategias, herramientas y capacidades de facilitación de reuniones, eventos y encuentros que logran que ocurran con éxito las interacciones que se esperan de un equipo ágil, gestionando los conflictos, obteniendo el propósito y máximo provecho del evento facilitado, sin involucrarse en el contenido de las conversaciones y asegurando que todos se puedan expresar. Como Formador dispone de dinámicas de capacitación y entrenamiento adecuadas para formar y desarrollar en los agilistas de la empresa las competencias ágiles requeridas. Como Mentor apoya e incentiva al personal para que apliquen el aprendizaje y obtengan en forma continua la mejor versión de sí mismos y de sus equipos, maximizando su potencial y mejorando su capacidad y rendimiento, y para ello se cuida de no dar soluciones o recomendaciones, sino de facilitar que sean las personas y sus equipos los que tomen sus propias decisiones. Como Coach debe generar un alto grado de empatía con los agilistas en formación, aplicar una escucha activa y genuina, estar presente y generar confianza, dar feedback de calidad y hacer preguntas poderosas que orienten a la persona a las respuestas que tiene sentido y cambien, de ser necesario, la perspectiva de esta persona.

Entre otras habilidades (4) destacan:

• Sabe leer la situación observando
• Se preocupa por la gente más que por el producto
• Asume que no sabe y pregunta, es curioso
• Cree que en general la gente es bien intencionada
• Reacciona junto al equipo más que fijarse en el plan
• Tiene sed de aprendizaje
• Persigue la excelencia del grupo
• No permite el desperdicio
• Sabe que es necesario algo de caos y desequilibrio para conseguir resultados.
• No tiene miedo de equivocarse.

Y muy importante, disponer de paciencia, entusiasmo y constancia (5), a lo que añado auto-control y humildad.

Te invito a leer el Credo del Agile Coach, por Ewan O.: https://www.linkedin.com/pulse/i-am-professional-agile-coach-ewan-o-leary.

¿Cuáles son las funciones de un Agile Coach? Algunas de las funciones más relevantes son:

Asesorar y acompañar a la organización en la implementación de frameworks y métodos ágiles.

Facilitar reuniones, eventos, conversaciones y encuentros entre las personas y equipos de trabajo.

Capacitar a los agilistas de la empresa en las competencias ágiles requeridas y adaptadas a cada proyecto.

Guiar el uso de técnicas y herramientas ágiles para que los equipos logren sus metas y objetivos específicos, para ello debe estar alerta de cómo funciona el equipo.

Establecer mecanismos de medición y evaluación para validar rutas, realizar ajustes y facilitar la generación de acciones de mejora continua.

Incentivar y comunicar en forma constante la filosofía ágil, predicando con el ejemplo, para lograr que el cambio de cultura y mentalidad se lleve a cabo.

Estar alerta de cómo funciona el equipo para detectar obstáculos y oportunidades de mejora, y dar feedback.

Fomentar la transparencia en la ejecución de tareas, proyectos y ritmos de trabajo.

Dar ánimos y ayudar a gestionar frustraciones cuando las cosas no salen como queríamos

Finalmente, ¿Porqué es necesario un Agile Coach?

Vivimos en una sociedad ágil, dinámica, cambiante, con mucha incertidumbre, lo que la hace compleja y exigente de nuevas formas de gestión y de trabajo que le dé a las organizaciones la agilidad para responder a tales exigencias.

Transformar una organización en ágil, es una labor compleja, ya que implica cambios no solo de procesos y estructuras, sino de mentalidad y cultura. Esa es la labor de un Agile Coach ayudar a la organización en llevar a cabo transformaciones y proyectos ágiles.

Para ello, el Agile Coach requiere una visión global de la empresa que le permita ayudar al desarrollo y cambio profesional de sus empleados. Como Coach, no resolverá directamente los problemas, sino los localizará y notificará al personal y a los equipos sobre ellos, de tal forma que sean ellos quienes establezcan la mejor estrategia para solucionarlos.

Me encantaría recibir tus comentarios, opiniones y experiencias al respecto (^.^).

Gracias por leerme.-

________

(1) La transformación digital es la integración de tecnología digital en todas las áreas de una empresa, cambiando fundamentalmente la forma en que opera y brinda valor a sus clientes. También supone un cambio cultural que requiere que las organizaciones desafíen constantemente el status quo, experimenten y se sientan cómodas con el fracaso. La transformación digital puede implicar la reelaboración de los productos, procesos y estrategias dentro de la organización mediante el aprovechamiento de la tecnología digital. Tomado de https://www.powerdata.es/transformacion-digital

(2) En un entorno tan cambiante y competitivo como el actual, la utilización de los marcos de trabajo ágiles se ha convertido en un elemento común en la gestión de proyectos y equipos de las organizaciones más innovadoras y competitivas del mundo. Para ello, muchas empresas han decidido emprender su propia transformación Agile. Se trata de una nueva forma de trabajar más colaborativa, más abierta, más creativa y mucho más eficiente que otros modelos. Tomado de: https://www.ennaranja.com/agile/como-emprender-una- transformacion-agile-el-caso-de-ing/

(3) Scrum es un marco de trabajo para la gestión de proyectos. Es considerada un marco ágil para el Desarrollo Ágil De Software, aún cuando Scrum puede ser aplicado para la administración de proyectos de prácticamente cualquier índole. Tomado de https://dosideas.com/wiki/Scrum

(4) Resumen del libro Coaching Agile Teams de Lyssa Adkins, por Samuel Casanova. Disponible en: https://samuelcasanova.com/2018/05/resumen-coaching-agile-teams/

(5) ¿Qué es un Agile Coach? por Javier Martín de Agar. Disponible en: https://www.paradigmadigital.com/techbiz/que-es-un-agile-coach/

Management 3.0

Imagen tomada de Management 3.0

El portal https://management30.com define Management 3.0 como una mentalidad (mindset), combinada con una colección de juegos, herramientas y prácticas en constante cambio para ayudar a cualquier trabajador a gestionar la organización, dado que es una responsabilidad de grupo y no solo del gerente.

Utiliza un enfoque sistémico para encontrar las soluciones correctas para un liderazgo mejor y efectivo, teniendo como objetivo hacer crecer y transformar a las organizaciones hacia excelentes lugares para trabajar, con empleados motivados, comprometidos y clientes contentos.

Martie, es el Monstruo de 6 ojos del Management 3.0, que simboliza las seis vistas organizacionales:

A continuación enlaces a lecturas que detallan cada perspectiva y sus elementos clave: 

• Energizar a las personas: Motivación y compromiso, individuos e interacciones, recompensas e incentivos, felicidad laboral
• Empoderar a los equipos: delegación y empoderamiento
• Alinear restricciones: Valores y cultura, Significado y propósito, métricas y OKRs
• Desarrollar competencias: aprendizaje y competencias, mejores comentarios, mejores reuniones
• Estructura de crecimiento: escalamiento de la estructura organizacional, contratar grandes personas, desarrollo de productos ágil
• Mejorar todo: éxito y fracaso, creatividad e innovación

Para cada una de estas áreas, se disponen de dinámicas y juegos que buscan potenciar los resultados, como por ejemplo la cuadrícula de celebración (celebration grid), que puede ser utilizada en reuniones de retrospectiva para motivar al equipo a celebrar los experimentos y prácticas, que resultan de un resultado positivo, y donde podemos aprender algo de nuestros fracasos. Las preguntas clave son: ¿Qué hicimos bien? (siguiendo las prácticas) y ¿Qué aprendimos? (ejecutando experimentos). En el siguiente vídeo: Celebration Grids: Celebrate Learning, Juegen Appelo te explica el método.

Así se ve la matriz:

Donde en A. se colocan los errores que dieron un resultado positivo, en B. los experimentos que resultaron exitosos y con aprendizaje, en C. buenos resultados realizando las acciones correctas, D. malas prácticas que fallan, E. experimentos que fallaron y de los que se aprendió, y F. prácticas que fallaron.

La otra herramienta interesante para crear o fortalecer la empatía y ajustar experimentos y prácticas es la Puerta de la felicidad (happiness door), donde se anima a los participantes a compartir en un post it, las cosas que los hace feliz, en las que se sienten neutrales y la cosas que no les gustaron.

Tomado de: https://medium.com/@lallia_cherif/happiness-door-quick-powerful-feedback-where-emotions-matter-7a82183a5d23

Otra información de interés para crear buenos equipos es conocer las motivaciones y necesidades de las personas que conforman el equipo u organización. La dinámica se llama Motivadores en movimiento (moving motivators) y se basa en diez motivadores:

1. Orden: Hay suficientes reglas y políticas para un entorno estable.
2. Curiosidad: Tengo muchas cosas para investigar y sobre las cuales pensar.
3. Aceptación: Las personas a mí alrededor aprueban lo que hago y quien soy.
4. Honra: Me siento orgulloso de que mis valores personales se reflejan en cómo trabajo.
5. Meta: Mi propósito en la vida se refleja en el trabajo que hago.
6. Estatus: Mi posición es buena y reconocida por la gente que trabaja conmigo.
7. Maestría: Mi trabajo desafía mis competencias, pero aún está dentro de mis capacidades.
8. Libertad: Soy independiente de otros con mi propio trabajo y responsabilidades.
9. Poder: Hay suficiente espacio para que yo influencie lo que ocurre a mi alrededor.
10. Relaciones: Tengo buenas relaciones sociales con la gente de mi trabajo.

Se entrega a cada persona un lote de cartas con estos valores, para que la ordene de menor a mayor importancia. Por ejemplo:

Tomado de: http://www.plays-in-business.com/moving-motivators/

Es un tema apasionante y muy amplio, espero haber influido en tu curiosidad para que estudies y experimentes con estas prácticas.

Gracias por leerme.-

De qué va el Agilismo?

Imagen de JorgeRuiz.Agile

Agile, traducido en ocasiones como Agilismo, es una filosofía basada en el Manifiesto Ágil, desarrollado por diecisiete profesionales del software a partir de cuatro valores clave, con el objetivo de simplificar los procesos y la comunicación, y de acelerar los procesos de entrega de un producto. Estos valores son:

   1. Personas e interacciones antes que procesos y herramientas
   2. Software funcional antes que documentación exhaustiva
   3. Colaboración entre clientes antes que negociación de contrato
   4. Responder ante los cambios antes que seguir un plan.

Adicionalmente, incluye 12 principios que forman parte de los marcos de trabajo de las metodologías ágiles, tales como Scrum, con sus pilares de transparencia, inspección y adaptación, sus Sprints entre 1 y 4 semanas que entregan incrementos del producto de valor para el negocio, equipos auto-organizados, delimitación de roles que facilitan la comunicación y el foco del equipo de trabajo, ceremonias y artefactos con propósitos y reglas.

Kanban (“tarjetas visuales” creado en Toyota) es otro marco metodológico utilizado por los agilistas, para visualizar y mejorar el flujo de trabajo de forma continua. Consta de 3 reglas: 1. Visualizar el trabajo y las fases del flujo de trabajo, 2. Determinar el límite de “trabajo en curso” (Work In Progress-WIP) y 3. Medir el tiempo en completar una tarea (Lead Time). Kanban al igual que Scrum, promueve la división del trabajo en entregas de desarrollo incremental y la transparencia facilitando la visualización y la comunicación de lo que se hace y quien lo hace en cualquier momento del proyecto. Junto con Scrum, se conoce como Scrumban.

Lean aplicado a proyectos de software, fue popularizado por Mary y Tom en el libro, “Lean Software Development”, donde hacen hincapié en la eliminación de desperdicios y de la burocracia en el desarrollo de productos, fomentando el aprendizaje por ciclos cortos y frecuentes, iteraciones rápidas, retroalimentación del producto, en lugar de documentos de requisitos y planes de desarrollo.

Cabe destacar, que lo esencial del agilismo no son los métodos e instrumentos, los resultados dependen de la gente, como leí en algún post, “los instrumentos no hacen la música, la hacen las personas”. En un proyecto ágil, se debe tener clara la necesidad y lo que se quiere mejorar, y con ello en mente, identificar las herramientas más adecuadas para cumplir el propósito, sabiendo que al tomar acciones ágiles puede que se avance en la solución del problema, o puede que no funcione, lo que lleva al equipo a planear un nuevo experimento, ponerlo en práctica y entrar de nuevo en el ciclo de evaluación y mejora contínua.

Otra consideración importante, es que hacer agilismo se aprende aplicándolo, aprendiendo y evaluando los resultados, y adaptando las estrategias para mejorar en forma continua.

Cuando una organización quiere una transformación ágil, Apiumhub, empresa de desarrollo de software, propone los siguientes pasos: Pasos a considerar:

1. Describe la visión de la transformación, lo que está cambiando y los beneficios que espera
2. Crea el equipo de implementación, que planificará y ejecutará la agenda de transformación
3. Identifica los beneficios rápidos de las formas ágiles de trabajar
4. Crea una marca y socialízala, la transición ágil es un cambio de mentalidad
5. Entrena, experimenta y haz correcciones. La mejora continua es la clave, el liderazgo debe recibir retroalimentación de los grupos de interés, de forma contínua para validar que el negocio se beneficia de hecho con las prácticas ágiles.

Seguiremos compartiendo aprendizajes y reflexiones sobre este tema.

Gracias por leerme.-

La Gestión en Scrum

Imagen tomada del portal proyectosagiles.org

¿Cómo se lleva a cabo la gestión en un proyecto ágil? ¿Cómo el Product Owner, el Scrum Master y el Equipo de Desarrollo se relacionan con otros roles como el Project manager, el Product manager y el PMO manager?.

En todo proyecto se gestionan los recursos financieros, logísticos y humanos, se gestiona el producto, los procesos de desarrollo y el proyecto, todo esto en la búsqueda de efectividad y eficiencia.  

En algunas organizaciones y metodologías existe el rol del Gerente o Director del proyecto (Project manager), que el PMI (2017)^[i] define como la persona asignada por la organización que está dedicada a liderar el equipo responsable de lograr los objetivos de un proyecto.

En Scrum, el equipo se auto-gestiona, lo que significa que no hay un líder o gestor para delimitar, asignar y coordinar sus tareas, son los propios miembros del equipo quienes lo realizan. Scrum incorpora el rol del Scrum Master (SM), un facilitador, coach o líder servicial, que ayuda al equipo a lograr los objetivos desde sus propias decisiones y competencias.

Por otra parte, el Product Owner (PO) es el rol dentro de Scrum que asegura el desarrollo del producto correcto en el orden adecuado, por lo que es responsable de maximizar el valor de los productos para el negocio a través de la gestión y priorización del Product Backlog y del trabajo que realiza el equipo en cada Sprint.

Adicionalmente, los productos requieren de una gestión estratégica, con una visión a corto y mediano plazo, lanzamiento al mercado, estudio de nuevas oportunidades, etc. Para ello, algunas empresas disponen de Product Managers (PM), personal responsable de la gestión estratégica del producto. El Product Manager trabaja de la mano del PO, quien tiene un rol más operativo y táctico junto al equipo de desarrollo.

Entonces, las funciones del Project Manager se distribuyen en los 3 roles de Scrum y el Product manager trabaja en forma coordinada con el Product Owner, o éste asume sus funciones.

Otro rol común, en particular en grandes empresas, es el PMO Manager (gestor de la Oficina de Proyectos) quien asume funciones de estandarización, aplicación de metodologías y herramientas gerenciales para la administración y gestión de proyectos, gestión de conflictos entre proyectos, gestión de recursos financieros, logísticos y humanos, entre otros, funciones similares al del Scrum Master pero a nivel de Portafolio de productos y de programas que integran varios proyectos.

En métodos de escalado de Scrum, como SAFe, donde se manejan varios niveles (portafolio, programa, equipo), el nivel de programa incorpora roles como el Release Train Engineer, Product Management, System Architect/Engineer, System Team y el Bussiness Owners, roles cuya función principal es la de alinear, sincronizar e integrar equipos y productos de varios proyectos que comparten objetivos comunes. En este sentido una PMO podría transformarse para dar respuesta a la implementación de un escalado de Scrum.

Si nos mantenemos dentro del marco de Scrum, las funciones de la gestión (planificación, control (métricas), organización, comunicación) la llevan a cabo sus 3 roles. La siguiente tabla resume para cada elemento el rol responsable en Scrum.

Cabe destacar que el Equipo Scrum, conformado por el Product Owner, el Scrum Master y el Equipo de Desarrollo, trabajan como una unidad para lograr los objetivos del proyecto. El término responsable se utiliza para señalar quien lleva la gestión del artefacto, herramienta o evento en Scrum, y su función más importante es lograr la integración y colaboración activa de los otros miembros del equipo.

Gracias por leerme.-

[i] Project Management Institute (PMI) (2017). Guía del PMBOK (Project Management Body of Knowledge).

Estimaciones y planes en SCRUM

El manifiesto ágil tiene entre sus principios dar “Respuesta ante el cambio sobre seguir un plan”, lo que quiere decir que por encima el plan está la flexibilidad para realizar cambios y adaptarse a las exigencias dinámicas del negocio, del mercado, de la tecnología, etc.

En Scrum la planificación se realiza al inicio de cada Sprint, sobre la base de un Product Backlog  priorizado, que va evolucionando a lo largo del proyecto. El Sprint Planning se focaliza en establecer qué y cuánto trabajo incluir en el Sprint para lograr la meta acordada por el equipo, incluyendo cómo lograrlo.

El marco de trabajo iterativo de Scrum, comienza en el Sprint 1, con la existencia de un Product Backlog preliminar, ya que sus autores no referencian un Sprint 0. Independientemente de esto, antes de iterar para obtener los incrementos del producto, es necesaria una fase preliminar, que algunos llaman “Incepción“ (Inception), para conformar el equipo de Scrum, comprender una visión general del problema y de la solución de alto nivel compartida por todos los miembros del equipo, identificar e involucrar a los stakeholders, asegurar los recursos financieros, técnicos y logísticos necesarios, configurar los ambientes, generar el Product Backlog, desarrollar las historias de usuario prioritarias, y generar un Plan General de Entregas de alto nivel (Release Plan).

En los proyectos complejos, al comienzo poco se sabe sobre el producto y el desempeño del equipo, por lo que las estimaciones están sujetas a una gran incertidumbre, sobretodo en proyectos de software, donde el contexto es volátil, la tecnología cambia con rapidez, así como la dinámica del negocio y del mercado.

Las estimaciones en contextos inciertos hacen poco probable el cumplimiento de planes, a medida que avanza el proyecto aumenta el conocimiento y las estimaciones podrán ser más precisas. Las estimaciones iniciales son aproximaciones basadas en supuestos con incertidumbre que utilizan valores con orden de magnitud probable. Por ejemplo las Épicas (agrupaciones de historias de usuario de alto nivel), podrían estimarse con letras (S pequeña, M medio, L grande, XL muy grande), para las historias de usuario se suele utilizar una estimación relativa que asigna puntos basados en la secuencia de Fibonacci (0, 1, 2, 3, 5, 8, 13, …), así una historia de 2 puntos requiere el doble de esfuerzo de una de 1 punto, y una de 3 puntos el triple.

Una forma de asignar el puntaje a la historia, es con la técnica del Póker Planning, donde cada miembro del equipo recibe un lote de cartas con los valores de la serie de Fibonacci, el Product Owner explica la historia de usuario, cada persona selecciona una carta y todos a la vez presentan su selección. Las personas con los puntos más bajos y más altos explican por qué del puntaje asignado, el equipo discute y puede repetirse la jugada hasta llegar a un consenso.

Por otra parte, cada equipo de desarrollo tiene una Velocidad, que representa la cantidad de trabajo realizada en un Sprint, por ejemplo, una velocidad de 15 puntos indica que el equipo realiza 15 puntos de trabajo en cada Sprint. Para los primeros Sprint el equipo asigna una velocidad estimada, que se refina luego del tercero o cuarto Sprint con la velocidad real que ha tenido el equipo en estos primeros Sprint.

Sobre métricas y estrategias de seguimiento hablaremos en la próxima entrega.

Gracias por leerme.-

Las Historias de Usuario en SCRUM

Uno de los principales insumos en el desarrollo de productos son las especificaciones funcionales, donde clientes y usuarios describen a los desarrolladores lo que desean del producto. Cuando éstas son escritas, están sujetas a interpretaciones, malos entendidos y resultados que no satisfacen las expectativas. La comunicación humana se enriquece con las conversaciones, ya que el tono de voz y los gestos comunican más que las palabras, por esta razón en SCRUM se incorpora el concepto de Historias de Usuario (User Story), especificaciones compuestas de una pequeña ficha (card) que esquematiza la redacción del requisito, conversaciones entre el Product Owner y el Equipo de Desarrollo y Criterios de aceptación que especifican las condiciones que debe cumplir dicho requisito (3C: Card Conversaciones Criterios).

La redacción de la historia de usuario describe para el rol involucrado, la funcionalidad requerida y el objetivo de la misma en una frase corta, la cual tiene la forma: Como Quiero Para . Por ejemplo: Como Estudiante quiero consultar mis programas en línea para ahorrar tiempo y dinero.

Los criterios de aceptación deben describir un contexto, un evento y la respuesta o consecuencia esperada. La forma más utilizada para describir los criterios de aceptación es: Dado Cuando Entonces . Aquí un ejemplo: Dado un estudiante autenticado en el sistema académico Cuando accede a la opción de programas en línea Entonces se le redirige automáticamente a la lista de programas de la carrera en la cual está inscrito.

Una buena historia de usuario debe cumplir un conjunto de características, conocidas con el acrónimo INVEST: Independiente (poderse desarrollar sin depender de otra), Negociable (entre el Product Owner y el Equipo de Desarrollo), Valiosa (para los clientes), Pequeña (desarrollable en poco tiempo) y Testeable (con los criterios de aceptación bien definidos para ser probada). Adicionalmente, el equipo de desarrollo acuerda con el Product Owner las condiciones que debe cumplir una historia de usuario para estar lista (Definition of Ready) y poder ser incluida en el Sprint Backlog, por ejemplo debe cumplir los requisitos INVEST, estar redactada de la forma    Como-Quiero-Para, y detallados los Criterios de aceptación de la forma Dado-Cuando-Entonces.

Finalmente, el equipo de SCRUM también debe acordar las condiciones que debe cumplir la historia de usuario para darla por terminada (Definition of Done) y disponer de un producto entregable y usable, por ejemplo todos los criterios de aceptación funcionan correctamente, todos los archivos fuentes están en el repositorio adecuado, entre otros.

En el Product Backlog, pueden registrarse historias de usuario generales, de gran complejidad, que cuando pasan a ser prioritarias, se descomponen en más pequeñas. A estas historias se les conoce como épicas (epic) y la estimación general que se puede utilizar es XS (muy pequeña), S (pequeña), M (medio), L (grande) y XL (muy grande). Para las historias de usuario que van al Sprint Backlog, la estimación de esfuerzo puede utilizar la secuencia de Fibonacci, técnica sobre la cual les hablaré en el próximo artículo.

Gracias por leerme.

Rituales o Eventos de SCRUM

La dinámica de SCRUM se implementa a través de ceremonias o rituales caracterizadas por eventos de duración predeterminada (Time-box), que le dan al desarrollo un ritmo sostenible, con entregas frecuentes de software valioso y oportunidades frecuentes de inspección, adaptación y transparencia. Cada evento en forma de reunión, tiene un objetivo con una duración máxima que depende del tamaño del Sprint, que se puede acortar si se logra antes dicho objetivo. Solo el Sprint tiene una duración fija. El SCRUM Master se asegura que el equipo comprende, realiza y logra el objetivo de cada evento en el tiempo especificado.

Los rituales de SCRUM mejoran la comunicación entre los miembros del equipo y con ello su nivel de conocimiento, asimismo, promueven el cumplimiento del objetivo del Sprint ya que facilita procesos ágiles de aprendizaje, toma de decisiones y solución de problemas.

El Sprint es el núcleo de SCRUM en el que se desarrolla y entrega un incremento del producto. Tiene una duración entre 1 y 4 semanas, siendo 2 o 3 semanas la duración más común. Considerando la complejidad del desarrollo, la volatilidad del negocio, la tecnología y la madurez del equipo,  el equipo SCRUM decide el tamaño fijo que tendrán los Sprint. Si la meta fijada para el Sprint se logra antes, o no se pudiese alcanzar, el equipo podría ajustar el alcance del Sprint, pero no se modifica su tiempo de duración. Cada Sprint contiene los demás eventos.

Los eventos de SCRUM incluyen: la reunión de Planificación del Sprint (Sprint Planning Meeting), las reuniones Diarias (Daily Scrums), la Revisión del Sprint (Sprint Review) y la reunión de Retrospectiva (Sprint Retrospective). Adicionalmente, el equipo puede realizar 1 o 2 reuniones de Refinamiento del Product Backlog (Product Backlog Refinement o Grooming) para colaborar con el Product Owner en el mantenimiento y detalle del Product Backlog.

En el Sprint Planning todo el equipo colabora para seleccionar los PBI (Product Backlog Item) priorizados que se desarrollarán durante el Sprint y fijar la meta del mismo. Los PBI deben ser lo más independientes posible, los más dependientes podrían agruparse en uno. 

El Sprint Planning dura máximo 8 horas en Sprint de un mes. Se divide en 2 partes, la primera donde el Product Owner explica los detalles funcionales de los PBI prioritarios, responde las preguntas del equipo de desarrollo y junto al equipo se seleccionan los PBI a desarrollar y la meta del Sprint. En la segunda parte, se suele retirar el Product Owner, y el equipo acompañado del Scrum Master, establece cómo se realizará el trabajo, define un diseño general, identifica tareas técnicas y llega a acuerdos de alto nivel que se detallarán durante el desarrollo del Sprint. El resultado del Sprint Planning es el Sprint Backlog que se coloca en una pizarra de tareas (Taskboard), física o digital, visible para todos.

El Equipo de Desarrollo es quien realiza la estimación de esfuerzos. Puede utilizar la técnica de Planning Poker para realizar una estimación inicial por consenso donde cada miembro  comparte su opinión y estimación. También se suele utilizar información sobre la velocidad y capacidad productiva del equipo obtenida en Sprint anteriores. En SCRUM la estimación es un pronóstico  potencial que se basa en el compromiso que adquiere el equipo para lograr el objetivo del Sprint.

Las reuniones Diarias (Daily Scrums), son reuniones cortas que el equipo de desarrollo debe realizar todos los días, de solo 15 minutos, para asegurar la comunicación, coordinación de actividades y la colaboración entre los miembros del equipo. Los Daily permiten al equipo evaluar actividades, compartir dificultades y tomar decisiones de planificación, en tiempo real, promoviendo los pilares de Scrum de Transparencia, Inspección y Adaptación.

Se realizan siempre a la misma hora y en el mismo lugar. Es conducida por el Equipo de Desarrollo, el Scrum Master puede facilitar la dinámica para garantizar se mantenga la reunión dentro de su propósito y duración. Puede asistir el Product Owner y otros involucrados en calidad de observadores, sin embargo, no deben intervenir en la discusión, ni solicitar justificación del progreso o explicaciones a los problemas. No se debe usar para dar Status a ninguno de los roles.

Cada miembro del equipo de desarrollo responde a 3 preguntas: 1. ¿Qué hice desde el último daily? 2. ¿En qué voy a estar trabajando?, y 3. ¿Qué problema o impedimento tengo para alcanzar el objetivo?.  Los problemas no se resuelven en el daily, sino en revisiones posteriores. El Scrum Master asegura que estas revisiones se realicen a la brevedad y los problemas sean resueltos con prontitud.

Al finalizar el Sprint se realiza una reunión de revisión (Sprint Review), donde el equipo de desarrollo presenta al Product Owner e involucrados, el resultado funcional del incremento. Estos lo aceptan o rechazan dando retroalimentación al equipo de desarrollo. Si el elemento (PBI) es rechazado, reingresa al Product Backlog con alta prioridad, para ser tomado en el próximo Sprint; a menos que el Product Owner cambie la prioridad del elemento. El Scrum Master facilita la reunión, asegurando que cumpla su objetivo dentro del tiempo estimado, que en Sprint de un mes, es máximo de 4 horas.

Luego del Sprint Review y antes del Sprint Planning del próximo Sprint, se realiza una reunión de Retrospectiva (Sprint Retrospective), que permite al equipo reflexionar sobre cómo se realizó el trabajo, identificar y analizar los acontecimientos positivos y negativos para el cumplimiento del objetivo del Sprint. El resultado principal de esta reunión es lograr en consenso acciones de mejora para ser implementadas en el próximo Sprint, asegurando con ello la mejora continua y la implementación de prácticas emergentes en los procesos del equipo de desarrollo. Estas acciones y su impacto se revisan en la próxima reunión de retrospectiva. Cómo en los otros eventos, el Scrum Master facilita la reunión, asegurando que cumpla su objetivo dentro del tiempo estimado, que en Sprint de un mes, es máximo de 3 horas.

Por último, a fin de mantener el Product Backlog priorizado y los PBI próximos a desarrollarse detallados, el Product Owner y el Equipo de desarrollo suelen ejecutar 1 o 2 reuniones de refinamiento (Product Backlog Refinement o Grooming) en cada Sprint, donde se añaden, retiran, detallan y estiman los elementos del Product Backlog del siguiente Sprint. Es una reunión corta, generalmente de 1 hora, conducida por el Product Owner, con el apoyo del Scrum Master quien asegura que la reunión cumpla su objetivo en el tiempo establecido.

Un aspecto de gran relevancia para el éxito de cualquier proyecto de desarrollo de software, es la forma en que se describen los requerimientos o requisitos del producto en el Product Backlog, siendo la técnica más utilizada las historias de usuario. Sobre este tema escribiré en el próximo artículo.

Gracias por leerme.-

Los 3 artefactos de SCRUM

Al aplicar SCRUM se utilizan 3 herramientas o artefactos: el Product Backlog, donde se registran los elementos (requerimientos y características) del producto, el Sprint Backlog, que contiene los elementos a desarrollar en un Sprint y los resultados de cada Sprint que se denomina el Incremento del producto.

El Product Backlog está conformado por la lista de elementos (PBI: Product Backlog Item) que conforman las especificaciones de un producto. Estos elementos incluyen los requerimientos, características del producto, historias de usuarios, criterios de aceptación, etcétera.  Esta lista está ordenada por prioridad, de acuerdo al valor que el PBI da al negocio y su aporte al logro de los objetivos. El Product Backlog es gestionado y mantenido por el dueño del producto (Product Owner).

En los enfoques de desarrollo tradicionales, se procura describir con el mayor detalle posible el alcance del producto, valorando que éste no cambie durante la construcción. En SCRUM se reconoce, que al desarrollar proyectos complejos, es imposible conocer en detalle todas las especificaciones del producto que se pretende desarrollar. En lugar de eso, se tiene un alcance variable que se va refinando y descubriendo en la medida que el desarrollo avanza, con las entregas iterativas y la retroalimentación frecuente, dando lugar a un producto iterativo, incremental y evolutivo. En el Product Backlog los PBI más prioritarios tienen más detalle que los PBI de menor prioridad, que se van refinando y  adaptando a la evolución del producto, del contexto y de la tecnología.

El Product Owner establece el objetivo y meta del Sprint, y el Equipo de Desarrollo selecciona los PBI que hacen posible la meta deseada, conformando el Sprint Backlog, junto al plan, tareas técnicas, tareas de ejecución y acciones de mejora del proceso. El Equipo de Desarrollo es el dueño del Sprint Backlog, y es el único que lo gestiona y actualiza. El Product Owner no debe modificar los PBI del Sprint Backlog y el Equipo de Desarrollo debe hacer visible su contenido a todo el equipo de trabajo y a los involucrados (stakeholders) del proyecto.

El tercer artefacto de SCRUM es el Incremento del producto, que es la suma de todos los PBI completados durante un Sprint y el valor de los incrementos de todos los Sprint anteriores. Un acuerdo importante que debe establecer y cumplir el Equipo de trabajo, es cuando un PBI está completado o terminado, lo que se conoce como “Definition of Done”, el cual especifica las condiciones que debe cumplir el elemento para darlo por completado. Incluye usualmente que todos los criterios de aceptación de cada PBI han sido validados y aceptados por el Product Owner, que todas las pruebas unitarias e integrales se realizaron sin generar errores, entre otros criterios. Esto asegura que el incremento es usable, independientemente de si el Product Owner decide liberarlo o no.

Estos artefactos se crean y mantienen de forma cíclica dentro de los Eventos de SCRUM. En el próximo artículo te hablaré sobre el propósito y la dinámica de cada uno de estos eventos.

Gracias por leerme.-

El Liderazgo en SCRUM

En Scrum se definen 3 roles: el Equipo de Desarrollo (Development Team), el Dueño del Producto (Product Owner) y el SCRUM Master.

El Equipo de Desarrollo es responsable de estimar, desarrollar y entregar productos terminados al final de cada Sprint. No tiene un líder, sus miembros disponen de las habilidades necesarias para construir el producto, sin títulos ni rangos, aunque con destrezas específicas, todos son desarrolladores, y la responsabilidad del producto es del equipo. Sus miembros se auto-organizan para decidir cómo realizar el trabajo y resolver los problemas que se presenten. Su tamaño suele estar entre 3 y 9 personas.

El Product Owner es el responsable de maximizar el valor del Producto y del trabajo del Equipo de Desarrollo, asegurando la claridad, visibilidad, transparencia y comprensión de las características y requerimientos del incremento del producto a desarrollar en cada Sprint. Gestiona las expectativas de los stakeholders y determina las prioridades de las especificaciones del producto, adaptándolas a los cambios que se den en el negocio o en la tecnología. Aunque puede representar las necesidades de un grupo de personas o comité, el Product Owner es una sola persona con la autoridad para establecer las prioridades y especificaciones del producto dentro del proyecto.

El SCRUM Master es el Coach del equipo, enseña y acompaña el uso de SCRUM, ayudando al equipo para que alcance su máximo nivel de productividad. En palabras de Wolk[1] es un Facilitador que fomenta ambientes de apertura y discusión para lograr consensos, es un Provocador que desafía las estructuras rígidas y antiguas concepciones de cómo se deben hacer las cosas, es un Detective que busca indicios y pistas en la narrativa del equipo, y es un Soplador de brasas que facilita en el otro el aprendizaje para reconectarlo a sus pasiones.

El SCRUM Master es un Facilitador Servicial que acompaña al Product Owner y al Equipo de Desarrollo en la comprensión y el uso correcto de SCRUM,  y para que realicen sus actividades con productividad y eficiencia. Asimismo, protege al equipo de distracciones y trabas externas, facilita la remoción de impedimentos y asegura la comunicación y colaboración dentro del equipo.

El SCRUM Master realiza sus funciones sin interferir en el trabajo del equipo, no ordena, ni controla, por lo que no incide de forma directa en los resultados del equipo, a diferencia de un gerente tradicional de proyectos. Sin embargo, sí el SCRUM Master logra cumplir con éxito su propósito, será una pieza clave en el logro del éxito del proyecto.

SCRUM propone un conjunto mínimo de artefactos para construir un producto, en la próxima entrega les hablaré sobre ello.

Gracias por leerme.

---

[1] Wolk, Leonardo. Coaching. El arte de soplar brasas, 2003. Citado en Alaimo y Salinas. Proyectos ágiles con SCRUM. Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos, 2015.