La semana pasada, en el primer post de esta serie, hablábamos de algunos conocimientos que se deberían conocer para escalar Scrum, es decir, llevar Scrum a empresas grandes (y vimos algunos casos de estudio públicos, de los que se pueden contar, como los de Spotify y Autodesk).
Haciendo un breve resumen, hablábamos de las dimensiones para el crecimiento de Scrum, centrándonos en la dimensión “escala”, el contexto en el que se encuentra tú organización, Scrum visto como un “framework” orientado a objetos y algunas áreas de trabajo (te dejamos el enlace a la primera parte del post Scrum en empresas grandes: las áreas de trabajo para escalar Scrum (Parte 1//2)).
Retomando donde lo dejamos, en esta segunda y última parte, continuamos con las otras 5 áreas de trabajo que Jeff Sutherland cuenta en la conferencia Agile 2014 – Orlando que debieras considerar para escalar Scrum en empresas grandes .
Área de trabajo 5: Planificación de la Release
El reto aquí es la comunicación instantánea de las expectativas de las entregas a los clientes y/o usuarios y actualizar la priorización del Product Backlog basada en las aportaciones de los mismos.
Para llevar a cabo esta área, tanto en llevar Scrum en empresas grandes o como en cualquier tipo de empresa, es necesario tener priorizado el Product Backlog, tener datos sobre los requisitos, defectos y otras actividades complementarias, y adicionalmente aportaciones de los interesados, pudiendo así actualizar el Product Backlog basándonos en expectativas actuales, y obtener gráficos “Burn-down Char(s)” y “Roadmap ágil”.
“Burn-down Char(s)” son representaciones gráficas del trabajo por hacer de un proyecto en tiempo, donde podemos ver el avance del mismo (te dejamos este post sobre gráficos Burn-down y gráficos Burn-up, otro tipo de gráficos que muestran la cantidad de trabajo completado.
La siguiente imagen muestra un ejemplo de dos gráficos, Burn-down y Burn-up respectivamente.
Usualmente el trabajo pendiente del Product Backlog (medido normalmente en puntos historia) se muestra en el eje vertical y el tiempo de los Sprint en el eje horizontal. Estos diagramas son muy útiles para predecir cuándo se completará todo el trabajo. Normalmente, se actualizan al final de cada Sprint por el Product Owner (te dejamos una infografía sobre del Product Owner).
Adicionalmente, como complemento a lo anterior, en Scrum en empresas grandes, lo usual es usar un “Roadmap ágil”, que es un plan que describe cómo el producto va a ir evolucionando en el futuro, y su objetivo es planificar el producto a largo plazo, generalmente años (te dejamos un post sobre los roadmap ágil). Se actualiza cada varios meses y el encargado de ello es el Product Owner.
Algunos casos de estudio
¿Cómo logra la planificación de la release Spotify? El Product Owner es el encargado de proporcionar unas métricas o directrices a seguir, proporcionando visibilidad de todo el proceso a todos los que trabajan en el proyecto.
¿Cómo logra la planificación de la release Autodesk? El equipo se reúne regularmente para debatir el proceso, actualizar el plan de release y volver a priorizar el Product Backlog.
Área de trabajo 6: Gestión de la Release
El principal objetivo de esta área, al llevar Scrum a empresas grandes, es la entrega de los trabajos que han sido terminados a los usuarios, integrando el trabajo de los diferentes equipos en un solo producto, versión, reléase, etc., (quizá te ayuden aquí los post sobre aprender a implantar la integración continua desde cero, y DevOps, llevar la agilidad al departamento de sistemas para aumentar los pasos a producción).
El reto aquí es mantener un proceso de entregas constante por parte de los equipos. Si se consigue y además se logra recoger y procesar el feedback de los clientes y/o usuarios de estas entregas (que se irán incorporando al Product Backlog con su priorización correspondiente).
Algunos casos de estudio
¿Cómo logra la gestión de release Spotify? Si una nueva funcionalidad está acabada, se entrega directamente a los clientes. Las releases pueden ocurrir más de una vez al día, además todas las funciones tienen un conmutador de “on/off” para permitir una rápida retirada en caso de problemas.
Esta manera permite un rápido desarrollo de productos, pero hay que tener especial cuidado con las dependencias entre equipos, ya que puede haber historias de usuario de un Product Backlog que necesiten de otras de otro Product Backlog, lo que conlleva problemas, retrasos…
¿Cómo logra la gestión de release Autodesk? Release de productos cada mes, las funciones que no están terminadas a tiempo para la entrega se dejan para la siguiente versión, pero esto es más complicado de hacer con productos acoplados (te dejamos un post para saber más sobre el acoplamiento y cómo reducirlo)
Área de trabajo 7: Feedback de los clientes y/o usuarios
Los objetivos de esta área se centran sobre todo en los clientes/usuarios, en entender cómo estos utilizan e interactúan con el producto y así definir las mejoras en la funcionalidad existente y nuevas funcionalidades que puedan surgir para una próxima versión mejorada.
Obviamente son necesarias las reacciones de los clientes y/o usuarios, por ejemplo mediante la observación directa de los usuarios reales del producto haciendo uso del mismo, esto nos ayuda a encontrar errores o problemas de experiencia de usuario que se deben corregir, funcionalidad adicional que los usuarios piden a medida que interactúan con el producto…
Algunos casos de estudio
¿Cómo logra el feedback de los clientes Spotify? Los equipos usan diferentes tipos de herramientas para recoger y procesar el feedback de los clientes, como la observación directa o indirecta a los usuarios haciendo uso del producto, entrevistas, cuestionarios… Esto permite que cada equipo utilice un enfoque que funciona para sus necesidades.
¿Cómo logra el feedback de los clientes Autodesk? Feedback del producto a través de los clientes de prueba en las reuniones de demostración, cualquier comentario, votación, cambio… pasa por el Product Owner, de esta manera se mantiene una visión integrada de los productos.
Área de trabajo 8: Mejora continua y eliminación de impedimentos
El reto de esta área de trabajo en llevar Scrum a empresas grandes es la identificación de problemas que hacen ir a los equipos más despacio y una vez identificados, replantearse nuevas maneras de acelerar el ritmo y mantener un ambiente seguro y estructurado para seguir mejorando en sus trabajos.
Es necesaria la información sobre los problemas planteados por los equipos individuales y los datos de la velocidad del equipo en sus proyectos (te dejamos este post si quieres saber más sobre la velocidad), para tener una visibilidad de dichos problemas y aprender de ellos para mejorar en el desarrollo del producto.
Para recoger esta información, se puede hacer uso de las retrospectivas, reunión al final del proyecto o de cada iteración para mejorar y aprender de cómo han ido las cosas. Por si te vale de guía, existe una técnica que sirve para estructurar retrospectivas que recibe el nombre de “estrella de mar” y así poder organizar la información de manera eficiente (te dejamos un post para saber más sobre las retrospectivas y sobre esta técnica).
Algunos casos de estudio
¿Cómo logra la mejora continua y eliminación de los impedimentos Spotify? Cada uno de los equipos identifica sus problemas, la cultura de la mejora continua anima a los empleados a ayudar en la determinación de los impedimentos del equipo. Esto permite diferentes soluciones a diferentes problemas, y refuerza la cultura de colaboración.
¿Cómo logra la mejora continua y eliminación de los impedimentos Autodesk? Cada uno de los equipos identifica sus problemas y también son los encargados de eliminarlos, lo que requiere una mayor sobrecarga para los equipos.
Área de trabajo 9: Coordinación de equipos cruzados
En la primera parte del post, hablábamos de la estructura de los equipos (área de trabajo 1), de cómo deben ser los equipos, multifuncionales, auto-organizados, pequeños en número, mínimas dependencias entre equipos (te dejamos de nuevo el post para profundizar sobre cosas a tener claras para llevar un equipo de desarrollo)… con el objetivo de maximizar su productividad.
En esta área de trabajo los objetivos son la coordinación y comunicación entre múltiples equipos relacionados y la gestión de dependencias entre los equipos con el fin de que no se conviertan en obstáculos.
Para ello es necesario tener identificadas estas dependencias para poder realizar acciones alineadas y sincronizar los posibles retrasos que se puedan crear por las dependencias entre los equipos.
En la siguiente imagen vemos la estructura de los equipos de Spotify en la que componentes de los equipos forman otros equipos, por eso equipos cruzados, con mecanismos de coordinación entre ellos.
Algunos casos de estudio
¿Cómo logra la coordinación de equipos cruzados Spotify? Organización con superposición de los miembros del equipo con experiencia relacionada. Te dejamos un post sobre un caso de estudio de cómo Spotify organiza de manera ágil su departamento de desarrollo software.
¿Cómo logra la coordinación de equipos cruzados Autodesk? Equipos temporales formados por miembros de otros equipos para tratar un problema específico. Los equipos son “cruzados” en lo que a funcionalidad se refiere, útil para abordar problemas o retos importantes, pero de corta duración.
Área de trabajo 10: Métricas
La meta en esta área de trabajo en llevar Scrum a empresas grandes es proporcionar a quienes toman las decisiones, incluidos los miembros del equipo, buena información para tomar buenas decisiones y lograrlo con un mínimo esfuerzo y para ello, es necesario conocer la satisfacción del cliente y otros datos identificados como útiles.
Algunos casos de estudio
¿Cómo logra las métricas Spotify? Cada equipo elige sus propias herramientas, métricas y métodos. Todos los equipos tienen acceso a las herramientas y al espacio de cualquier otro equipo si se desea.
¿Cómo logra las métricas Autodesk? Todos los equipos utilizan la misma herramienta de seguimiento del Product Backlog y pueden tener acceso a los retrasos de los demás, a los datos de velocidad, a los Burn-down Char(s) y a los Roadmap. Los equipos pueden producir un cuadro de mando de métricas adicionales (bugs, felicidad, impedimentos, etc.) propios de su área.
Concluyendo…
Hoy día, muchas empresas han puesto en práctica Scrum y grandes empresas como las mencionadas en estos post, escalar Scrum, lo que ha permitido que este sistema haya madurado en los últimos años con gran éxito.
Jeff Sutherland habló de estas prácticas en la conferencia con el fin de que Scrum pueda seguir evolucionando y adaptándose a más contextos organizacionales y nosotros con esta serie de 2 post queremos ayudar difundir estos conocimientos para aquellos que quieran meterse en este mundo y llevar a cabo estas prácticas.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024