Un recorrido por Scrum

¡Descubre el apasionante mundo de Scrum!

En el ámbito del desarrollo de proyectos, existe una metodología que ha revolucionado la forma en que se trabaja y se entregan resultados de manera ágil y eficiente.  Nos referimos a Scrum, un marco de trabajo que promueve la colaboración, la adaptabilidad y la entrega de valor continuo.

En este recorrido por Scrum, exploraremos desde sus fundamentos hasta sus aplicaciones prácticas, pasando por su historia, referentes y principales características.  Aprenderemos sobre la planificación del proyecto, la formación de equipos Scrum y la gestión de los artefactos clave como el Product Backlog y el Sprint Backlog.  También descubriremos los eventos fundamentales en el proceso Scrum, como el Sprint Planning, el Daily Scrum, la Sprint Review y la Sprint Retrospective.

Conoceremos los inconvenientes de Scrum y cómo abordarlos, así como su utilidad específica en el tercer sector.

¡Prepárate para descubrir cómo Scrum puede transformar tu forma de trabajar y llevarte a alcanzar resultados sorprendentes!

1. ¿Qué es Scrum?

Scrum es un marco de trabajo ágil utilizado principalmente en el desarrollo de software, aunque también se aplica en otros ámbitos.  Se basa en un enfoque colaborativo y adaptativo para gestionar proyectos complejos y fomentar la entrega continua de valor.  Scrum se centra en la flexibilidad, la transparencia y la mejora continua.

En Scrum, el trabajo se organiza en iteraciones llamadas «sprints«, que son períodos de tiempo fijos y cortos, generalmente de 1 a 4 semanas.  Durante cada sprint, se seleccionan las tareas más importantes y se trabaja en ellas de manera intensiva.  Al final de cada sprint, se entrega un incremento de producto potencialmente utilizable.

Scrum se basa en la inspección y adaptación continua.  Al final de cada sprint, se realiza un sprint review para revisar el trabajo completado y recibir feedback.  También se lleva a cabo un sprint retrospective para identificar mejoras y ajustes en el proceso.

La metodología Scrum se caracteriza por su enfoque iterativo e incremental, su capacidad para adaptarse a los cambios y su énfasis en la colaboración y la comunicación entre los miembros del equipo.

Promueve la transparencia en todos los niveles.  El equipo comparte información sobre el progreso, los impedimentos y los problemas a través de los artefactos y los eventos de Scrum.  La colaboración es esencial, ya que se fomenta el trabajo en equipo, la comunicación abierta y la toma de decisiones conjunta.

Reconoce que los requisitos y las circunstancias pueden cambiar durante el desarrollo del proyecto.  Por lo tanto, está diseñado para ser flexible y adaptable, permitiendo ajustes y cambios en función de la retroalimentación y los aprendizajes obtenidos durante el proceso.

Estas características Scrum contribuyen a su éxito en la gestión de proyectos al fomentar la entrega temprana de valor, la colaboración efectiva y la capacidad de adaptación a medida que se avanza en el proyecto.

Objetivo Entregar valor de manera rápida y constante, permitiendo a los equipos responder a los cambios y requerimientos del cliente de manera más ágil y eficiente.

2. Historia y evolución de Scrum

Scrum se ha convertido en una de las metodologías ágiles más populares y ha evolucionado a lo largo de los años, adaptándose a diferentes contextos y necesidades.  Algunos de los hitos más destacados en la historia y evolución de Scrum:

A principios de la década de 1980, Jeff Sutherland trabajaba en el campo del desarrollo de software en Easel Corporation.  Fue allí donde comenzó a experimentar con un enfoque iterativo e incremental para gestionar proyectos, centrándose en la entrega de valor al cliente de manera rápida y constante, en contraposición a los enfoques tradicionales de gestión de proyectos que se basaban en planes rígidos y entregas finales tardías.

Jeff se inspiró en varios métodos y enfoques existentes, como el Lean Manufacturing[1], el enfoque de equipos autónomos de Honda[2] y las ideas de calidad total de Deming[3].  Estos conceptos lo llevaron a desarrollar un marco de trabajo basado en iteraciones cortas, inspección y adaptación continua, y una mentalidad centrada en el valor del cliente.

A partir de estas experiencias y aprendizajes, Jeff Sutherland y Ken Schwaber, junto con otros profesionales, desarrollaron formalmente el marco de trabajo Scrum a mediados de la década de 1990.  Desde entonces, Scrum ha evolucionado y se ha convertido en una de las metodologías ágiles más populares y ampliamente adoptadas en el desarrollo de software y en otros ámbitos empresariales.

En «The New New Product Development Game«[4], escrito por Hirotaka Takeuchi y Ikujiro Nonaka de 1986 se analizan nuevos procesos de desarrollo utilizados en Japón y Estados Unidos (Canon, Xerox, Honda, HP y otros).  Los equipos que desarrollaron esos productos partían de requisitos muy generales, novedosos, y salían al mercado en mucho menos del tiempo del que se tardó en lanzar productos anteriores.  Estos equipos seguían patrones de ejecución de proyecto muy similares.  En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboración entre los jugadores de Rugby y su formación de Scrum (melé en español).

En 1993 se realizó el primer Scrum para desarrollo de software, Jeff Sutherland, John Scumniotales y Jeff McKenna concibieron, ejecutaron y documentaron el primer Scrum para desarrollo software, utilizando el estudio de gestión de equipos de Takeuchi y Nonaka como base.  1995 el proceso fue formalizado por Ken Schwaber para la industria de desarrollo de software.

En 2001, un grupo de desarrolladores y expertos en metodologías ágiles se reunieron para discutir y definir los principios y valores de los enfoques ágiles.  Este encuentro condujo a la creación del Manifiesto Ágil, un documento que establece los valores y principios clave de las metodologías ágiles.  Scrum fue reconocido como uno de los marcos de trabajo ágiles y se convirtió en uno de los más populares y ampliamente adoptados.

A partir de la década de 2000, Scrum experimentó un crecimiento significativo y una adopción global en diversos sectores y disciplinas, no solo en el desarrollo de software, sino también en la gestión de proyectos, la investigación científica, el marketing y otros campos.  Se han creado numerosas comunidades, certificaciones y recursos relacionados con Scrum para apoyar su implementación y práctica.

A medida que las metodologías ágiles continuaron evolucionando, se reconocieron las sinergias y complementariedades entre Scrum y otras prácticas ágiles.  Scrum se ha combinado con técnicas como Kanban[5], Lean Startup[6] y Design Thinking[7] para ofrecer enfoques más holísticos y adaptativos en la gestión de proyectos y productos.

Con el avance de la tecnología y el desarrollo de herramientas específicas para la gestión de proyectos ágiles, se ha facilitado la implementación y el seguimiento de Scrum.  Las herramientas de gestión de proyectos, tableros virtuales y software de colaboración en línea ofrecen funcionalidades diseñadas específicamente para respaldar la planificación, seguimiento y comunicación dentro de un marco Scrum.

Aunque Scrum se originó en el desarrollo de software, su aplicación se ha extendido a diferentes industrias y disciplinas.  Hoy en día, Scrum se utiliza en áreas como el marketing, la educación, el diseño de productos, la gestión de servicios y muchas más.  Esto demuestra la versatilidad y la aplicabilidad de Scrum en diversos contextos organizacionales.

La historia y evolución de Scrum muestran cómo ha pasado de ser una práctica emergente en el desarrollo de software a convertirse en un enfoque ágil ampliamente adoptado en diferentes industrias.  A lo largo de los años, se han realizado mejoras y adaptaciones para satisfacer las necesidades cambiantes de los proyectos y las organizaciones, lo que ha contribuido a su popularidad y éxito en la actualidad.

3. Principales referentes de Scrum

En el ámbito de Scrum, hay varios profesionales y expertos reconocidos que han desempeñado un papel clave en la difusión y promoción de esta metodología ágil.  A continuación, se presentan algunos de los principales referentes de Scrum:

Jeff Sutherland: Considerado uno de los cofundadores de Scrum, Jeff Sutherland ha sido una figura influyente en la evolución y promoción de esta metodología.  Es coautor del libro «Scrum: El el arte de hacer el doble de trabajo en la mitad de tiempo» y ha trabajado extensamente en la aplicación de Scrum en diversas organizaciones.

Ken Schwaber: Cofundador de Scrum, Ken Schwaber ha desempeñado un papel clave en la definición y desarrollo de la metodología.  Ha escrito varios libros sobre Scrum y es uno de los creadores del Professional Scrum Master (PSM) y del Professional Scrum Product Owner (PSPO), certificaciones reconocidas internacionalmente.

Mike Cohn: Autor de varios libros sobre Scrum, como «Agile Estimating and Planning» y «Succeeding with Agile«, Mike Cohn es un referente en la aplicación práctica de Scrum y la gestión ágil de proyectos.  Es fundador de Mountain Goat Software y ha brindado capacitación y consultoría en Scrum a numerosas organizaciones.

Roman Pichler: Reconocido autor y consultor en el ámbito de Scrum, Roman Pichler se especializa en la gestión ágil de productos y ha escrito libros como «Agile Product Management with Scrum«.  Sus enfoques y metodologías han sido ampliamente adoptados por profesionales que buscan una gestión de productos ágil y efectiva.

Alistair Cockburn: Aunque no está directamente relacionado con la creación de Scrum, Alistair Cockburn es un experto en metodologías ágiles y ha contribuido al desarrollo del Manifiesto Ágil.  Ha desarrollado el concepto de «Heart of Agile«, un enfoque simplificado para el éxito en proyectos ágiles, del cual Scrum es un componente clave.

Heart of Agile

