Para el Delivery, los equipos de Producto se apoyan en el enfoque ágil. Agile permite una mejor capacidad de respuesta a los cambios, las exigencias y las necesidades de los usuarios gracias al desarrollo iterativo y continuo. Apoyándose en los principios y valores de Agile, el equipo se esfuerza por establecer un funcionamiento colaborativo y humano, propicio para la iteración y la mejora continua.
Los fundamentos del enfoque Agile
Los valores y principios de Agile
El enfoque agile se compone de 4 valores y 12 principios descritos en un manifiesto, que permite desarrollar productos digitales de calidad mediante la entrega de pequeños incrementos.
Los valores fundamentales de Agile indican que:
- Las personas y las interacciones son más importantes que los procesos y herramientas. La comunicación y la colaboración entre los miembros del equipo son esenciales para el éxito de un producto.
- Un producto operativo es más importante que una documentación exhaustiva. Aunque la documentación es necesaria, la prioridad debe darse a la creación del producto.
- La colaboración con el cliente es más importante que la negociación contractual. Se enfatiza en el contacto del equipo con el cliente para responder adecuadamente a sus necesidades que evolucionan con el tiempo.
- La adaptación al cambio es más importante que seguir el plan. En lugar de aferrarse a un plan inicial fijo, el equipo está abierto a los cambios y puede responder de manera flexible.
Los 12 principios de Agile
Estos principios se implementan mediante frameworks como Scrum o Kanban, que ayudan a los equipos a entregar valor de forma constante y ágil.
Prerrequisitos para la implementación de Agile
Como prerrequisito para la correcta aplicación de Agile, es necesario establecer un entorno propicio para la autonomía y la colaboración del equipo. De hecho, el éxito de un equipo ágil reside en su capacidad para ser empoderado, con un alto grado de alineación y autonomía. Por eso, un equipo de Producto Agile es:
- Multidisciplinar y autoorganizado: incluye a todas las personas (a tiempo completo o parcial) necesarias para el delivery, ya sea en diseño, desarrollo y prueba.
- Autorizado para tomar decisiones: puede tomar decisiones y poner en producción de manera regular y autónoma.
Este artículo es un extracto del libro:
Frameworks agile para la gestión de productos
Scrum, un marco estructurado
Scrum se basa en la implementación de ciclos de desarrollo cortos e iterativos llamados sprints, durante los cuales el equipo se enfoca en la entrega de un alcance específico y establecido. Basado en tres pilares fundamentales —la transparencia, la inspección o la capacidad de cuestionarse a sí mismo, y la adaptación al cambio—, el marco detalla 3 roles, 3 artefactos y 4 eventos.
Los 3 roles de Scrum
- El Product Owner tiene el rol de maximizar el valor del producto realizado por el equipo. Es responsable de la gestión del backlog, asegura representar las necesidades de las distintas partes interesadas en los ítems del backlog y comunica objetivos de Producto claros. El rol de Product Owner es específico del marco Scrum. En principio, estas responsabilidades recaen en los Product Managers.
- El Scrum Master tiene el rol de acompañar al equipo en la aplicación de Scrum. También facilita la comunicación entre los distintos actores y elimina los obstáculos que encuentra el equipo. Dependiendo de las organizaciones y los niveles de madurez de un equipo, el rol de Scrum Master puede ser desempeñado por una persona compartida entre varios equipos o por un desarrollador dentro del equipo.
- El equipo de desarrollo realiza el trabajo necesario para la creación del producto y la entrega de un incremento terminado.
Los 3 artefactos de Scrum
Scrum menciona tres artefactos principales que permiten difundir la información con transparencia:
- El Product Backlog es la lista de ítems necesarios para construir o mejorar el producto, priorizados por el Product Owner según su valor.
- El Sprint Backlog contiene los elementos más prioritarios del Product Backlog que el equipo de desarrollo se compromete a entregar durante el sprint en curso.
- El incremento es la suma de desarrollos que respetan la Definition of Done y pueden ser puestos en producción.
El sprint
En el corazón del marco Scrum, el sprint tiene una duración máxima de cuatro semanas. Esta duración es generalmente fijada por los líderes de Producto y no por los Product Managers, para asegurar coherencia entre equipos. Sin embargo, el objetivo para Scrum es tener iteraciones lo más cortas posibles para entregar los incrementos de Producto, obtener feedback y ajustar el alcance lo más pronto posible.
El sprint comienza con la planificación del sprint, donde el equipo se compromete con un objetivo a alcanzar: el objetivo del sprint o sprint goal. Marcado por los daily, termina con la revisión y la retrospectiva.
Los 4 eventos de Scrum
- La Sprint Planning establece el marco del sprint. Durante esta ceremonia, el equipo discute las Historias de Usuario más prioritarias y determina lo que puede ser incluido en el sprint definiendo el objetivo del sprint.
- La Daily se organiza todos los días a la misma hora, permitiendo al equipo compartir el progreso del sprint respecto al objetivo del sprint. El objetivo de la Daily no es reportar el trabajo realizado, sino identificar los posibles puntos de bloqueo lo más rápidamente posible y ajustar la priorización y el backlog del sprint si es necesario, para garantizar el logro del objetivo.
- La Sprint Review permite al equipo presentar a las partes interesadas el resultado del sprint. El equipo hace una demostración de los incrementos realizados y puede recoger el feedback de las partes interesadas. Una buena práctica es que la demostración la realicen los desarrolladores que contribuyeron al desarrollo de las funcionalidades presentadas. Además de la demo, la Review es también la oportunidad de compartir elementos clave como el seguimiento del rendimiento, un balance sobre el avance del roadmap o la consecución de objetivos.
- La Sprint Retrospective (Retro) permite hacer un balance del sprint para identificar los éxitos y fracasos, así como las áreas de mejora. También permite implementar acciones de mejora continua. Existen múltiples formatos de retrospectiva, lo que permite renovarse y hacer el ejercicio más dinámico.
El marco de trabajo Scrum
Kanban, gestión de delivery en flujo continuo
Kanban se basa en el principio de flujo continuo. Los elementos listos y prioritarios del backlog son «arrastrados» en el tablero Kanban. Antes de comenzar un nuevo tema, el equipo revisa si puede avanzar o terminar alguno de los temas actuales. El enfoque Kanban se centra en la visualización del trabajo en curso, la limitación de este trabajo, la optimización del flujo y la mejora continua.
Visualización y limitación del trabajo en Kanaban
El tablero Kanban es una herramienta que permite visualizar el flujo de trabajo en forma de etapas, cada etapa representada por una columna. El flujo representa de manera exhaustiva el conjunto de actividades necesarias para entregar una funcionalidad. Según tus necesidades, el tablero puede ser tan simple como «por hacer», «en curso» y «hecho», o bien más detallado, con columnas como «por analizar», «listo», «en desarrollo», «en revisión», «en prueba», «terminado», «desplegado», «cerrado».
La tarjeta Kanban es un elemento del backlog. Colocadas en el tablero por orden de prioridad, las tarjetas, que son todas de tamaño equivalente, van a moverse por las columnas de izquierda a derecha. Es posible que una tarjeta salte algunas columnas, pero en principio no pueden regresar atrás. Los criterios de ese movimiento deben ser explícitos y compartidos.
Esta representación visual es esencial, ya que permite dar una mejor visibilidad sobre el trabajo en curso y facilita la identificación de puntos de bloqueo que podrían impedir el avance de los temas.
«Deja de empezar, empieza a terminar» es un lema que refleja bien el enfoque Kanban. El objetivo es hacer que el máximo número de elementos pase lo más rápido posible de una columna a la otra. En lugar de trabajar en un gran número de tareas en paralelo, se impone para cada columna del tablero un límite en el número de elementos que pueden figurar al mismo tiempo en la columna. Esto es lo que se llama el WIP Limit (Work in Progress Limit). Una vez alcanzado el límite, el equipo se concentra en los elementos presentes en la columna y se ayuda mutuamente para hacerlos avanzar a la siguiente etapa.
El marco de trabajo Kanban
Optimización del flujo
En Kanban, para optimizar el flujo de trabajo, es importante analizar los procesos de producción e identificar las etapas que más tiempo consumen. El tiempo de ciclo (cycle time), un indicador que mide el tiempo para pasar de una etapa a otra, permite detectar los cuellos de botella. El tablero también ayudará a identificar las etapas en las que las tareas se acumulan. Al identificar las etapas problemáticas, es posible mejorarlas y optimizar el proceso de entrega de funcionalidades.
Mejora continua en Kanban
El enfoque Kanban fomenta la mejora continua evaluando regularmente el proceso e identificando oportunidades de mejora. El equipo discute los éxitos y fracasos con el objetivo de identificar formas de mejorar el rendimiento en el futuro. Aunque no hay un ritual específico documentado en el marco de Kanban, la retrospectiva es un buen medio para enmarcar esta reunión regular.
Adaptar agile a las necesidades del equipo
Scrum y Kanban son dos marcos de trabajo que implementan los principios y valores Agile con el objetivo de mejorar la colaboración, transparencia y productividad. Aunque ambas aproximaciones tienen similitudes, cada una tiene sus especificidades y limitaciones.
Scrum, que ofrece más procesos y reglas, así como un ritmo iterativo fijo con los sprints es adecuado para contextos que requieren una planificación rigurosa, como cuando se necesita un fuerte alineamiento entre diferentes equipos que trabajan en el mismo ámbito. Sin embargo, Scrum puede volverse restrictivo, obligando a los Product Owners a proveer un número significativo de Historias de Usuario listas para ser incluidas en un sprint en una fecha específica, o limitando la capacidad de adaptarse durante un sprint.
Kanban, más flexible, permite ajustar más rápidamente los cambios de prioridades y es más adecuado en contextos que requieren una capacidad de adaptación rápida. Por otro lado, Kanban puede carecer de estructura y planificación a largo plazo.
Algunos equipos optan por un modelo híbrido, a menudo llamado Scrumban, para adaptar el marco a sus necesidades operativas. Pueden comenzar con el enfoque de flujo de Kanban mientras agregan elementos de Scrum, como el daily, la review y la retrospectiva. También pueden elegir mantener el ritmo de los sprints y permitir que el equipo tome directamente del backlog las Historias de Usuario prioritarias a medida que se completan otros tickets.
Consejos para implementar agile en el delivery de producto
- Experimenta con diferentes frameworks Agile y adáptalos a las necesidades del equipo.
- Prepara presentaciones y demostraciones para la Sprint Review para evitar problemas en la presentación en vivo.
- No subestimes el valor de las retrospectivas; la mejora continua es clave para el éxito en Agile.
Para saber más: descarga nuestro libro Las Claves del Product Management