El Heart of Agile es un enfoque simplificado y centrado en lo esencial de Agile (ágil) que busca sintetizar los valores y principios fundamentales detrás de Agile y aplicarlos de manera efectiva en cualquier contexto. El Heart of Agile se basa en cuatro palabras clave: Colaborar (Collaborate), Entregar (Deliver), Reflexionar (Reflect) y Mejorar (Improve).  Estas cuatro palabras representan las actividades centrales que se deben llevar a cabo para lograr resultados exitosos con Agile. Colaborar (Collaborate): Se refiere a la importancia de la colaboración efectiva entre las personas involucradas en el proyecto.  Esto implica la comunicación constante, la construcción de relaciones sólidas, el trabajo en equipo y la apertura a diferentes perspectivas.  La colaboración eficiente es esencial para lograr un enfoque ágil exitoso. Entregar (Deliver): Se enfoca en la entrega continua de valor al cliente.  En lugar de esperar hasta el final del proyecto para entregar resultados, Agile promueve la entrega incremental y frecuente de productos o funcionalidades.  Esto permite obtener retroalimentación temprana y realizar ajustes en el camino. Reflexionar (Reflect): Hace hincapié en la importancia de la reflexión y el aprendizaje continuo.  Agile promueve la realización de revisiones y retrospectivas periódicas para evaluar el progreso, identificar áreas de mejora y ajustar la forma de trabajar.  La reflexión constante ayuda a adaptarse a los cambios y maximizar el valor entregado. Mejorar (Improve): Se trata de buscar constantemente la mejora y el crecimiento.  Agile promueve la mentalidad de mejora continua, donde los equipos buscan formas de optimizar su trabajo, eliminar desperdicios y maximizar el valor para el cliente.  La mejora es un proceso iterativo que se basa en la retroalimentación y la experimentación. El Heart of Agile proporciona un enfoque simplificado y pragmático para aplicar los principios ágiles en cualquier proyecto o contexto.  Se centra en las actividades fundamentales que impulsan el éxito en Agile y sirve como recordatorio de los aspectos clave que deben ser atendidos en cualquier implementación ágil.

Estos referentes de Scrum han realizado importantes contribuciones a la metodología y han ayudado a difundir su adopción en diferentes industrias y organizaciones en todo el mundo.  Sus conocimientos y experiencias han sido fundamentales para el éxito y la evolución continua de Scrum.

4. Características de Scrum

Scrum utiliza un enfoque iterativo, dividiendo el proyecto en intervalos de tiempo llamados sprints.  Cada sprint tiene una duración fija, generalmente de 2 a 4 semanas.  Durante cada sprint, se selecciona un conjunto de elementos del Product Backlog para ser implementados.  El equipo trabaja en estos elementos de principio a fin, y al final del sprint, se obtiene un incremento potencialmente entregable del producto.

También utiliza un enfoque Incremental, con cada sprint, el producto se incrementa con nuevas funcionalidades o mejoras.  Cada incremento agrega valor al producto y está listo para ser entregado o demostrado a los interesados.  A medida que los sprints progresan, el producto se va construyendo gradualmente y se va enriqueciendo con nuevas funcionalidades en cada iteración.

Al final de cada sprint, se lleva a cabo un sprint review, donde se muestra el incremento del producto al equipo de desarrollo y a los interesados.  Durante esta revisión, se obtiene retroalimentación sobre el incremento y se pueden realizar ajustes en los siguientes sprints.  Esto permite un proceso de mejora continua, donde se adaptan y refinan los planes y requisitos según la retroalimentación recibida.

La naturaleza iterativa e incremental de Scrum ofrece varias ventajas significativas:

• Permite obtener resultados tangibles y potencialmente entregables en cortos períodos de tiempo.
• Facilita la adaptación a los cambios y la introducción de mejoras continuas en el producto.
• Proporciona una mayor visibilidad y transparencia del progreso del proyecto.
• Facilita la colaboración y la comunicación efectiva entre los miembros del equipo y los interesados.
• Permite una rápida retroalimentación del cliente y la validación temprana de las funcionalidades implementadas.
• Reduce los riesgos al abordar y mitigar los problemas de manera temprana en lugar de esperar hasta el final del proyecto.

En resumen, el enfoque iterativo e incremental de Scrum es fundamental para la flexibilidad, la adaptabilidad y la entrega continua de valor en el desarrollo de proyectos.  Permite un proceso ágil y colaborativo, donde el equipo puede ajustar y mejorar el producto de manera constante en función de las necesidades y los requisitos en evolución.

Terminología

Artefactos Elementos tangibles que se crean y utilizan durante el desarrollo de un proyecto. Estos artefactos son importantes para facilitar la transparencia, la comunicación y la colaboración entre los miembros del equipo Scrum	Eventos Son reuniones y actividades estructuradas que se llevan a cabo durante un sprint para facilitar la colaboración, la planificación y la entrega continua de valor. Estos eventos son oportunidades clave para que el equipo Scrum inspeccione, adapte y sincronice su trabajo
Product Backlog: Es una lista de elementos seleccionados del Product Backlog que se comprometen a completar durante un sprint específico.  Contiene las tareas y actividades detalladas necesarias para desarrollar el incremento del producto	Sprint: Ciclo de ejecución en tiempo corto y fijo (de 1 a 4 semanas).  El resultado de cada Sprint es un producto usable y la iteración de Sprint da lugar a incrementos del producto hasta llegar al producto final.
Sprint Backlog: Conjunto de elementos del PB que seleccionamos para un Sprint.  Incluye también cada incremento del producto para conseguir el objetivo.	Sprint Planning:  Es una reunión al inicio de cada sprint donde el equipo Scrum define los objetivos y selecciona las tareas a realizar durante el sprint.  Se establece el Sprint Backlog.
Incremento: Es el resultado del trabajo realizado durante un sprint.  Es un producto potencialmente entregable que cumple con los criterios de aceptación establecidos.	Daily Scrum: Es una reunión breve y diaria en la que el equipo Scrum sincroniza su trabajo.  Cada miembro comparte qué hizo ayer, qué planea hacer hoy y si hay algún obstáculo.  El objetivo es mantener a todos alineados y facilitar la colaboración.
Definition of Done: Es un conjunto de criterios claros y acordados que establecen cuándo se considera que un elemento del Product Backlog está terminado y es potencialmente entregable.	Sprint Review: Es una reunión al finalizar el sprint donde el equipo Scrum presenta el incremento desarrollado durante el sprint a los stakeholders.  Se revisa el trabajo completado y se recopilan comentarios y sugerencias para la siguiente iteración.
	Sprint Retrospective: Es una reunión al finalizar el sprint donde el equipo Scrum reflexiona sobre su desempeño y busca mejoras.  Se analizan los procesos, las prácticas y las relaciones de trabajo, y se definen acciones para optimizar el próximo sprint.

5. Aplicación práctica de Scrum

Para aplicar Scrum de manera práctica, se deben seguir varios pasos. Primero, se debe formar un equipo Scrum y establecer los roles y responsabilidades.  Luego, se realiza una planificación inicial del proyecto y se crea un producto backlog.  A medida que el proyecto avanza, se llevan a cabo sprints, incluyendo daily scrum y sprint review.  La retroalimentación y la mejora continua son elementos clave en cada paso del proceso.

Tomado de https://www.scrum.org/learning-series/what-is-scrum

5.1. La planificación del proyecto

La planificación inicial de un proyecto es una etapa crucial para establecer una base sólida y definir los objetivos, el alcance y los recursos necesarios y los tiempos.  El Product Owner trabaja en colaboración con el equipo para establecer los objetivos del proyecto y crear el Product Backlog.

Ejemplo de Planificación Inicial

Proyecto: Desarrollo de una aplicación móvil de gestión de tareas Definición de objetivos:  Crear una aplicación móvil intuitiva y fácil de usar para gestionar tareas y proyectos. Proporcionar una interfaz amigable y atractiva para los usuarios. Implementar funcionalidades clave, como la creación de tareas, asignación de responsables, seguimiento de avance y recordatorios. Identificación del Product Owner: Representante del departamento de gestión de proyectos, será el Product Owner. Será responsable de definir y priorizar los requisitos del producto, así como de tomar decisiones clave durante el desarrollo. Formación del Equipo Scrum: Desarrollador 1 Desarrollador 2 Diseñador Tester Definición del Product Backlog: Se encargará de recopilar los requisitos y crear el Product Backlog, que incluirá todas las funcionalidades y características deseadas para la aplicación. El Product Backlog se ordenará en función de la prioridad y se mantendrá actualizado a lo largo del proyecto. Duración del Sprint: Se acuerda que cada sprint tendrá una duración de 2 semanas. Esto proporcionará un marco de tiempo adecuado para desarrollar y entregar incrementos del producto de manera regular. Planificación del primer Sprint: El equipo se reúne para seleccionar las historias de usuario de mayor prioridad del Product Backlog para el primer sprint. Las historias de usuario se descomponen en tareas más pequeñas y se estiman los esfuerzos necesarios para completarlas. Sprint Backlog: Se crea el Sprint Backlog, que contiene todas las tareas identificadas para el primer sprint. Cada tarea se asigna a un miembro del equipo, teniendo en cuenta las habilidades y disponibilidad de cada uno. Reuniones diarias: El equipo acuerda realizar reuniones diarias de 15 minutos para compartir el progreso, identificar cualquier obstáculo y planificar el trabajo del día siguiente. Entrega del incremento: Al finalizar el primer sprint, se entrega el incremento del producto, que incluye las funcionalidades completadas durante ese período.

5.2. Formar un equipo Scrum

Reúne a un equipo multidisciplinario de profesionales que trabajarán juntos en el proyecto.  Define claramente los roles y las responsabilidades de cada miembro del equipo.  Scrum define tres roles principales:

• Product Owner: Es el responsable de definir y priorizar los requisitos del producto, representando los intereses de los stakeholders y asegurando que se desarrolle un producto de alto valor.
• Scrum Master: Es el facilitador del equipo Scrum, se encarga de asegurar que se cumplan los principios y prácticas de Scrum, y ayuda a resolver obstáculos que puedan surgir durante el proyecto.
• Equipo de Desarrollo: Son los profesionales que realizan el trabajo para entregar el producto. Son autónomos y autoorganizados, responsables de planificar, diseñar, implementar y probar las funcionalidades.

En algunos casos, dependiendo de la complejidad y tamaño del proyecto, pueden surgir otros roles adicionales para satisfacer las necesidades específicas del equipo y del producto.  Algunos de estos roles adicionales pueden ser

• Scrum Team Extensions roles adicionales dentro del equipo de Scrum para manejar tareas específicas, como especialistas en seguridad, expertos en experiencia de usuario (UX) o arquitectos.
• Scrum of Scrums, en proyectos de gran escala que involucran múltiples equipos de desarrollo, puede existir un rol de Scrum of Scrums. Esta persona o grupo se encarga de coordinar y comunicarse entre los diferentes equipos Scrum para abordar desafíos y asegurar la colaboración efectiva.

Una vez que se han definido las tareas, el equipo las asigna a los miembros responsables de su ejecución. Cada miembro del equipo asume la responsabilidad de completar las tareas asignadas y colabora con otros miembros cuando sea necesario.

Ejemplo Equipo Scrum

Equipo Scrum: Desarrollo de un sistema de gestión de proyectos Roles y responsabilidades: Product Owner (PO) Responsable de gestionar y priorizar el Product Backlog. Define los requisitos del producto y los objetivos. Toma decisiones sobre el alcance y las características del producto. Trabaja en estrecha colaboración con el equipo de desarrollo y los stakeholders. Scrum Master (SM). Facilita el proceso Scrum y promueve las buenas prácticas. Ayuda al equipo a comprender y aplicar los principios de Scrum. Elimina obstáculos y protege al equipo de interrupciones externas. Organiza las reuniones y fomenta la mejora continua. Equipo de Desarrollo: Desarrollador 1. Desarrollador 2. Desarrollador 3. Responsabilidades: Desarrollar y entregar el incremento del producto en cada sprint. Estimar el esfuerzo y la complejidad de las tareas. Colaborar estrechamente con el Product Owner para comprender los requisitos. Participar en las reuniones diarias, la planificación del sprint y las retrospectivas.

5.3. Product Backlog

El Product Backlog es una lista priorizada de todas las funcionalidades, características, mejoras y requisitos del producto.  El Product Backlog se mantiene y gestiona por el Product Owner, quien es responsable de asegurar que esté actualizado y refleje las necesidades y prioridades del negocio.  Los elementos del Product Backlog se desglosan en ítems más pequeños y detallados a medida que se acerca su implementación.

Ejemplo de Product Backlog

1.      Registro de usuarios: Los usuarios podrán registrarse en la plataforma utilizando su dirección de correo electrónico y una contraseña segura. 2.      Inicio de sesión de usuarios: Los usuarios podrán iniciar sesión en la plataforma utilizando su dirección de correo electrónico y contraseña. 3.      Creación de perfiles de usuario: Los usuarios podrán crear perfiles personalizados, agregando información como nombre, foto de perfil y descripción. 4.      Búsqueda de usuarios: Los usuarios podrán buscar a otros usuarios dentro de la plataforma utilizando filtros como nombre, ubicación o intereses. 5.      Publicación de contenido: Los usuarios podrán crear publicaciones de texto, imágenes o videos para compartir con otros usuarios. 6.      Comentarios en publicaciones: Los usuarios podrán comentar las publicaciones de otros usuarios y participar en conversaciones. 7.      Funcionalidad de «Me gusta«: Los usuarios podrán dar «Me gusta» a las publicaciones de otros usuarios para mostrar su aprecio. 8.      Sistema de notificaciones: Los usuarios recibirán notificaciones en tiempo real sobre actividades relevantes, como nuevos seguidores o comentarios en sus publicaciones. 9.      Integración de redes sociales: Los usuarios podrán conectar sus perfiles de la plataforma con sus cuentas en redes sociales como Facebook y Twitter. 10.   Configuración de privacidad: Los usuarios podrán ajustar la configuración de privacidad para controlar quién puede ver su perfil y sus publicaciones.

5.4 Sprint

El desarrollo de un Sprint en Scrum implica una serie de actividades y pasos que se llevan a cabo durante un periodo de tiempo fijo, que generalmente oscila entre 1 y 4 semanas.  Todo el trabajo necesario para alcanzar el Product Backlog, incluyendo la Sprint Planning, Daily Scrums, Sprint Review y Sprint Retrospective, ocurren dentro del Sprints

5.4.1. Sprint Planning

Estas reuniones marcan el inicio de cada sprint, que es un período de tiempo fijo en el que se realiza el trabajo.  Durante el Sprint Planning, el equipo selecciona elementos del Product Backlog que se trabajarán durante el sprint.  Estos elementos se basan en la prioridad establecida por el Product Owner y representan el trabajo que se realizará durante el sprint.  Esta selección es el Sprint Backlog.

Ejemplo de Sprint Planning

Reunión de Sprint Planning: Duración: 2 horas (para un Sprint de 2 semanas) Participantes: Product Owner y Equipo de Desarrollo Definición del Objetivo del Sprint: El Product Owner comparte la visión del producto y establece el objetivo específico para el Sprint en función de las prioridades del Product Backlog y las necesidades del cliente. Selección de Elementos del Product Backlog: El Product Owner y el Equipo de Desarrollo revisan juntos el Product Backlog y seleccionan los elementos que se abordarán durante el Sprint, teniendo en cuenta la capacidad del equipo y la prioridad de los elementos. Creación del Sprint Backlog: El Equipo de Desarrollo descompone los elementos seleccionados en tareas más pequeñas y las estima en términos de esfuerzo y tiempo requeridos. Se crea el Sprint Backlog, que es una lista de tareas específicas que el equipo se compromete a completar durante el Sprint. Estimación del esfuerzo: El Equipo de Desarrollo estima el esfuerzo necesario para completar cada tarea utilizando técnicas como el Planning Poker o puntos de historia. Asignación de tareas: El Equipo de Desarrollo se asigna las tareas que pueden manejar durante el Sprint, teniendo en cuenta las habilidades y la carga de trabajo de cada miembro. Definición de «Terminado«: El Equipo de Desarrollo establece los criterios claros que deben cumplir las tareas para considerarse «terminadas» al final del Sprint. Establecimiento de un Plan de Sprint: El Equipo de Desarrollo acuerda la duración del Sprint y establece un calendario y una secuencia de actividades para llevar a cabo las tareas durante el período de tiempo del Sprint.

5.4.2. Sprint Backlog

El Sprint Backlog es una lista de elementos seleccionados del Product Backlog que el equipo de desarrollo se compromete a completar durante un Sprint en particular.  El Sprint Backlog es creado por el equipo de desarrollo durante la Sprint Planning y contiene todas las tareas y actividades necesarias para entregar los elementos seleccionados.  Es un plan viviente que se actualiza y ajusta durante el Sprint según las necesidades emergentes.

Ejemplo de Sprint Backlog – Semana 1

1.      Registro de usuarios: Implementar la funcionalidad de registro de usuarios, incluyendo validación de correo electrónico y almacenamiento de datos en la base de datos. 2.      Inicio de sesión de usuarios: Desarrollar el proceso de inicio de sesión de usuarios, verificando las credenciales y permitiendo el acceso a la plataforma. 3.      Creación de perfiles de usuario: Diseñar la interfaz de usuario y desarrollar la lógica para que los usuarios puedan crear perfiles personalizados. 4.      Búsqueda de usuarios: Implementar la funcionalidad de búsqueda de usuarios, permitiendo a los usuarios encontrar a otros usuarios utilizando filtros de búsqueda. 5.      Pruebas de rendimiento: Realizar pruebas de carga y rendimiento para asegurar que la plataforma pueda manejar una cantidad significativa de usuarios concurrentes. 6.      Diseño de la interfaz de usuario: Trabajar en el diseño visual y la experiencia de usuario de la plataforma, asegurando una interfaz atractiva y fácil de usar. 7.      Configuración de privacidad: Desarrollar la funcionalidad de configuración de privacidad, permitiendo a los usuarios controlar la visibilidad de su perfil y sus publicaciones. 8.      Pruebas de aceptación: Realizar pruebas exhaustivas para garantizar que todas las funcionalidades implementadas cumplan con los criterios de aceptación establecidos. 9.      Documentación del sprint: Actualizar la documentación del sprint, incluyendo los avances realizados, los impedimentos encontrados y las lecciones aprendidas.

5.4.3. Daily Scrum

Las Daily Scrum son breves encuentros diarios en los que el equipo de Scrum se sincroniza sobre el progreso y los próximos pasos.  Cada miembro del equipo responde a tres preguntas clave: ¿Qué hice ayer?, ¿Qué haré hoy? y ¿Hay algún impedimento que me impida avanzar?  Estas reuniones son clave para mantener a todos alineados y abordar los desafíos de manera oportuna.

Ejemplo de Daily Scrum

Equipo Scrum: Desarrollo de un nuevo sitio web Fecha: 10 de mayo de 2023 Duración de la reunión: 15 minutos Participantes: Scrum Master. Product Owner. Desarrollador 1. Desarrollador 2. Desarrollador 3. Agenda de la reunión: Comienza la reunión puntualmente a las 9:00 a.m. Cada miembro del equipo responde a las tres preguntas clave: ¿Qué hiciste ayer? ¿Qué harás hoy? ¿Hay algún impedimento o bloqueo? Ejemplo de la reunión: Scrum Master: Buenos días a todos. Comencemos la reunión diaria. Pedro, ¿puedes empezar? Desarrollador 2: Claro. Ayer terminé la implementación del formulario de contacto y comencé a trabajar en la página de inicio. Hoy continuaré con la página de inicio y espero terminarla. Desarrollador 1: Ayer trabajé en la optimización del rendimiento del sitio web y resolví algunos problemas de carga. Hoy me enfocaré en la mejora de la accesibilidad del sitio. Desarrollador 3: Ayer estuve investigando nuevas tecnologías para implementar en el sitio web. Hoy comenzaré a trabajar en la integración de la API de pagos. Product Owner: Excelente. No tengo ningún impedimento en este momento. Scrum Master: Perfecto. Continuemos avanzando en nuestras tareas y asegurémonos de comunicarnos si encontramos algún bloqueo. ¡Buena suerte a todos! La Daily Scrum tiene como objetivo proporcionar una actualización rápida y sincronizar al equipo en cuanto a lo que cada miembro está haciendo, lo que planea hacer y si hay algún obstáculo en su camino. Es importante que la reunión se realice en un ambiente colaborativo y que se mantenga enfocada en los puntos clave para que no se prolongue innecesariamente.

5.4.4. Trabajo en el Sprint Backlog

El equipo trabaja en las tareas y actividades definidas en el Sprint Backlog. Cada miembro del equipo se enfoca en completar sus tareas asignadas y colabora de cerca con los demás miembros para lograr el objetivo del Sprint.

Durante el Sprint, es esencial mantener una comunicación y colaboración continua dentro del equipo Scrum. Esto incluye la resolución de problemas, la clarificación de requisitos, la coordinación de actividades y la adaptación a los cambios que puedan surgir.

5.4.5. Sprint Review

Al final de cada sprint, se lleva a cabo una Sprint Review para presentar el trabajo completado al Product Owner y a los stakeholders.  Durante esta reunión, el equipo muestra las funcionalidades desarrolladas y el Product Owner y los stakeholders proporcionan retroalimentación y se discute la planificación para el siguiente sprint.  Se pueden realizar demostraciones, presentaciones y discusiones interactivas

Ejemplo Sprint Review

Equipo Scrum: Desarrollo de un nuevo sitio web Fecha: 15 de mayo de 2023 Duración de la reunión: 1 hora Participantes: Scrum Master. Product Owner. Desarrollador 1. Desarrollador 2. Desarrollador 3. Stakeholder 1: Representante del área de Marketing Stakeholder 2: Representante del área de Ventas Agenda de la reunión: Bienvenida y presentación (5 minutos) Scrum Master da la bienvenida a los participantes y presenta el objetivo de la reunión. Resumen del sprint (10 minutos) Scrum Master repasa los objetivos del sprint y recuerda los elementos del Sprint Backlog que se comprometieron a entregar. Demostración del incremento (30 minutos) Los miembros del equipo, especialmente los desarrolladores, realizan una demostración del incremento del producto desarrollado durante el sprint. Muestran las nuevas funcionalidades implementadas y explican cómo se alinean con las necesidades del cliente y los objetivos del proyecto. Retroalimentación y discusión (15 minutos) Los stakeholders presentes brindan su retroalimentación sobre las funcionalidades mostradas y hacen preguntas al equipo. Se genera una discusión constructiva para aclarar dudas y obtener más información sobre las necesidades del cliente. Revisión del Product Backlog (10 minutos) Product Owner revisa el Product Backlog y discute con el equipo si es necesario realizar ajustes o agregar nuevas historias de usuario basadas en la retroalimentación recibida. Cierre y siguientes pasos (5 minutos) Scrum Master agradece a los participantes por su asistencia y resalta los próximos pasos, como la planificación del próximo sprint y cualquier otra acción derivada de la reunión. Es importante destacar que la Sprint Review es una oportunidad para mostrar los avances y recibir comentarios valiosos de los stakeholders.  Se busca validar y ajustar el producto en función de las necesidades del cliente y las metas del proyecto.  La colaboración y la retroalimentación son fundamentales para mejorar continuamente y garantizar la satisfacción del cliente.

5.4.6. Sprint Retrospective

Después de la Sprint Review, se realiza una Sprint Retrospective.  En esta reunión, el equipo reflexiona sobre su desempeño durante el sprint y busca formas de mejorar.  Se identifican las prácticas que funcionaron bien y las que deben ajustarse.  La Sprint Retrospective es esencial para fomentar el aprendizaje continuo y la mejora en futuros sprints.  Pueden utilizarse técnicas como el «comenzar, parar, continuar» o el «Contento, triste, Enojado» para recopilar los comentarios del equipo.

Ejemplo Retrospectivas del sprint

Equipo Scrum: Desarrollo de un nuevo sistema de gestión de proyectos Fecha: 30 de abril de 2023 Duración de la reunión: 1 hora Participantes: Scrum Master. Product Owner. Desarrollador 1. Desarrollador 2. Desarrollador 3. Agenda de la reunión: Bienvenida y establecimiento del objetivo (5 minutos) Scrum Master da la bienvenida a los participantes y establece el objetivo de la retrospectiva: identificar los aspectos positivos y las oportunidades de mejora del sprint que acaba de finalizar. Recopilación de datos (10 minutos) Cada miembro del equipo anota en notas adhesivas los aspectos positivos y los problemas que experimentaron durante el sprint. Se pegan las notas en un tablero visible para su posterior discusión. Discusión en grupo (30 minutos) El equipo revisa las notas adhesivas en el tablero y discute los aspectos positivos y los problemas identificados. Se anima a los miembros del equipo a compartir sus opiniones y perspectivas. Priorización y generación de acciones (10 minutos) El equipo prioriza los elementos más relevantes y decide sobre las acciones a tomar para mejorar en el próximo sprint. Se asignan responsables y se establecen plazos para cada acción. Cierre y siguientes pasos (5 minutos) Scrum Master resume los puntos clave discutidos y agradece la participación de todos. Se acuerda seguir el plan de acción establecido y se programan las fechas para la próxima retrospectiva del sprint. Es importante destacar que la Sprint Retrospective es un espacio seguro y abierto donde el equipo tiene la oportunidad de reflexionar sobre su trabajo y buscar continuamente formas de mejorar.  Se fomenta la transparencia, la colaboración y la honestidad para crear un ambiente propicio para el aprendizaje y el crecimiento del equipo.

5.4.7. Incrementos de producto

Durante el sprint, el equipo trabaja en la implementación de los elementos seleccionados del Product Backlog.  Al finalizar el sprint, se entrega un incremento de producto funcional que puede ser revisado y evaluado por el Product Owner y los stakeholders.  Es la suma de todos los elementos del Product Backlog completados durante un Sprint, junto con los incrementos de todos los Sprints anteriores.  El Incremento debe ser «Potencialmente Entregable«, lo que significa que es importante realizar pruebas y revisiones de calidad para asegurarse de que el incremento de producto cumple con los estándares y requisitos establecidos.  Cada Incremento agrega valor al producto y se basa en el trabajo previo realizado.

Ejemplo de Incremento de producto funcional

Supongamos que estás trabajando en el desarrollo de una aplicación de gestión de tareas y el incremento del sprint actual incluye las siguientes funcionalidades: 1.     Creación de tareas: Los usuarios pueden crear nuevas tareas asignándoles un título, descripción y fecha de vencimiento. 2.     Asignación de tareas: Los usuarios pueden asignar tareas a otros miembros del equipo, lo que implica seleccionar el responsable de la tarea y establecer una fecha límite. 3.     Estado de las tareas: Se ha implementado la funcionalidad para que los usuarios puedan marcar una tarea como «pendiente», «en progreso» o «completada». También se muestra visualmente el estado actual de cada tarea. 4.     Notificaciones: Los usuarios reciben notificaciones por correo electrónico cuando se les asigna una nueva tarea o cuando una tarea que han creado o asignado se actualiza. 5.     Lista de tareas filtrable: Los usuarios pueden aplicar filtros a la lista de tareas para ver únicamente las tareas asignadas a ellos, las tareas completadas o las tareas pendientes. 6.     Interfaz de usuario mejorada: Se han realizado mejoras en la interfaz de usuario para que sea más intuitiva y fácil de usar, incluyendo cambios en los colores, iconos y disposición de elementos. Este incremento del sprint representa un conjunto de funcionalidades completas y listas para su entrega.  Cada incremento debe ser «potencialmente entregable«, lo que significa que debe estar en un estado en el que pueda ser demostrado y utilizado por los usuarios finales, aunque puede no incluir todas las funcionalidades deseadas del producto final.

6. Algunas herramientas complementarias

6.1. Definition of Done (Definición de Hecho)

Es un conjunto de criterios acordados por el equipo de desarrollo que establecen los estándares de calidad y las condiciones que deben cumplirse para considerar que un elemento del Product Backlog está «hecho«.  La Definition of Done asegura que los elementos entregados cumplan con los estándares de calidad y se ajusten a las expectativas del cliente y del negocio.

Ejemplo de Definition of Done

Definition of Done para un equipo de desarrollo de software: 1.     Todas las historias de usuario están completas y han pasado las pruebas unitarias. 2.     Las pruebas de integración se han realizado y han pasado satisfactoriamente. 3.     Se han realizado pruebas de aceptación y han sido aprobadas por el cliente o el product owner. 4.     Se ha realizado la revisión de código y se han abordado todas las revisiones y comentarios pertinentes. 5.     Se ha realizado la documentación necesaria, como documentación del código, manuales de usuario y guías de implementación. 6.     Se han corregido todos los errores y problemas conocidos. 7.     Se han realizado pruebas de rendimiento y se ha verificado que el software funciona de manera eficiente. 8.     El código ha sido revisado y aprobado por el equipo de calidad o de control de calidad. 9.     Se ha llevado a cabo una demostración exitosa del incremento ante el equipo, el cliente o el product owner. 10.  El incremento está listo para ser desplegado en el entorno de producción.

6.2. Burn-Down Chart

Es una herramienta visual que muestra el progreso del trabajo en un sprint o en el proyecto en general.  Se utiliza para rastrear y comunicar la cantidad de trabajo restante en relación con el tiempo disponible.

Ejemplo de Burn-Down Chart[8]

6.3. Definition of Ready (DoR)

Es una descripción acordada de los criterios que un elemento del Product Backlog debe cumplir antes de ser considerado listo para ser seleccionado en un sprint.  Estos criterios ayudan a garantizar que el equipo tenga toda la información y los recursos necesarios para trabajar de manera efectiva en el elemento y para evitar retrasos o problemas durante el sprint.  Cada equipo puede adaptar la Definition of Ready según sus necesidades y requisitos específicos.

Ejemplo de Definition of Ready (DoR)

1.      La descripción del elemento del Product Backlog está clara y comprensible para el equipo. 2.      Todos los criterios de aceptación y requisitos del elemento están definidos y documentados. 3.      Los stakeholders relevantes han revisado y aprobado los requisitos del elemento. 4.      El elemento del Product Backlog tiene una estimación de tamaño o esfuerzo. 5.      Todas las dependencias y recursos necesarios para completar el elemento están identificados y disponibles. 6.      El elemento del Product Backlog está priorizado adecuadamente en función de su valor y necesidades del negocio. 7.      El equipo tiene la capacidad y los recursos necesarios para abordar el elemento de manera efectiva. 8.      El elemento del Product Backlog cumple con los estándares de calidad y requisitos técnicos establecidos. 9.      El elemento del Product Backlog ha sido revisado y aceptado por el product owner.

6.4. Planning Poker

Esta dinámica se utiliza para estimar el esfuerzo necesario para completar las tareas.  Cada miembro del equipo recibe un conjunto de cartas numeradas que representan diferentes niveles de esfuerzo.  Se presenta una tarea y, simultáneamente, todos los miembros seleccionan la carta que consideran que representa mejor el esfuerzo requerido. Luego, se comparan las cartas y se discuten las diferencias hasta llegar a un consenso.

Planning Poker

Reunir al equipo: Se reúne el equipo Scrum, que incluye a los desarrolladores, el Scrum Master y el Product Owner. Cada miembro del equipo necesita un mazo de cartas de Planning Poker. Presentación de la historia de usuario: El Product Owner presenta una historia de usuario o tarea del Product Backlog que debe ser estimada. La historia de usuario debe estar bien definida y comprensible para todos los miembros del equipo. Explicación de las cartas: Se explica a todos los miembros del equipo el significado de las cartas de Planning Poker. Por lo general, se utilizan cartas con valores numéricos que representan la complejidad o el esfuerzo estimado, como 1, 2, 3, 5, 8, 13, 20, etc. También se incluye una carta con el símbolo «?» para casos de incertidumbre y una carta con el símbolo «infinito» para casos extremadamente complejos. Ronda de estimaciones: Se selecciona una historia de usuario y cada miembro del equipo elige una carta que representa su estimación de esfuerzo o complejidad para esa historia. Las cartas se mantienen boca abajo hasta que todos los miembros hayan elegido su carta. Revelación de las cartas: Una vez que todos han elegido su carta, las cartas se revelan simultáneamente. Si las estimaciones son similares, se toma ese valor como estimación. Si hay discrepancias significativas, se inicia una discusión para comprender los puntos de vista y las razones detrás de las diferentes estimaciones. Discusión y consenso: Si hay discrepancias, se anima al equipo a discutir y compartir sus perspectivas para llegar a un consenso sobre la estimación. Se pueden hacer preguntas, aclaraciones o proponer cambios en la definición de la historia de usuario para llegar a un entendimiento común. Repetir el proceso: Se repiten los pasos del 2 al 6 para cada historia de usuario o tarea del Product Backlog que se estime.

6.5. Pair Programming

Esta dinámica implica que dos miembros del equipo trabajen juntos en la implementación de una tarea.  Uno actúa como conductor (quien escribe el código) y el otro como observador o revisor.  Ambos colaboran estrechamente, intercambian ideas y se aseguran de que el código cumpla con los estándares de calidad establecidos.

Pair Programming

Selección de los miembros del par: Dos programadores son seleccionados para trabajar en conjunto como un par. Pueden ser dos desarrolladores con diferentes niveles de experiencia o habilidades complementarias. Definición del rol del «conductor» y el «observador»: Uno de los miembros del par asume el rol de «conductor», quien es responsable de escribir el código y tomar las decisiones en ese momento. El otro miembro asume el rol de «observador», quien revisa y ofrece comentarios sobre el código escrito. Comunicación constante: El par de programadores se comunica de manera continua durante todo el proceso. Explican sus pensamientos, comparten ideas y resuelven problemas juntos. Esto puede incluir discusiones sobre el diseño de la solución, la elección de algoritmos o la identificación de posibles errores. Rotación de roles: A intervalos regulares, los miembros del par pueden rotar los roles de «conductor» y «observador». Esto permite que ambos programadores estén involucrados en la toma de decisiones y en la escritura del código. Enfoque en la calidad del código: Durante el Pair Programming, el par se asegura de que el código producido cumpla con los estándares de calidad establecidos. Ambos revisan y verifican la calidad del código, realizan pruebas y se aseguran de que esté correctamente documentado.

6.6. Fishbowl Technique (Pecera)

Esta dinámica es útil para facilitar discusiones profundas y fomentar la participación equitativa de todos los miembros del equipo.  Consiste en formar dos círculos concéntricos: en el círculo interior se encuentran los participantes activos que discuten un tema específico, y en el círculo exterior se encuentran los observadores que escuchan atentamente.  Los observadores pueden ingresar al círculo interior para unirse a la discusión en cualquier momento, mientras que un participante activo debe salir al círculo exterior. Esto permite un flujo dinámico de ideas y una participación equilibrada.

Fishbowl Technique

Preparación: Selecciona un tema o pregunta de debate relevante para el grupo. Por ejemplo, podrías elegir «Estrategias para mejorar la comunicación en el equipo de trabajo». Formación del círculo exterior: Organiza a los participantes en un círculo exterior alrededor del grupo principal, que se asemeja a una pecera. Los participantes en el círculo exterior serán los observadores. Establecimiento de las reglas: Explica las reglas de la Fishbowl Technique. Por ejemplo, podrías establecer que solo los participantes dentro de la «pecera» pueden hablar, mientras que los observadores en el círculo exterior deben escuchar atentamente. Comienzo de la discusión: Invita a un número limitado de participantes, por ejemplo, 4 o 5 personas, a sentarse en el círculo interior, que representa el grupo de discusión principal. Desarrollo de la discusión: Los participantes en el círculo interior comienzan a debatir el tema propuesto. Pueden compartir ideas, experiencias y perspectivas sobre el tema. Mientras tanto, los observadores en el círculo exterior escuchan atentamente y toman notas de los puntos relevantes. Rotación de los participantes: Después de un tiempo determinado, por ejemplo, 10 minutos, puedes rotar a un participante del círculo exterior al círculo interior, y uno del círculo interior pasa al círculo exterior. Esto permite que nuevos participantes compartan sus opiniones y enriquezcan la discusión. Continuación de la discusión: La discusión continúa con el nuevo grupo de participantes en el círculo interior. Los observadores en el círculo exterior continúan escuchando y tomando notas. Conclusión y reflexión: Después de varias rondas de rotación, se concluye la discusión. Puedes permitir que los observadores compartan sus observaciones y reflexiones sobre el debate.

6.7. Retrospectiva del equipo visual

Esta dinámica se basa en la creación de un mural o pizarra visual en la que el equipo puede expresar sus pensamientos y emociones sobre el sprint.  Puedes utilizar papeles adhesivos de diferentes colores para representar aspectos positivos, negativos o mejorables del sprint.  Los miembros del equipo pueden escribir sus comentarios y pegarlos en el mural. Posteriormente, se realiza una discusión grupal para explorar los temas presentados y tomar medidas para la mejora continua.

Retrospectiva del equipo visual

Preparación: Antes de la retrospectiva, prepara un espacio visual para capturar las ideas y conclusiones del equipo. Puedes utilizar un pizarrón, una pizarra blanca o un mural en la pared. Creación de categorías: Divide el espacio visual en secciones o categorías relevantes para la retrospectiva. Por ejemplo, podrías tener secciones como «Fortalezas del equipo», «Desafíos», «Ideas de mejora» y «Acciones a tomar». Captura de ideas: Invita a los miembros del equipo a escribir sus ideas, comentarios y reflexiones en notas adhesivas de diferentes colores. Cada miembro del equipo puede agregar sus notas adhesivas en las secciones correspondientes del espacio visual. Discusión en grupo: Una vez que todos los miembros del equipo hayan agregado sus notas adhesivas, comienza una discusión en grupo. Cada miembro puede compartir sus ideas, explicar el contenido de sus notas y debatir sobre los temas relevantes. Agrupación de ideas: A medida que se discuten las ideas, busca patrones y similitudes entre las notas adhesivas. Puedes agrupar las ideas similares juntas y etiquetar cada grupo con una breve descripción. Identificación de acciones: A partir de las ideas agrupadas, trabaja en conjunto con el equipo para identificar acciones concretas y específicas que puedan llevarse a cabo para mejorar el trabajo y la colaboración. Anota estas acciones en la sección correspondiente del espacio visual. Acuerdo y compromiso: Al final de la retrospectiva, revisa las acciones identificadas y asegúrate de que todos los miembros del equipo estén de acuerdo y comprometidos con su implementación. Esto puede incluir asignar responsabilidades y establecer fechas límite. Seguimiento: Una vez finalizada la retrospectiva, asegúrate de dar seguimiento a las acciones acordadas en futuras reuniones y evaluar su progreso y efectividad.

6.8. Comenzar, Parar, Continuar

Es una herramienta de retroalimentación y mejora utilizada en diversos contextos, como equipos de trabajo, proyectos o procesos. Consiste en identificar y analizar acciones o comportamientos específicos y decidir si se deben comenzar, parar o continuar.

Comenzar: En esta parte de la técnica, se identifican las acciones o comportamientos que aún no se están llevando a cabo pero que se considera que serían beneficiosos para el equipo o el proyecto. Estas nuevas acciones se inician como una forma de mejorar o resolver un problema.

Parar: Aquí se identifican las acciones o comportamientos existentes que se considera que no están aportando valor o están causando dificultades. Estas acciones se detienen o se eliminan para evitar problemas futuros o para liberar recursos que pueden ser utilizados de manera más eficiente.

Continuar: En esta etapa, se destacan las acciones o comportamientos que están funcionando bien y aportando resultados positivos. Estas acciones se siguen llevando a cabo y se refuerzan para mantener y mejorar los resultados obtenidos.

Comenzar, Parar, Continuar

1.     Preparación: Reúne al equipo en un espacio tranquilo y asegúrate de que todos los miembros estén presentes. Proporciona una pizarra, un tablero o una herramienta de colaboración en línea donde puedas registrar las ideas del equipo. Explica brevemente el propósito de la técnica y cómo se llevará a cabo. 2.     Fase de «Comenzar»: Pide al equipo que piense en aspectos o prácticas que les gustaría comenzar a implementar en su trabajo. Cada miembro del equipo puede escribir en tarjetas o agregar notas en la herramienta colaborativa sus ideas para comenzar. Anima a todos a participar y expresar sus opiniones sin restricciones. 3.     Fase de «Parar»: Invita al equipo a reflexionar sobre las cosas que no están funcionando o que deberían detenerse en su trabajo actual. Cada miembro del equipo puede compartir en tarjetas o notas sus ideas sobre qué acciones o prácticas deberían parar. Fomenta un ambiente abierto y respetuoso donde se puedan discutir abiertamente los puntos de vista y las preocupaciones. 4.     Fase de «Continuar»: Pide al equipo que identifique las prácticas, acciones o aspectos positivos que están funcionando bien y que deberían continuar. Cada miembro del equipo puede agregar sus ideas de lo que les gustaría mantener o seguir haciendo. Anima a destacar los éxitos y los logros del equipo. 5.     Discusión y acciones: Una vez que se hayan recopilado las ideas en cada categoría (Comenzar, Parar, Continuar), lleva a cabo una discusión en grupo. Analiza cada idea y promueve la participación de todos los miembros del equipo para comprender mejor las propuestas y llegar a un consenso. Identifica acciones específicas y factibles que se deriven de las ideas compartidas. Establece un plan de acción con responsables y plazos para implementar las decisiones tomadas.

6.9. Contento, Triste, Enojado

Es una herramienta utilizada para recopilar retroalimentación emocional y obtener perspectivas diversas de los participantes en un grupo o equipo. Permite identificar los aspectos positivos, negativos y frustrantes de una situación o experiencia determinada.

Contento: En esta parte de la técnica, los participantes expresan lo que les agrada o les hace sentir satisfechos en relación a la situación o experiencia en cuestión. Pueden mencionar logros, avances, aspectos positivos o cualquier elemento que les produzca alegría o satisfacción.

Triste: Aquí, los participantes expresan sus preocupaciones, decepciones o frustraciones respecto a la situación o experiencia. Pueden señalar obstáculos, dificultades, problemas o cualquier aspecto que les cause tristeza o insatisfacción.

Enojado: En esta etapa, los participantes expresan su enojo, irritación o frustración en relación a la situación o experiencia. Pueden mencionar aspectos que les causen indignación, injusticias o cualquier otro sentimiento negativo.

Recuerda adaptar las diferentes herramientas a las necesidades y preferencias de tu equipo.  Además, es recomendable rotar y diversificar las dinámicas utilizadas en diferentes sprints para mantener el interés y la participación activa del equipo.

Contento, Triste, Enojado

1.     Preparación: Reúne al equipo en un entorno tranquilo y asegúrate de que todos los miembros estén presentes. Proporciona un espacio donde los participantes puedan compartir sus sentimientos de forma segura y abierta. Explica brevemente el propósito de la técnica y cómo se llevará a cabo. 2.     Fase de «Contento»: Pide a los miembros del equipo que reflexionen sobre las cosas que los hacen sentir contentos o satisfechos en relación con el proyecto o la situación en cuestión. Cada persona puede compartir en voz alta o por escrito los aspectos que les generan alegría, satisfacción o gratificación. Anima a todos a expresar sus emociones positivas y a celebrar los logros y los aspectos exitosos. 3.     Fase de «Triste»: Invita al equipo a compartir las cosas que los hacen sentir tristes, decepcionados o insatisfechos en relación con el proyecto o la situación en cuestión. Cada miembro puede expresar sus preocupaciones, frustraciones o aspectos negativos que han experimentado. Fomenta un ambiente de escucha comprensiva y empatía, sin juzgar ni criticar las opiniones de los demás. 4.     Fase de «Enojado»: Pide a los participantes que compartan las situaciones, eventos o aspectos que los hacen sentir enojados o molestos en relación con el proyecto o la situación en cuestión. Cada persona puede expresar sus sentimientos de enojo, irritación o indignación, respetando siempre las opiniones de los demás. Recuerda mantener un ambiente seguro y constructivo, promoviendo la expresión honesta pero respetuosa. 5.     Discusión y acciones: Una vez que se hayan compartido los sentimientos en cada categoría (Contento, Triste, Enojado), lleva a cabo una discusión en grupo. Explora las emociones y los comentarios expresados por los miembros del equipo, buscando comprender mejor las preocupaciones y los desafíos. Identifica las acciones o mejoras que se pueden implementar para abordar las preocupaciones y trabajar hacia soluciones. Establece un plan de acción con responsables y plazos para abordar las situaciones negativas y fomentar un ambiente más satisfactorio.

7. Inconvenientes de Scrum

Aunque Scrum tiene muchas ventajas, también tiene algunos inconvenientes a considerar.  El enfoque en la autoorganización y la colaboración intensiva puede requerir un cambio cultural y de mentalidad en las organizaciones.  Además, Scrum puede no ser adecuado para proyectos muy complejos o con requisitos cambiantes constantemente.  Además, una implementación incorrecta de Scrum puede llevar a resultados insatisfactorios.

Si bien Scrum es una metodología ágil ampliamente adoptada y valorada, también presenta ciertos inconvenientes y desafíos que es importante tener en cuenta.  A continuación, se mencionan algunos de los principales inconvenientes de Scrum:

1. Complejidad de aprendizaje: Scrum tiene una estructura y roles específicos que pueden resultar complejos de comprender y aplicar correctamente.  Requiere un entendimiento profundo de sus principios y prácticas, así como un cambio de mentalidad por parte de los miembros del equipo y la organización.
2. Necesidad de autogestión: Scrum se basa en la autogestión y la colaboración activa del equipo.  Esto puede suponer un desafío en entornos donde los equipos no están acostumbrados a tomar decisiones colectivas o donde la cultura organizativa no favorece la autonomía.
3. Requerimientos de tiempo y recursos: La implementación exitosa de Scrum requiere una dedicación de tiempo y recursos por parte del equipo y la organización.  Las reuniones regulares, la planificación y el seguimiento constante pueden implicar una carga adicional de trabajo.
4. Dependencia de la colaboración y la comunicación efectiva: Scrum se basa en una comunicación abierta y una colaboración estrecha entre todos los miembros del equipo.  Si existen barreras en la comunicación o falta de compromiso por parte de los miembros del equipo, la implementación de Scrum puede resultar menos efectiva.
5. Adaptabilidad a proyectos complejos: Aunque Scrum es eficaz en proyectos iterativos e incrementales, puede presentar desafíos en proyectos altamente complejos o con requisitos cambiantes de manera frecuente.  La gestión de dichos proyectos puede requerir adaptaciones adicionales y técnicas complementarias.
6. Falta de documentación exhaustiva: Scrum se centra en la entrega de productos funcionales en lugar de una documentación exhaustiva.  Esto puede dificultar la trazabilidad y la gestión de requisitos a largo plazo, especialmente en entornos regulados o con necesidades de documentación más estrictas.

Es importante tener en cuenta estos inconvenientes al considerar la implementación de Scrum.  Sin embargo, muchos de ellos pueden abordarse y superarse mediante una comprensión adecuada de Scrum, una preparación y capacitación adecuadas, y un compromiso organizativo para respaldar la adopción de la metodología.

8. Comparación del Marco Lógico con Scrum

El marco lógico, también conocido como enfoque de Marco Lógico (MML), se utiliza en la gestión de proyectos y programas para planificar, implementar, monitorear y evaluar intervenciones.  A diferencia de Scrum, el marco lógico se centra en la planificación estratégica y el seguimiento de proyectos, mientras que Scrum se enfoca en la entrega de valor incremental, la colaboración intensiva y la adaptabilidad al cambio.

El marco lógico, también conocido como enfoque de Marco Lógico, es una metodología de gestión de proyectos ampliamente utilizada en el sector de desarrollo y cooperación internacional.  Aunque comparte algunos elementos comunes con Scrum, existen diferencias significativas entre ambos enfoques.  A continuación, se presenta una comparación entre el marco lógico y Scrum:

	Marco Lógico	Scrum
Enfoque de planificación	Se centra en la planificación detallada y exhaustiva de un proyecto desde su inicio, utilizando herramientas como el Árbol de Problemas, el Árbol de Objetivos y la Matriz de Planificación	Adopta un enfoque más adaptativo y flexible, donde la planificación se realiza en ciclos cortos y se ajusta de manera continua a medida que se obtiene retroalimentación y se generan cambios.
Naturaleza del proyecto	Se utiliza comúnmente en proyectos de desarrollo y cooperación internacional, donde el enfoque está en el logro de objetivos a largo plazo y el impacto social	Es ampliamente utilizado en el desarrollo de software y proyectos que requieren una respuesta ágil a requisitos cambiantes y una entrega incremental de valor
Roles y responsabilidades	Se asignan roles específicos a los actores involucrados, como el gerente de proyecto, el especialista en monitoreo y evaluación, y el responsable de seguimiento	Establece tres roles principales: el Scrum Master, Scrum Owner y el Equipo de Desarrollo, cada uno con responsabilidades específicas y una colaboración estrecha
Herramientas	Utiliza herramientas como la Matriz de Planificación, el Marco de Resultados y la Matriz de Indicadores para documentar y monitorear el progreso del proyecto	Emplea el Product Backlog, el Sprint Backlog y el Incremento para gestionar el trabajo y la entrega de valor. Hitos como las Daily Scrum y Sprint Review.
Flexibilidad y adaptabilidad	Tiende a ser más rígido en su planificación inicial y puede requerir procesos más formales para realizar cambios significativos en la implementación.	Se caracteriza por su enfoque iterativo e incremental, lo que permite una mayor flexibilidad y adaptabilidad a medida que se obtiene retroalimentación del producto y las necesidades del cliente cambian.

En resumen, el marco lógico se centra en una planificación detallada y exhaustiva, con énfasis en el logro de objetivos a largo plazo y el impacto social, mientras que Scrum adopta un enfoque ágil y adaptativo, con ciclos cortos de planificación y entrega de valor en proyectos de desarrollo de software y otros proyectos que requieren flexibilidad y respuesta rápida a los cambios. La elección entre ambos enfoques dependerá de la naturaleza del proyecto, los objetivos y las necesidades específicas de la organización.

9. Utilidad de Scrum para el tercer sector

Scrum puede ser altamente beneficioso para el tercer sector, ya que permite una gestión ágil de proyectos y programas.  En el tercer sector, donde los recursos suelen ser limitados y los objetivos están centrados en generar impacto social, Scrum puede ayudar a optimizar el uso de recursos, adaptarse rápidamente a los cambios y mantener un enfoque constante en las necesidades de los beneficiarios.

Scrum puede ser de gran utilidad para el tercer sector, que engloba organizaciones sin fines de lucro, organizaciones no gubernamentales, fundaciones y otros actores que trabajan en pro de causas sociales y comunitarias.  A continuación, se presentan algunas formas en las que Scrum puede ser beneficioso para el tercer sector:

1. Mayor agilidad y adaptabilidad: Scrum permite a las organizaciones del tercer sector ser más ágiles y adaptarse rápidamente a los cambios en las necesidades y demandas de la comunidad a la que sirven.  Al trabajar en ciclos cortos y enfocarse en entregas incrementales, Scrum permite una mayor capacidad de respuesta a los desafíos y oportunidades emergentes.
2. Enfoque en el valor y el impacto: Scrum pone un fuerte énfasis en la entrega de valor al cliente y en el logro de resultados tangibles.  Esto es especialmente relevante para el tercer sector, donde la medición del impacto social y la generación de resultados concretos son aspectos críticos para la sostenibilidad y el éxito de las organizaciones.
3. Colaboración y participación activa: Scrum promueve la colaboración y la participación activa de todos los miembros del equipo, incluidos los voluntarios y las partes interesadas del tercer sector.  Esto fomenta la transparencia, la comunicación efectiva y el empoderamiento de todas las partes involucradas en la realización de los proyectos y la consecución de los objetivos comunes.
4. Gestión de proyectos más efectiva: Scrum proporciona un marco de trabajo estructurado para la gestión de proyectos, lo que facilita la organización, planificación y seguimiento de las actividades.  Los roles claros, los artefactos y los eventos de Scrum permiten una mayor visibilidad y control sobre el progreso de los proyectos, lo que ayuda a evitar retrasos y a garantizar la entrega oportuna de resultados.
5. Promoción de la innovación: Scrum fomenta la experimentación, la retroalimentación constante y la mejora continua.  Esto puede ser especialmente valioso para el tercer sector, donde se busca encontrar soluciones innovadoras a problemas sociales complejos.  La mentalidad de aprendizaje y adaptación de Scrum permite a las organizaciones del tercer sector explorar nuevas ideas y enfoques, y ajustar sus estrategias en función de los resultados y las necesidades identificadas.

Al implementar Scrum en el tercer sector, es importante adaptar y personalizar el enfoque para abordar las particularidades y desafíos propios de las organizaciones sin fines de lucro. Al hacerlo, Scrum puede ayudar a maximizar la eficacia, la eficiencia y el impacto de las iniciativas del tercer sector, permitiendo un mayor alcance y resultados más significativos en el logro de su misión.

10. Escalado de Scrum

Con el crecimiento de las organizaciones y la necesidad de aplicar Scrum en proyectos más grandes y complejos, surgieron enfoques de escalado de Scrum.  Algunos de los más populares que nos ofrecen pautas y estructuras para coordinar y sincronizar múltiples equipos Scrum que trabajan en colaboración en un proyecto:

10.1 Scrum of Scrums

Es una técnica utilizada para escalar Scrum y gestionar la colaboración entre múltiples equipos Scrum en proyectos de gran envergadura.  Proporciona un marco de trabajo para coordinar y sincronizar los esfuerzos de varios equipos Scrum, especialmente cuando trabajan en conjunto para entregar un producto o proyecto complejo.

La idea detrás de Scrum of Scrums es que los representantes de cada equipo Scrum se reúnen periódicamente en un evento llamado «Scrum of Scrums«, donde comparten actualizaciones sobre el progreso de sus respectivos equipos, resuelven dependencias y abordan impedimentos que puedan afectar la colaboración entre los equipos.

Algunos aspectos clave de Scrum of Scrums son:

Representantes de equipo: Cada equipo Scrum selecciona a uno o más miembros para representarlos en el Scrum of Scrums. Estos representantes actúan como enlace entre su equipo y los demás equipos Scrum.

Frecuencia de reuniones: Los Scrum of Scrums generalmente se llevan a cabo con una frecuencia establecida, como una vez al día o una vez a la semana, dependiendo de las necesidades del proyecto.  La periodicidad de las reuniones puede ajustarse según el contexto.

Agenda de reuniones: Durante el Scrum of Scrums, los representantes de cada equipo comparten actualizaciones sobre el progreso de sus equipos, incluyendo el estado de las tareas, los impedimentos y las dependencias identificadas.  También se discuten y se resuelven problemas de coordinación y colaboración entre los equipos.

Resolución de impedimentos: Si se identifican impedimentos o problemas que requieren la colaboración de múltiples equipos, el Scrum of Scrums proporciona un espacio para abordarlos y buscar soluciones conjuntas. Se pueden asignar acciones o tareas específicas para resolver los impedimentos identificados.

Scrum of Scrums es una técnica útil para gestionar proyectos grandes o complejos que involucran múltiples equipos Scrum.  Ayuda a mantener una comunicación fluida entre los equipos, a identificar y resolver problemas de dependencias, y a asegurar que el trabajo de los equipos se integre de manera efectiva.

10.2 Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) es un marco de trabajo ágil que se utiliza para escalar Scrum en organizaciones con múltiples equipos de desarrollo que trabajan en un mismo producto o proyecto. Fue creado por Craig Larman y Bas Vodde y se basa en los principios y valores de Scrum, pero adaptados para entornos de mayor escala.

LeSS se centra en simplificar y despojar de complejidad innecesaria los procesos de desarrollo, permitiendo a los equipos colaborar de manera efectiva y entregar valor de forma iterativa e incremental. Algunos aspectos clave de LeSS son:

Equipo de desarrollo único: A diferencia de otros marcos de escalamiento que utilizan múltiples equipos Scrum, LeSS propone que todos los equipos trabajen como un solo Equipo de Desarrollo.  Esto fomenta la colaboración y la responsabilidad compartida para entregar el producto de manera integrada.

Roles y eventos de Scrum tradicionales: LeSS mantiene los roles básicos de Scrum, como el Scrum Master, el Product Owner y el Equipo de Desarrollo, así como los eventos de Scrum, como la Planificación del Sprint, la Revisión del Sprint y la Retrospectiva del Sprint.  Esto facilita la comprensión y la adopción del marco por parte de los equipos.

Amplificación de los principios de Scrum: LeSS enfatiza los principios ágiles y de Scrum, como la transparencia, la inspección y la adaptación.  Estos principios se amplifican en el contexto de LeSS para abordar los desafíos específicos de escalar Scrum.

Coordinación y gestión de dependencias: LeSS proporciona técnicas y herramientas para facilitar la coordinación entre los equipos y gestionar las dependencias.  Esto incluye la definición de un Product Backlog común, la realización de eventos de coordinación y la utilización de prácticas de desarrollo colaborativas.

Enfoque en el aprendizaje organizativo: LeSS promueve el aprendizaje continuo y la mejora en toda la organización.  Se alienta a los equipos a experimentar, compartir conocimientos y adaptar sus prácticas para impulsar la entrega de valor de manera más efectiva.

El objetivo de LeSS es ofrecer una forma ágil de escalar Scrum en organizaciones con múltiples equipos, fomentando la colaboración, la simplicidad y la entrega de valor de manera iterativa. Proporciona un marco flexible que se puede adaptar a diferentes contextos y promueve la agilidad a gran escala.

10.3 Scaled Agile Framework (SAFe)

Es un marco de trabajo que proporciona una guía para implementar prácticas ágiles a gran escala en organizaciones.  Fue desarrollado por Dean Leffingwell y se centra en la gestión y coordinación de múltiples equipos ágiles que trabajan en conjunto para lograr los objetivos estratégicos de la organización.

SAFe se basa en los principios y valores del Manifiesto Ágil y adopta elementos de Lean Thinking, Systems Thinking y desarrollo de software ágil.  Proporciona una estructura escalable que abarca desde equipos ágiles individuales hasta programas y carteras de proyectos más grandes.

Algunos de los componentes clave de SAFe incluyen:

1. Equipo Ágil: Los equipos ágiles son la unidad básica de trabajo en SAFe.  Siguen los principios y prácticas ágiles, como Scrum o Kanban, y son responsables de entregar incrementos de valor en intervalos regulares.
2. Program Increment (PI): Un PI es un marco de tiempo fijo de 8 a 12 semanas en el cual múltiples equipos ágiles trabajan de manera coordinada para lograr un conjunto de objetivos comunes.  Durante un PI, los equipos colaboran, planifican y entregan incrementos de valor.
3. Release Train: Un Release Train es un grupo de equipos ágiles que trabajan juntos en el mismo horario de PI y se alinean en torno a un objetivo compartido.  El Release Train está liderado por un Agile Release Train Engineer (ARTE) y se coordina a través de eventos como la Planificación de PI y la Demostración de Sistema.
4. Portafolio Ágil: El nivel más alto de SAFe se enfoca en la gestión de carteras de proyectos y la toma de decisiones estratégicas.  El Portafolio Ágil alinea los esfuerzos de desarrollo con los objetivos estratégicos de la organización y proporciona una visión holística del estado y el rendimiento de los programas y proyectos.

SAFe proporciona una guía detallada sobre cómo implementar prácticas ágiles a gran escala, brindando estructura y coherencia a través de diferentes niveles de la organización.  Es utilizado por muchas organizaciones que buscan escalar sus esfuerzos ágiles y alinearlos con su estrategia empresarial.

10.4. Nexus.

Nexus es un marco de trabajo ágil desarrollado por Scrum.org que se utiliza para escalar Scrum en proyectos de gran envergadura.  Está diseñado para abordar los desafíos de coordinación y colaboración entre múltiples equipos Scrum que trabajan juntos en un mismo producto o proyecto.

El objetivo principal de Nexus es permitir que múltiples equipos Scrum colaboren de manera efectiva y entreguen de forma conjunta un incremento de producto integrado al final de cada iteración, conocido como «Nexus Sprint«. Algunos conceptos clave de Nexus incluyen:

1. Nexus Integration Team: Es un equipo adicional dentro del Nexus compuesto por representantes de cada equipo Scrum.  Este equipo se encarga de garantizar la integración continua del trabajo de los equipos, resolviendo dependencias, gestionando impedimentos y asegurando que el incremento de producto sea coherente y de calidad al final de cada Sprint.
2. Nexus Sprint Planning: Es un evento en el que los equipos Scrum del Nexus colaboran para planificar las actividades y las metas del próximo Sprint.  Durante esta reunión, los equipos identifican las dependencias y los elementos de trabajo que deben abordar de manera conjunta para lograr el objetivo del Sprint.
3. Nexus Daily Scrum: Es una variante del Daily Scrum tradicional que se realiza a nivel de Nexus.  En esta reunión, los representantes de cada equipo Scrum comparten actualizaciones sobre el progreso de su trabajo y discuten cualquier impedimento o problema que afecte la colaboración entre los equipos.
4. Nexus Sprint Review: Al final de cada Sprint, se realiza una revisión conjunta para demostrar el incremento de producto integrado y recopilar comentarios de los stakeholders.  Esta reunión permite validar el trabajo realizado por los equipos Scrum y obtener retroalimentación para ajustar y mejorar el producto.
5. Nexus Sprint Retrospective: Es una retrospectiva a nivel de Nexus en la que los equipos Scrum reflexionan sobre su proceso de colaboración y buscan formas de mejorar la eficacia y la eficiencia en el próximo Sprint.

Nexus proporciona una estructura y un conjunto de eventos específicos para facilitar la colaboración y la entrega de valor en proyectos escalados de Scrum.  Ayuda a los equipos a trabajar de manera más coordinada y a abordar los desafíos de integración y dependencias en proyectos de mayor envergadura.

11. Algunos casos de éxito

Scrum ha sido implementado con éxito en numerosos proyectos y organizaciones en diferentes sectores.  Ejemplos destacados incluyen el desarrollo de software en empresas como Spotify y Google, así como proyectos en el sector público y organizaciones sin fines de lucro.  Estos casos de éxito demuestran la efectividad de Scrum en la entrega de valor y la adaptación a los cambios.

Existen numerosos casos de éxito en la aplicación de Scrum en diferentes industrias y contextos.  A continuación, se presentan algunos ejemplos destacados:

Adobe Systems: Ha adoptado Scrum en su proceso de desarrollo de productos.  A través de la implementación de Scrum, han logrado una mayor flexibilidad y capacidad de respuesta a las necesidades cambiantes del mercado, permitiéndoles lanzar nuevas versiones de sus productos de manera más rápida y eficiente.

Amazon: Ha incorporado Scrum en su proceso de desarrollo de software, lo que les ha permitido innovar rápidamente y lanzar productos y servicios de manera ágil.  La adopción de Scrum les ha ayudado a responder de manera más eficiente a las necesidades cambiantes del mercado.

BBVA: Ha utilizado Scrum en sus proyectos de transformación digital.  Han implementado equipos Scrum para acelerar la entrega de nuevos productos y servicios digitales, y mejorar la colaboración entre los diferentes departamentos y áreas de la organización.

Google: Ha aplicado Scrum en varios de sus proyectos, incluyendo el desarrollo de productos como Gmail y Google Ads.  A través de la implementación de Scrum, han logrado acelerar la entrega de nuevas funciones y mejorar la colaboración entre los equipos de desarrollo.

Infojobs: Ha implementado Scrum en su proceso de desarrollo de software.  Utilizan equipos Scrum para mejorar la entrega de nuevas funcionalidades y la calidad de su plataforma.  La adopción de Scrum les ha permitido tener una mayor visibilidad y control sobre el progreso de los proyectos, así como una mayor capacidad para adaptarse a los cambios y prioridades del mercado laboral.

LEGO: Ha implementado Scrum en su proceso de diseño y desarrollo de productos.  Scrum les ha permitido tener una visión clara de los objetivos del proyecto, una comunicación efectiva entre los equipos y una mayor velocidad en la entrega de nuevos productos al mercado.

Salesforce: Salesforce, una de las principales empresas de software de gestión de relaciones con clientes (CRM), ha incorporado Scrum en su enfoque de desarrollo de software.  Utilizan equipos Scrum autónomos y autoorganizados para desarrollar y mejorar continuamente su plataforma, lo que les ha permitido ofrecer a sus clientes nuevas funcionalidades de manera más ágil.

Spotify:  Ha adoptado Scrum en su enfoque de desarrollo de software.  Utilizan equipos autónomos y multidisciplinarios, conocidos como «tribus«, que trabajan de manera colaborativa y ágil para mejorar continuamente su producto y adaptarse a las demandas de los usuarios.

Telefónica: Utilizan equipos Scrum para desarrollar aplicaciones y servicios digitales, lo que les ha permitido acelerar la entrega de nuevos productos al mercado y adaptarse rápidamente a las necesidades de sus clientes.  Scrum les ha proporcionado mayor transparencia, colaboración efectiva y capacidad de respuesta en un entorno altamente competitivo.

Toyota: Ha aplicado los principios de Scrum en su proceso de fabricación de automóviles. Han adoptado el enfoque de «Lean Scrum» para mejorar la eficiencia, reducir el desperdicio y fomentar la mejora continua en sus operaciones.

Twitter:  Ha utilizado Scrum para mejorar la colaboración y la eficiencia en el desarrollo de su plataforma.  La implementación de Scrum ha facilitado la gestión de los diferentes aspectos del proyecto, desde la planificación hasta la entrega de las funcionalidades.

Zappos: Zappos, una reconocida compañía de comercio electrónico, ha implementado Scrum en su proceso de gestión de proyectos y desarrollo de software.  A través de Scrum, han logrado una mayor transparencia, colaboración y capacidad de adaptación, lo que ha llevado a una mejora significativa en la entrega de proyectos y en la satisfacción del cliente.

12. Publicaciones de referencia sobre Scrum

Existen varias publicaciones de referencia que ofrecen información detallada sobre Scrum y su aplicación en la gestión ágil de proyectos.  A continuación, se presentan algunas de las principales publicaciones sobre Scrum:

1. «The Scrum Guide«: Esta es la guía oficial de Scrum, escrita por Ken Schwaber y Jeff Sutherland, los creadores de Scrum. Proporciona una descripción detallada de los roles, artefactos y eventos de Scrum, así como las reglas y principios fundamentales.  Se actualiza regularmente para reflejar las últimas prácticas y evoluciones de Scrum.
2. « Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo» (Jeff Sutherland): Escrito por uno de los cofundadores de Scrum, este libro explora los principios y prácticas de Scrum y cómo pueden aplicarse para mejorar la eficiencia y la productividad. También comparte experiencias y casos de estudio de la implementación exitosa de Scrum en diferentes organizaciones.
3. «Scrum Mastery: From Good to Great Servant-Leadership» (Geoff Watts): Este libro se centra en el papel del Scrum Master y ofrece consejos prácticos sobre cómo llevar a cabo eficazmente las responsabilidades de este rol. Explora temas como la facilitación, el coaching, la resolución de conflictos y la mejora continua en el contexto de Scrum.
4. «Agile Estimating and Planning» (Mike Cohn): Mike Cohn, reconocido experto en Scrum, aborda en este libro el desafío de la estimación y planificación ágil en el contexto de Scrum. Proporciona técnicas y enfoques prácticos para realizar estimaciones ágiles y crear planes efectivos para proyectos Scrum.
5. « Scrum y XP desde las trincheras » (Henrik Kniberg): Este libro ofrece una perspectiva práctica sobre la implementación de Scrum en el desarrollo de software. Basado en experiencias reales, presenta consejos, técnicas y casos de estudio para ayudar a los equipos a adoptar y mejorar su uso de Scrum.
6. «Essential Scrum: A Practical Guide to the Most Popular Agile Process» (Kenneth S. Rubin): Esta publicación aborda los conceptos fundamentales de Scrum y ofrece una guía completa para la implementación exitosa de Scrum. Cubre aspectos como la planificación, la estimación, la gestión del backlog y la mejora continua en el contexto de Scrum.
7. «Scrum: Gestión ágil de proyectos de software» (Javier Garzás Parreño y Hugo Ferreira): Este libro ofrece una visión general de Scrum y cómo aplicarlo en proyectos de software. Cubre los conceptos clave de Scrum, los roles, artefactos y eventos, y proporciona ejemplos de casos reales.

13. Enlaces de interés sobre Scrum

Hay varios enlaces de interés que proporcionan información adicional sobre Scrum. El sitio web oficial de Scrum.org es una fuente confiable que brinda recursos, cursos y certificaciones relacionadas con Scrum. Otros sitios como Agile Alliance, Scrum Alliance y Scrum Inc. también ofrecen información valiosa sobre Scrum.

Aquí tienes algunos enlaces de interés sobre Scrum:

1. org: El sitio oficial de Scrum.org, que ofrece una amplia gama de recursos, incluyendo guías, artículos, libros y cursos de capacitación. Puedes encontrar más información en su página web: https://www.scrum.org/
2. Scrum Alliance: La Scrum Alliance es una organización que promueve el uso de Scrum en todo el mundo. Su sitio web ofrece recursos valiosos, como guías, artículos y una comunidad activa de profesionales de Scrum. Puedes acceder a su sitio web aquí: https://www.scrumalliance.org/
3. Agile Alliance: La Agile Alliance es una organización global que promueve los enfoques ágiles, incluido Scrum. En su página web, encontrarás información relevante sobre Scrum, así como otros métodos ágiles. Visita su sitio web en: https://www.agilealliance.org/
4. Mountain Goat Software Blog: El blog de Mike Cohn, fundador de Mountain Goat Software y experto en Scrum. Ofrece una amplia gama de artículos sobre Scrum y métodos ágiles. Visita el blog en: https://www.mountaingoatsoftware.com/blog
5. ScrumInc Blog: El blog de ScrumInc, fundado por Jeff Sutherland, uno de los creadores de Scrum. Proporciona contenido valioso sobre Scrum y cómo aplicarlo de manera efectiva. Puedes leer el blog en: https://www.scruminc.com/blog/
6. Agile Alliance Blog: El blog de la Agile Alliance, donde se comparten ideas y experiencias relacionadas con los métodos ágiles, incluyendo Scrum. Explora el blog en: https://www.agilealliance.org/resources/blog/
7. Reddit – r/scrum: El subreddit dedicado a Scrum, donde puedes unirte a discusiones, hacer preguntas y compartir tus experiencias con la comunidad de Scrum. Puedes acceder al subreddit aquí: https://www.reddit.com/r/scrum/

Estas fuentes te proporcionarán una amplia gama de recursos, opiniones y discusiones sobre Scrum. Asegúrate de explorar los blogs y unirte a las comunidades en línea para mantenerte actualizado y aprender de las experiencias de otros profesionales en Scrum.

[1] Lean Manufacturing, también conocido como Lean Production o simplemente Lean, es una metodología de gestión que se originó en Toyota en Japón. Fue desarrollada por Taiichi Ohno y Eiji Toyoda en las décadas de 1940 y 1950 como parte del sistema de producción de Toyota, conocido como Toyota Production System (TPS).  El enfoque Lean tiene como objetivo principal eliminar el desperdicio y mejorar la eficiencia en los procesos de producción. Se basa en el principio fundamental de maximizar el valor para el cliente mientras se minimiza el uso de recursos y se reducen los tiempos de producción.

[2] El enfoque de equipos autónomos de Honda es una práctica de gestión que se originó en Honda Motor.  En lugar de utilizar una estructura jerárquica tradicional, Honda ha implementado un enfoque de equipos autónomos, también conocidos como «células de trabajo«. Estos equipos están compuestos por empleados de diferentes áreas y habilidades, quienes trabajan juntos para completar tareas específicas y alcanzar objetivos comunes.

[3] La calidad total de Deming, también conocida como el ciclo PDCA (Plan, Do, Check, Act), es un enfoque de gestión de la calidad desarrollado por el Dr. W. Edwards Deming. Este enfoque se basa en principios y prácticas destinados a mejorar continuamente la calidad de los productos, servicios y procesos de una organización.  La calidad total de Deming se basa en la idea de que la calidad es responsabilidad de todos en la organización y que la mejora continua es fundamental para alcanzar la excelencia. Deming enfatizó la importancia de la gestión participativa, el trabajo en equipo, la capacitación y el aprendizaje organizacional como elementos clave para lograr la calidad total.

[4] Takeuchi, H. y Nonaka, I., 1986, Nuevo Nuevo Juego del Desarrollo de Productos (New New Product Development Game): Harvard Business Review, 64, 137-146

[5] Kanban es un enfoque de gestión visual que se utiliza para optimizar el flujo de trabajo. Se basa en tarjetas o «kanbans» que representan las tareas a realizar. A medida que las tareas avanzan, se mueven a través de columnas en un tablero, lo que permite una visualización clara del progreso y facilita la identificación de cuellos de botella y la toma de decisiones.

[6] Lean Startup es una metodología que se utiliza para desarrollar productos y servicios de manera rápida y eficiente, minimizando el desperdicio y maximizando el aprendizaje. Se basa en la experimentación y la validación temprana de ideas a través de ciclos de construcción, medición y aprendizaje. El enfoque principal es construir un producto mínimo viable (MVP) y obtener retroalimentación de los clientes lo antes posible.

[7] Design Thinking es un enfoque centrado en el usuario para resolver problemas complejos y fomentar la innovación. Se basa en la comprensión profunda de las necesidades y deseos de los usuarios para generar ideas creativas y soluciones efectivas. El proceso de Design Thinking incluye etapas de empatía, definición del problema, generación de ideas, prototipado y pruebas iterativas.

[8] Tomado de Wikipedia https://en.wikipedia.org/wiki/Burndown_chart