1. Adoptando Scrum

En este capítulo se abordan aspectos como el ciclo de vida de la adopción de Scrum y cada una de sus actividades: el inicio del proyecto de adopción, el backlog del proyecto, la ejecución, la evaluación de madurez, la gestión del cambio organizacional y una sección especial donde se aborda la implementación de Scrum en grandes organizaciones.

• 1.1. Ciclo de vida de la adopción de Scrum
• 1.2. Inicio de un proyecto de adopción Scrum
• 1.3. Definir y priorizar el backlog del proyecto
• 1.4. Ejecución del proyecto
• 1.5. Evaluación de madurez
• 1.6. Gestión del cambio organizacional
• 1.7. Implementación de Scrum en grandes organizaciones.

1.1. Ciclo de vida de la adopción de Scrum

1.1.1. ¿Implementar o adoptar Scrum?

Scrum es mucho más que solo implementar herramientas o técnicas, es más bien un cambio cultural, por lo que pensar en la "implementación" de Scrum es erróneo, lo más apropiado es hablar de "Adopción" de Scrum.

"Implementar" es un concepto relacionado con el cumplimiento o ejecución de una actividad, mientras que "Adoptar" hace énfasis en la apropiación y compromiso que se genera en un nivel más profundo de la persona.

Para la adopción de Scrum se requiere poner en marcha las prácticas, realizar experimentos y realizar ajustes al marco de trabajo, esto significa que Scrum no es un Framework estático, sino que por el contrario, se ajusta según las necesidades cambiantes de la organización.

Además, se requiere el apoyo de toda la organización, para fortalecer una cultura orientada hacia lo ágil, basada en la simplicidad, el valor y el alto rendimiento que se necesita para la gestión de proyectos modernos.

Cabe resaltar que la transformación ágil basada en Scrum va más allá de realizar reuniones time-box o ejecutar prácticas técnicas, pues es importante tener en cuenta en el ámbito de la organización aspectos como los que se describen en el siguiente gráfico:

Una transformación ágil implica considerar estos aspectos, pues si bien el proyecto de adopción de Scrum puede estar encabezado por una área específica, es necesario contar con la participación del talento humano, las áreas estratégicas e incluso la colaboración con algunas partes interesadas externas como los clientes, el mercado y los proveedores.

1.1.2. Ciclo de vida de la adopción de Scrum

El ciclo de vida de adopción de Scrum describe las fases que se deben seguir con el objetivo de adoptar Scrum dentro de una organización, estas fases aunque en el gráfico se presentan de manera lineal, son iterativas, pues durante la ejecución de la adopción es posible redefinir aspectos como la visión, identificar la necesidar de nuevos miembros del equipo de trabajo, adicional elementos al backlog o modificar su prioridad, etc.

La última fase que presenta el gráfico, la evaluación de madurez, contiene actividades que permitirán conocer el nivel de avance del proyecto, por lo que la información allí obtenida es de vital importancia para identificar las oportunidades de mejora y realizar los ajustes necesarios a las actividades de adopción de tal manera que se alcance la visión del proyecto, evitando posibles desviaciones.

Por otro lado, se puede observar que la Gestión del cambio (cultura ágil) es un elemento trasversal al ciclo de vida, esto obedece a que el éxito de la adopción de Scrum depende en gran medida de los comportamientos, rituales, estructuras, procesos y elementos propios de las actividades cotidianas de la organización, por lo que evaluar cuidadosamente la mejor manera de manejar el cambio es de suma importancia.

1.1.3. Componentes típicos de la adopción de Scrum

En el libro The Scrum Map 2021 se describen todos los aspectos que conforman este Framework de manera detallada, de hecho, se podría llegar a pensar que una organización adopta Scrum de manera exitosa únicamente si logra implementar la totalidad las ceremonias/eventos, los artefactos, los emisores de información, los elementos descritos en las prácticas, etc. lo cual no es del todo cierto, pues existen algunos elementos típicos, también llamados "elementos core" los cuales al ser adoptados dentro de la organización, se traducen en la adopción de Scrum.

Los elementos core, como se presenta en el gráfico anterior, se agrupan en cinco categorías:

• Roles y equipos: la organización debe como mínimo contar con un Scrum Master, un Product Owner y los desarrolladores.
• Ceremonias: la organización como mínimo debe realizar Sprints, planificación del Sprint, Scrum diario, Revisión del Sprint y Retrospectiva del Sprint.
• Artefactos: los artefactos mínimos que debe implementar la organización son el Product Backlog, Product goal, Sprint backlog, Sprint goal, incremento del producto y la definición de terminado.

La gestión de estos elementos se puede realizar con ayuda de una herramienta de Software.

La adopción de Scrum se puede ver fortalecida si se llevan a cabo acciones como:

• Creación de una Agile Project Management Office (APMO).
• Diseñar e implementar métricas y mediciones que permitan conocer
• Automatizar procesos o utilizar técnicas o Frameworks que favorezcan la operación de la organización, por ejemplo, DevOps.
• Fomentar la Agilidad organizacional.

1.1.4. Enfoques en la adopción de Scrum

No todas las organizaciones tienen los mismos objetivos al momento de adoptar Scrum, muchas tienen distintos enfoques, algunos de estos son:

• Herramientas y automatización: este enfoque se da en organizaciones que desean adoptar Scrum para la implementación de una nueva herramienta como podría ser un software de ERP o CRM, un Sistema de Gestión, RPA para automatizar procesos de la organización, etc. En estos casos la implementación de la herramienta o Framework se da de manera incremental, asegurando que en cada iteración se aumenta el valor que la implementación genera a la organización.
• Personas, motivación y compromiso: este enfoque se da en organizaciones que desean ejecutar un proyecto cuya finalidad es mejorar la calidad de su ambiente laboral, de tal manera que la motivación y compromiso de sus colaboradores se incremente. Para alcanzar este propósito es importante hacer un énfasis especial en los principios de Scrum.
• Procesos y prácticas: este enfoque se da en organizaciones que desean adoptar Scrum para ajustar sus procesos estratégicos, tácticos u operativos con las prácticas descritas en Scrum.

1.1.5. Factores de adaptación de Scrum

Cuando las prácticas y herramientas de Scrum han de ser adoptadas en una organización, estas no siempre se ajustan 100% al contexto del proyecto, el tipo de organización o incluso las necesidades concretas de un cliente especifico, razón por la cual en distintas organizaciones la APMO diseña un conjunto de guías que permiten adaptar las prácticas de Scrum al contexto de cada proyecto, estas guías reciben el nombre de “Factores de adaptación”.

• Los factores de adaptación son útiles para los miembros de los distintos equipos Scrum, principalmente para los distintos Product Owner.
• Los factores de adaptación también pueden ser utilizados para adaptar el programa de auditoría por parte de los grupos de calidad de la organización.

Los factores de adaptación que deben ser considerados a la hora de adoptar Scrum en la organización son:

1.2. Inicio de un proyecto de adopción Scrum

Esta fase es la más importante ya que representa la base del proyecto y el inicio oficial de la adopción de Scrum.

Dentro de las actividades más relevantes de esta fase, encontramos:

• Realizar un primer acercamiento con las partes interesadas, mediante un análisis inicial
• Identificar la visión del proyecto
• Seleccionar nuestro equipo de trabajo
• Dar a conocer a todos los involucrados en el proyecto la visión para buscar el compromiso y apoyo de todos
• Identificar los elementos que harán parte de este proyecto

Algunas recomendaciones antes de iniciar un proyecto de adopción Scrum son:

• Lo mejor es empezar con un equipo pequeño, que no sea crítico para la organización pero que no sea tan irrelevante como para que a nadie le importe el éxito de este.
• Antes de pensar en una adopción completa de las prácticas de Scrum, se debe pensar en pequeños experimentos que permitan a las personas pasar por una transición suave (ambiente seguro para fallar).
• El cumplimiento de las expectativas del negocio es muy importante: sin esto el proyecto no puede ser un éxito. Sin embargo, es muy común negociar la reducción en la calidad con el fin de cumplir plazos de entrega, lo cual se puede traducir en que a la organización muchas veces no le preocupa tanto tener algo perfecto, sino tener lo necesario y a tiempo.
• Para no sacrificar completamente la calidad, debemos ocuparnos de priorizar los elementos del Backlog en función del valor que aportan a la transformación.

1.2.1. Análisis inicial GAP

En análisis inicial consiste en realizar un diagnóstico basado en los elementos que conforman el Backlog del proyecto de adopción y del cual se hablará con mayor detalle más adelante, este análisis inicial le permite a la organización identificar las bases y modelo bajo el cual operan e interactúan las diferentes áreas y equipos en la organización, evaluando qué tanto están alineadas con la estrategia de negocios, la eficiencia de los procesos y la aceptación de TI en la organización.

En algunos casos, cuando no se cuenta con una visión clara de lo que se pretende alcanzar con la ejecución del proyecto de adopción, el análisis inicial ayudará de manera significativa a definir un panorama claro sobre lo que se desea alcanzar con la adopción de Scrum.

Es importante tener presente que el análisis incial no es solo revisar documentos o realizar una entrevista con las partes interesadas, el objetivo es entender el por qué del estado actual de la organización, así como lograr un acercamiento emocional con las partes interesadas, para capturar información valiosa sobre sus comportamientos y forma de actuar. Es recomendable utilizar técnicas y herramientas visuales para interactuar mejor con los interesados.

El resultado más importante del Análisis inicial es un conjunto de oportunidades de mejora para aplicar en tu organización, el cual representa la base para estructurar el mapa de ruta de la adopción, en la siguiente fase del proyecto.

Esta evaluación se puede realizar mediante el uso de la herramienta que se describe en el segundo capítulo "Evaluación de madurez" de este libro.

1.2.2. Visión del proyecto

“La visión sin acción es meramente un sueño. La acción sin visión solo es pasar el tiempo. La visión con acción puede cambiar el mundo.”  

Joel A. Barker

La visión del proyecto explica las necesidades empresariales que el proyecto de adopción busca satisfacer, considerando aspectos como el enfoque de la adopción, el alcance, el tiempo y el presupuesto, estos últimos tres elementos están enmarcados en la calidad esperada opor el patrocinador del proyecto.

A continuación, se presentan algunas de las actividades a considedar durante la definición de la visión del proyecto.

Identificar los motivadores del proyecto.

Esta actividad consiste en responder el por qué y el para qué se realiza el proyecto, la respuesta a estas preguntas es única para organización pues su contexto es particular, sin embargo, para resolver estos interrogantes es posible considerar los beneficios la adopción de agilidad en las organizaciones, por ejemplo un aumento en la caludad, reducción del "time to market", productividad mejorada y reducción en los costos de los proyectos comparados con otros enfoques, en el sitio web State Of Agile puedes consultar más reportes sobre agilidad.

Identificar las restricciones del proyecto.

Por lo general los proyectos se enfrentan a tres tipos de restricciones que son el alcance, el costo y la duración, estos tres elementos conforman la calidad del proyecto y por lo general ante la aparición de problemas (por ejemplo, terminar a tiempo, no agotar el presupuesto o cumplir con lo que dicta un contrato). El siguiente gráfico presenta tres variantes de los tres elementos de la calidad y el impacto que dichas variaciones tiene sobre el proyecto:

La ilustración en el primer recuadro presenta que si la organización necesita disminuir los costos, el tiempo de ejecución puede ser más largo. El segundo recuadro muestra que si lo que se desea es disminuir el tiempo de ejecución, probablemente los costos crecerán. El tercer recuadro nos muestra la situación ideal en la que se tiene el balance perfecto entre tiempo y costo para cubrir el alcance planeado, sin que se sacrifique la calidad del proyecto. Vale la pena resaltar que muchas veces las organizaciones no están preocupadas por tener salidas perfectas, sino tener lo que se considera necesario a tiempo.

Identificar las partes interesadas en el proyecto

Una actividad clave del análisis inicial es determinar el impacto de las partes interesadas en el proyecto de adopción Scrum, para esto se debe pensar en las personas que serán afectadas durante la ejecución del proyecto y el grado en el que se verán afectadas, por ejemplo, si es de manera directa, indirecta o si la parte interesada es simplemente un observador. Para la identificación de las partes interesadas y el nivel de impacto de las mismas sobre el proyecto, se pueden utilizar técnicas como el mapa de impacto de los interesados.

1.2.3. Roles involucrados en la adopción de Scrum

Contar con un equipo comprometido y confiable es de suma importancia, pues son las personas que trabajarán día a día para sacar adelante el proyecto de adopción. El equipo debe estar alineado y canalizar todos sus esfuerzos hacia la misma meta, por esta razón, la definición de la visión del proyecto debe realizarse antes de constituir el equipo.

Igual de importante es el compromiso del equipo, es por esto que antes de Constituir el equipo es necesario definir un objetivo común (es decir, la visión del proyecto).

Consultor Scrum

Para la adopción de Scrum, el rol del Consultor Scrum toma una posición de Product Owner, es decir que dentro de sus responsabilidades encontramos:

• Promueve la adopción de la agilidad en la organización
• Se desempeña a nivel estratégico y táctico
• Identifica las necesidades de la organización en cuanto a la agilidad
• Es la “voz del cliente”, en este caso el negocio o la Alta Dirección
• Ordenar los elementos del Backlog para alcanzar los objetivos de la mejor manera posible.
• Asegurar que todos los miembros del equipo entienden los elementos del Backlog al nivel necesario, brindando guía sobre cómo llevar a cabo la transformación.

Scrum Máster

En la adopción Scrum, el Scrum Máster se involucra más a nivel organizacional y no solo a nivel de equipo, por lo que representa un apoyo al Consultor Scrum.

• Garantizar que todos (personal del equipo y otras partes interesadas) conocen y aplican correctamente Scrum, sus prácticas y sus lineamientos.
• Ayudar a las personas externas al equipo (partes interesadas) a entender qué comportamientos / actitudes pueden ser útiles y cuáles no para la transformación.
• Contribuir a eliminar impedimentos / obstáculos para el proyecto de adopción.
• Ayudar a planificar la adopción de Scrum.
• Motivar cambios / experimentos que incrementen la productividad del personal involucrado en el proyecto de adopción.
• Junto con otros Scrum Máster, incrementar la efectividad de la adopción de Scrum en la organización.

Arquitecto de procesos

Para la adopción Scrum, será de gran apoyo contar con un Arquitecto/a de procesos, pues aportará el conocimiento y experiencia necesarios para la reestructuración, documentación, o levantamiento de procesos, además de:

• Trabajar en conjunto con los gerentes de negocios y el personal para definir y validar la operación del negocio, para posteriormente diseñar modelos de procesos futuros con acordes con las necesidades de optimización y agilidad.
• Asegurar la conexión entre equipos, áreas, personas, para determinar cómo lograr sus objetivos estratégicos tan eficientemente como sea posible.
• Definir cómo se deben cambiar los procesos de la organización para soportar los diferentes experimentos y ajustes en pro de la agilidad.

Diseñador (Comunicaciones)

En la adopción Scrum, el Diseñador apoya las labores de comunicación y difusión de información hacia las partes interesadas. Aunque este rol no está directamente involucrado en las actividades de adopción, resulta clave a la hora de generar más “seguidores” de Scrum. Adicionalmente este rol tendrá la responsabilidad de:

• Crear material audiovisual de apoyo para comunicar el propósito de la adopción, convocar a eventos, comunicar logros, lo cual fortalece el apoyo al proyecto de adopción.
• Ajustar la comunicación según el público, cuidando las reglas de negocio y asegurando un mensaje eficiente.
• Apoyar a las labores de comunicación de los demás miembros del equipo de adopción, para asegurar pertinencia y coherencia en el mensaje a transmitir.

Coach ontológico

“Coach”: Entrenamiento. “Ontología”: Ciencia del ser.

El Coach ontológico se enfoca en un aprendizaje transformacional, mediante el cuestionamiento, auto observación, reflexión y acción para el logro de resultados extraordinarios con efectividad y bienestar.

• Establecer una relación formal con las personas con el fin de desarrollar su potencial, y motivarlos al cambio.
• Plantear el desarrollo de habilidades y ajustes en la estrategia de relacionamiento con el objetivo de generar un clima organizacional que produzca sinergia entre el líder y las personas con las que trabaja para lograr el éxito.

1.2.4. Backlog del proyecto

Similar a lista de producto (product backlog), en un proyecto de adopción Scrum, el Backlog es la lista ordenada de todas las tareas y requerimientos que pueden ser necesarios para llevar a cabo la adopción.

Los elementos que componen el backlog de la implementación pueden ser agrupados en siete épicas, según su afinidad o campo de acción, estas épicas representan las dimensiones de una organización que al interactuar permiten el desarrollo de su misión, pues se contemplan las personas, los procesos, la tecnología y los clientes.

Los elementos incluidos en el Backlog se derivan del análisis inicial y la visión del proyecto, pues son estos elementos los que permitiran llevar la organización desde el estado actual hacia el estado planteado en la visión. Revisemos a continuación cada uno de los siete componentes que conforman el Backlog:

Clima y entorno de trabajo

Como se ha mencionado de manera reiterada, para que la adopción de Scrum sea exitosa, es necesario contar con el compromiso y apoyo de todos los colaboradores de la organización que están involucrados en el proyecto, por lo que es necesario garantizar que el ambiente en el cual los individuos ejecutan sus actividades sea adecuado, esta es la razón por la cual es un factor relevante dentro del Backlog.

Esta épica hace referencia a todos aquellos elementos que son necesarios para propiciar el ambiente laboral que facilite la adopción de Scrum, estos elementos pueden ser:

• Del tipo social: que contempla el fomento de un ambiente tranquilo, libre de conflictos, donde se promueva la tolerancia y el respeto.
• Del tipo psicológico: son aquellos elementos que afectan la psiquis del trabajador, por ejemplo, el nivel de estrés, el agotamiento físico, las emociones, etc.
• Del tipo físico: son aquellas condiciones sujetas a la infraestructura y condiciones físicas bajo las cuales los colaboradores ejecutan sus actividades cotidianas, por ejemplo, la temperatura, la humedad, la circulación del aire, el ruido, el mobiliario, etc.

Algunas recomendaciones para construir un adecuado clima y entorno de trabajo son:

• Diseñar el sistema de recompensas e incentivos:

  Las recomensas e incentivos no necesariamente deben ser de tipo económico, se pueden utilizar sistemas de recompensas como el envío de tarjetas kudo, una manera de demostrar aprecio y agradecimiento por los colaboradores del equipo de una manera sencilla, de bajo costo y muy valiosa (Kudo Box).

  Al momento de diseñar una recompensa, se debe evitar caer en acciones como prometer por adelantado; se debe procurar que las recompensas sean continuas, no solo una; las recompensas se deben dar en público, no en privado; es importante recompensar el comportamiento, no solo los resultados y finalmente no solamente los subordinados deben ser recompensados, los compañeros también deben ser reconocidos.

• Capacitación en comunicación efectiva:

  La comunicación efectiva no se trata solamente de enviar un mensaje a un receptor a través de un canal, sino que debe garantizar que el mensaje es recibido de tal manera que se cumpla el propósito deseado por el emisor. Para lograr este objetivo se debe asegurar que el mensaje es de fácil comprensión y que al momento de la comunicación el emisor considera las características del receptor, permitiendo enviar el mensaje considerando dichas características. En algunas ocasiones, la comunicación efectiva es una habilidad que no está muy desarrollada dentro del equipo, por lo que propiciar espacios de capacitación sobre este tema, genera valor al proceso de adopción de Scrum.

  Vale la pena recordar que uno de los principios del manifiesto ágil es promover la comunicación cara a cara pues es el método más eficiente y efectivo para comunicar información.

• Fortalecer la felicidad de los trabajadores (12 pasos de la felicidad):

  Contar con colaboradores felices tendrá un impacto positivo sobre la adopción de Scrum pues aunque no es una regla que un colaborador feliz, sea un colaborador comprometido, si es muy probable que su felicidad propicie su motivación y compromiso. Existen 12 pasos respaldados por la ciencia que permiten cultivar la felicidad de un individuo:

  • Agradecer a alguien diariamente.
  • Dar u ofrecer algo a otra persona.
  • Ayudar a quien lo necesita, puede ser un colega.
  • Comer bien, consumir alimentos saludables.
  • Hacer ejercicio con regularidad para cuidar la salud.
  • Descansar bien, dormir lo suficiente.
  • Nuevas experiencias, probar cosas nuevas.
  • Caminatas al aire libre que permitan disfrutar de la naturaleza y escapar de la rutina.
  • Aprender y adoptar prácticas de meditación.
  • Socializar, relacionarse con nuevas personas que permita desarrollar conexiones.
  • Apuntar a un objetivo.
  • Sonreir constantemente.

  Dentro de la organización se pueden fomentar actividades enfocadas a algunos de esos pasos, por ejemplo propiciar espacios para la actividad física o la meditación.

• Inteligencia emocional:

  La inteligencia emocional es la capacidad de "entender y manejar tus propias emociones, y las de las personas que te rodean", según Daniel Goleman, un psicólogo estadounidense. La Inteligencia Emocional es el título dado a un grupo de capacidades emocionales que hacen que las relaciones humanas funcionen eficazmente. La inteligencia emocional permite:

  • Mejorar las relaciones con nosotros mismos y con quienes nos rodean.
  • Ser líderes más eficaces y exitosos.
  • Tener más control de nuestras emociones en lugar de dejar que nuestras emociones tomen el control de nosotros.
  • Los líderes que pueden trabajar bien con otros pueden fomentar el éxito individual, de equipo y organizacional.
  • Cuando estamos en contacto con nuestras emociones somos capaces de tomar el control de nuestras emociones y nuestras acciones, en lugar de dejar que nuestras emociones nos controlen.

  Dentro de la organización, fomentar el desarrollo de esta capacidad dentro de los colaboradores permitirá mejorar el ambiente laboral.

• Estilos de liderazgo:

  Existen múltiples estilos de liderazgo, seleccionar uno o por qué no una mezcla de los elementos de varios de ellos, dependerá de las características del ambiente laboral y los colaboradores del equipo de trabajo, por ejemplo, se podría tener un liderazgo "dictador" donde un gerente es quien dirige completamente el trabajo de todos los colaboradores o un estilo "anarquista" en el que se empodera al trabajador y no es necesario centralizar el poder en una sola persona.

Automatización y procesos

La automatización y procesos es el componente del Backlog que incluye aquellos aspectos que generan un impacto sobre la forma en la cual se ejecutan los procesos, procedimientos y en general las tareas que permiten el desarrollo del sentido (misión) de la organización. Durante el análisis inicial, se identifican aquellos procesos o flujos de procesos que requieren ser modificados, eliminados o creados considerando desde luego los principios, artefactos, ceremonias, emisores de información y prácticas descritas en Scrum, toda esta información puede ser consultada en The Scrum Map 2021.

A continuación se describen algunas recomendaciones para la gestión de la automatización y procesos dentro del Backlog:

• Adopción de prácticas Scrum:

  Recordemos que Scrum presenta 6 etapas en su ciclo de vida, las cuales contienen en total 17 prácticas que permiten llevar a cabo un proyecto bajo este marco de trabajo. En este punto, la organización debe definir en el Backlog de la adopción cuáles de esos elementos presentados por el Framework desea adoptar dentro de la organización, por ejemplo:

  • Si se requiere la definición de un cronograma de entregas.
  • Si se requiere de la definición de la arquitectura del producto y en caso de que así fuera, las herramientas de software, la infraestructura, la información, etc. necesarios para la definición.
  • Las condiciones de tiempo, lugar y herramientas que se utilizarán durante la ceremonia de planeación del Sprint o cualquiera de los demás eventos.
  • Las condiciones bajo las cuales se realizará el envío de entregables a los clientes.
  • La estructura con la cual serán construidas las historias de usuario y las tareas.

• Estructura de equipos y definición de roles:

  Aquí se abarcan los elementos relacionados con la dimensión humana necesarios para el proyecto de adopción, por ejemplo:

  • La contratación del equipo Scrum que implica la definición de los perfiles requeridos,
  • Necesidades de capacitación en caso de que el personal requiera fortalecer sus capacidades.
  • Los recursos necesarios para la contratación y/o capacitación en términos de tiempo y dinero.
  • La definición de un plan de colaboración donde se definan cómo las distintas partes interesadas y los miembros del equipo participan, se comunican y colaboran durante todo el proyecto.

• Evaluación de las herramientas/tecnologías utilizadas para determinar capacidades:

  Dentro de la épica de automatización y procesos es útil considerar herramientas tecnológicas que faciliten la gestión de proyectos, este tipo de herramientas facilitan la gestión del líder del proyecto, mejoran la gestión de las tareas, promueven y favorecen el trabajo colaborativo y permiten contar con una mejor visibilidad del avance que ha tenido el proyecto. Para la selección de la herramienta es importante considerar elementos como lo son:

  • Que permita la colaboración entre los diferentes miembros del equipo.
  • Que permita hacer una correcta gestión de los recursos asociados al proyecto de adopción.
  • Que facilite el cálculo y manejo de las métricas y los reportes.
  • En caso de que se requiera que cuente con integración con las demás herramientas que se manejan dentro de la organización.
  • Que se cuente con el soporte y acompañamiento necesario para la correcta implementación de la herramienta.
  • Desde luego los costos de la herramienta frente a los beneficios que trae a la organización.

• Construcción del tablero de delegación:

  Esta herramienta permite definir de manera colaborativa y didáctica entre todos los miembros del equipo el nivel de decisión sobre distintos aspectos de la organización lo que facilita mostrar con claridad la delegación a la vez que se fomenta el empoderamiento de todos los integrantes del equipo.

  Por lo general el tablero se compone de una matriz, en la primera columna se enlistan los aspectos sobre los cuales se va a establecer el nivel de delegación (por ejemplo, días de vacaciones, horarios, herramientas de software, contratación, etc.), en la primera fila se definen los niveles de decisión que pueden ser de tipo numérico (por ejemplo, una escala de 1 a 7 donde 1 implica que no existe nivel de decisión, es decir que la decisión la toma el líder del equipo y 9 implica que existe total autonomía por parte del colaborador para tomar la decisión), la escala también puede ser de tipo cualitativo (por ejemplo, informar la decisión, vender la alternativa, consultar antes de decidir, llegar a un acuerdo, asesorar, preguntar o delegar). En las intersección se coloca el nombre o una fotografía de cada miembro del equipo según el nivel de decisión que tiene sobre cada uno de los elementos que están siendo objeto de evaluación. La siguiente ilustración presenta una idea de la forma en la que podría constituirse un tablero de delegación.

• Procesos de autorización y toma de decisiones:

  En esta épica se deben considerar aquellas acciones que permiten el fortalecimiento del desempeño del equipo de trabajo producto de flujos de autorización claros y procesos de toma de decisiones que faciliten la ejecución de las actividades de cada miembro del equipo de trabajo. Para determinar estos procesos de autorización y toma de decisiones se recomienda:

  • Identificar aquellas tareas que requieren una pequeña cantidad de tiempo para completarse, pero que suelen acumularse con el tiempo (por ejemplo: programar reuniones, revisar y eliminar correos electrónicos no deseados, etc.)
  • Identificar aquellas tareas que requieren poca habilidad y que pueden ser delegadas facilmente, de hecho este tipo de tareas pueden ser oportunidades de automatización.
  • Identificar aquellas tareas que requieren mucho tiempo, para realizar su división en tareas más pequeñas que puedan ser delegadas a otros miembros del equipo de trabajo.
  • Identificar las habilidades de cada miembro del equipo de trabajo, de tal manera que le sean asignadas las tareas para las cuales está calificado.
  • Definir los niveles de autoridad, por ejemplo, a través del tablero de delegación, permitirá que cada integrante del equipo de trabajo conozca qué decisiones puede tomar y cuales debe consultar, de esta manera el flujo de trabajo será mejor.
  • En las situaciones en las que se deba consultar alguna decisión, es importante definir claramente a quién se debe solicitar la aprobación, a través de qué canal, cuánto tiempo demora la aprobación, etc.

• Oportunidades de automatización + Robot Process Automation:

  La automatización hace referencia al uso de la tecnología para realizar un paso o serie de pasos de manera correcta y consistente con intervención humana limitada o nula. Por lo general automatizar actividades dentro de la organización se refleja en una mayor productividad, mejor confiabilidad y controles más sencillos, a veces la decisión de automatizar es difícil debido a sus altos costos de implementación y complejidad del alcance, una tecnología de automatización es la Robot Process Automation (RPA) que permite a los robots de un software desarrollar tareas en un computador tal como las haría un humano.

  Los siguientes son algunos tipos de actividades que pueden ser consideradas para automatización:

  • Las tareas repetitivas
  • Las tareas que consuman grandes cantidades de tiempo.
  • Las tareas propensas a errores.
  • Las tareas con un rendimiento de baja calidad.
  • Las tareas que involucran múltiples personas y pasos. Para que la automatización tenga éxito, una vez se hayan seleccionado las actividades a automatizar se debe garantizar que dichas actividades:
  • Tengas pasos bien definidos y basados en reglas.
  • Sean tareas lógicas.
  • La entrada de la tarea pueda ser ingresada aun sistema de Software.
  • La entrada de un proceso puede ser descifrada por los Sostemas de Software.
  • El sistema de salida es accesible.
  • Los beneficios son mayores a los costos.

Motivación y desarrollo del equipo

Contar con un equipo motivado ayudará a que el proyecto de adopción de Scrum sea exitoso, por lo que dentro de esta épica o componente del backlog se incluyen las condiciones que permiten a los miembros del equipo sentirse motivados, con este objetivo es necesario identificar cuáles son lo motivadores de cada persona, pues en definitiva, estos motivadores varian de una persona a otra pues están ligados a particularidades de las personas, como su personalidad, gustos, prioridades, metas, expectativas de vida, etc. A continuación se describen otras actividades que podrían fortalecer la motivación y el desarrollo del equipo de trabajo:

• Definición de Niveles de Servicio (ANS)

  La definición de los niveles de servicio permite establecer objetivos claros sobre la calidad que deben tener las salidas del proyecto de adopción de Scrum, estos niveles de servicio deben ser documentos en un documento denominado Acuerdo de Nivel de Servicio (ANS o SLA) y son costruidos entre todas las interesadas directas en el resultado del proyecto. Involucrar a los desarrolladores en la construcción de los ANS incrementará la motivación y apropiación del proyecto.

• Evaluación y definición de las estrategias de comunicación

  Anteriormente se mencionó la importancia de capacitar sobre comunicación efectiva a los desarrolladores para mantener un buen clima y entorno de trabajo, bien, en este punto, es necesario realizar además de la capacitación, una evaluación sobre el impacto que podrían tener diferentes estrategias de comunicación (canales, frecuencia de las comunicaciones, responsables, mensajes, medios de entrega de los mensajes, etc.) sobre el desarrollo del proyecto de adopción. Es importante que la selección de la estrategia de comunicación que utilizará el equipo sea una decisión en la que se involucre a los miembros de equipo, además, la estrategia de comunicación seleccionada debe ser evaluada constantemente para identificar oportunidades de mejora.

• Correcta negociación y contratos (orientados a ciclos de desarrollo ágil)*

  Para la formalización de los vínculos laborales o comerciales, se establecen los contratos, una forma generar motivación dentro del equipo de trabajo es diseñar dichos contratos con un enfoque hacia la agilidad, por ejemplo, si se definen incentivos de tipo económico en forma de comisión por cumplimiento de objetivos o entrega de resultados, los pagos de estas comisiones podrían alinearse con la finalización de los Sprints en los que se generan estos resultados, de esta manera los miembros del equipo podrán ver sus esfuerzos recompensados con una mayor frecuencia, por lo que se podrían entregar recompensas más pequeñas a una mayor frecuencia, en lugar de una de mayor cantidad pero en una única ocasión.

Relación con el cliente

Esta épica aborda aquellos elementos que afectan las relaciones con los clientes tanto internos como externos que se ven involucrados en el proyecto de adopción de Scrum. Por ejemplo, los proveedores como clientes externos y los empleados como clientes internos. A continuación se proponen algunas acciones que podrían favorecer la relación con los clientes internos involucrados en el proyecto de adopción:

• Estrategias para disminuir rotación del personal

  Definir una estrategia que disminuya la rotación del personal permite garantizar una estabilidad dentro del equipo que está trabajando en la adopción, garantizando que no existirá pérdida de conocimiento ni retrocesos en la ejecución del proyecto al tener que capacitar a los integrantes del equipo que lleguen como reemplazo de los que salen.

  La motivación es un aspecto que está muy ligado al compromiso y desde luego a generar en los colaboradores el sentido de pertenencia necesario para evitar que abandonen la organización, por lo que considerar, por ejemplo, los factores de motivación CHAMPFROGS, ayudará a identificar qué motiva a cada persona que compone al equipo para diseñar una estrategia efectiva.

• Definición de los planes de capacitación

  La capacitación continua de colaboradores además de mejorar el desempeño de sus actividades, tiene un impacto favorable sobre la motivación. Las capacitaciones pueden fortalecer las habilidades técnicas o blandas de la persona o incluso sensibilizar al colaborador sobre aspectos de la organización como los valores, la cultura, etc.

  Un instrumento que se puede considerar dentro del backlog es la definición de un plan de capacitación donde se definan los temas que serán abordados a través de capacitación, la duración, el mecanismo que se usará para entregar la capacitación (presencial, virtual, e-learning), los responsables de cada capacitación, etc.

• Desarrollo de habilidades para el manejo de conflictos

  La relación con los clientes puede generar conflictos por múltiples motivos como insatisfacción o inconformidad por un resultado, intereses opuestos, puntos de vista diferentes, mala comunicación, etc. Por esta razón considerar el desarrollo de habilidades de resolución de conflictos en los miembros del equipo de adopción de Scrum permitirá que se identifiquen a tiempo los posibles conflictos y se resuelvan de manera proactiva, antes de que suceda.

• Preparación de Scrum Masters

  Recordemos que el Scrum Master es el rol responsable de asegurar que Scrum es entendido y adoptado en la organización, garantizando que las actividades ejecutadas por el equipo Scrum se realizan de manera alineada con la teoría, prácticas y reglas de Scrum.

  El Scrum Master tiene responsabilidades asociadas a la coordinación y la motivación del equipo así como la gestión de impedimientos y seguimiento del proyecto, por lo que capacitar a diferentes miembros dentro de la organización en este rol, será un elemento estratégico en el éxito de la adopción de Scrum. Evaluar qué personas deben ser capacitadas por el papel que juegan dentro de la compañía debe ser considerado dentro del backlog de la adopción.

• Definir un correcto sistema de Feedback

  Definir la estrategia mediante la cual se dará retroalimentación a los clientes, permite establecer el mecanismo más apropiado para comunicar las críticas o aspectos negativos del desempeño de un colaborador o la baja calidad de algún entregable, la estrategia que se defina debe contemplar la importancia de hacer sentir cómodo a quien va a recibir la retroalimentación, la forma en la que transmiritá el mensaje y desde luego la exaltación de aspectos positivos que genere en quien recibe la retroalimentación una emoción positiva de curiosidad o interés en la mejora de la productividad.

Mediciones

Este componente del Backlog se enfoca en aquellos elementos dispuestos para medir el desempeño del proyecto desde diferentes perspectivas, se deben considerar aspectos como:

• Definición de métricas para el equipo

  Las métricas asociadas al equipo son aquellas que arrojan información sobre la calidad de los entregables, la productividad, el cumplimiento de las metas y en general aquellos aspectos que permiten medir la efectividad del equipo de adopción de Scrum.

• Definición de métricas para dar seguimiento a los proyectos

  Cada proyecto debe ser revisado desde las diferentes áreas que lo conforman por ejemplo, el progreso del cronograma, la calidad, las finanzas, el recurso humano, etc. Es importante resaltar que para dar seguimiento al proyecto de adopción de Scrum se pueden utilizar algunos emisores de información propios de este marco de trabajo, por ejemplo, el burndown chart o el diagrama de flujo acumulado.

• Definición de la frecuencia de medición y las fuentes de información

  Además de definir qué se medirá es importante establecer la frecuencia de la medición, asegurando que esta no es muy corta para que la medición se convierta en una sobrecarga laboral para el responsable de la medición, ni muy larga que no se puedan identificar a tiempo oportunidades de mejora o acciones correctivas en caso de que la ejecución del proyecto esté teniendo desviaciones. Adicional a la frecuencia de la medición, se deben identificar las fuentes de la información que se utilizará para el cálculo de la métrica, por ejemplo, la base de datos y su ubicación, el reporte generado por la herramienta de software, los registros de un procedimiento, etc.

• Herramientas y automatización de mediciones (BI)

  Dentro de la ejecución del proyecto se pueden utilizar la Inteligencia de Negocio (Business Intelligence - BI), consiste en un conjunto de procesos y métodos de recolección, almacenamiento y procesamiento de datos que permite extraer de estos información que soporta la toma de decisiones. Algunos ejemplos de procesos de inteligencia de negocios son:

  • Minería de datos: mediante el uso de datos, estadística y técnicas de machine learning permite descubrir tendencias en grandes conjuntos de datos.
  • Generación de informes: permite compartir el análisis de datos con las partes interesadas para conocer la evolución de un proyecto y tomar decisiones, actualmente la generación de informes es una actividad que se puede automatizar con ayuda de software.
  • Análisis descriptivo: para este tipo de análisis se utilizan los datos históricos que mediante el uso de estadística busca entender el comportamiento de los datos.
  • Consultas: permite la extracción de datos específicos según las necesidades de los usuarios.
  • Análisis estadístico: a partir del análisis descriptivo, se realiza una exploración aún más profunda en los datos, para comprender mejor las tendencias o patrones.
  • Visualización de datos: el análisis es presentado mediante gráficos que facilitan la comprensión de la información por parte del analista y del consumidor final de la información.

• Definición de los informes que debe generar el proyecto

  Dentro del Backlog del proyecto de adopción se deben contemplar los informes que serán generados, para ello es importante que todos los informes sean valiosos, es decir que presenten información útil, se deben evitar al máximo sobrecargar a los miembros del equipo con elaboración de informes poco relevantes.

  Es importante contar con informes que presenten un panorama general del desempeño del proyecto de adopción pues este permitirá tomar las medidas correctivas a tiempo en caso de que se identifique deuda técnica u otro tipo de problemas durante la ejecución del proyecto.

Planeación y calidad

Esta épica del Backlog agrupa aquellos elementos a considerar relacionados con la planeación del trabajo, es decir definir las actividades que se van a ejecutar, los tiempos asignados a cada actividad, los recursos que serán necesarios, los criterios de calidad que tendrán las actividades, entre otros. A continuación, se mencionan algunas acciones que ayudarán con la planeación y definición de los criterios de calidad del proyecto de adopción:

• Definición de los sistemas de Planeación del trabajo

  Los sistemas de planeación del trabajo permiten definir las actividades, responsables, los recursos, la duración y en general todos aquellos elementos que son necesarios para el buen desempeño del proyecto de adopción. Esta planeación, puede ser realizada mediante el uso de herramientas, como por ejemplo, un tablero kanban, el cual permite mapear y visualizar el flujo de trabajo y los componentes clave del proyecto, el tablero kanban puede ser físico o digital y básicamente se compone de filas donde se colocan las actividades a ejecutar y en las columnas se colocan los estados que pueden ser asignados a cada actividad (por ejemplo: por hacer, en proceso, revisado, terminado). Por lo general para relacionar las actividades se utilizan tarjetas que contienen la información más relevante de la actividad, estas tarjetas se van moviendo a través del tablero y se van cambiando de estados a medida que se avanza en la ejecución del proyecto.

• Capacitación y revisión sobre los sistemas de estimación del trabajo

  Además de identificar las actividades del proyecto, es importante realizar una estimación del trabajo que será necesario para ejecutar las actividades, para esto, la capacitación y revisión de los diferentes sistemas de estimación de trabajo se convierte en un elemento a considerar dentro del Backlog, la selección del sistema que se usará en el proyecto, dependerá de las condiciones de la organización donde tendrá lugar el proyecto. A continuación se presentan algunas técnicas de estimación del trabajo:

  • Registros históricos: esta técnica utiliza los registros del trabajo requerido para la ejecución de las actividades de proyectos anteriores, con la información histórica disponible, se calcular el valor promedio que tomará la actividad. En caso de no contar con el registro de la actividad, se pueden considerar actividades similares que si cuenten con dichos registros.
  • Juicio de expertos: esta técnica consiste en consultar expertos en las actividades objeto de estimación, los expertos utilizan su conocimiento y experiencia para proporcionar el valor estimado del trabajo requerido por la actividad.
  • Desglose del trabajo: esta técnica funciona para las actividades que por su complejidad dificultan la estimación del trabajo que requieren, para ello se propone desglosar la actividad en tareas más simples, de las cuales se pueda realizar la estimación y una vez se haya estimado cada tarea, se integran de tal modo que se pueda conocer el trabajo general de la actividad.
  • Project Evaluation and Review Techniques(PERT): es un algoritmo fundamentado en la teoría de redes y que como resultado final entrega un cronograma para el proyecto, esta técnica de estimación contempla tres tipos de tiempo (optimista, más probable y pesimista) además de la criticidad de las actividades.

• Cumplimiento de plazos

  Una vez se tienen identificadas las actividades del proyecto y estimado el trabajo que requerirán, es necesario definir los plazos de cumplimiento y las acciones que se llevarán a cabo en caso de incumplir estos plazos.

• Definición de las Auditorías de Proceso y Producto:

  Las auditorías realizadas al proceso permitirán identificar desviaciones en la ejecución del proyecto o deficiencias en la calidad de los entregables, las auditorías se pueden realizar considerando criterios de aseguramiento o de control de la calidad:

  • Aseguramiento de calidad: las auditorías enfocadas al aseguramiento de la calidad, evalúan el cumplimiento que durante la ejecución del proyecto se le está dando a los procesos y normas que se han definido para el proceso de adopción de Scrum, esta auditoría revela, por ejemplo, si los miembros del equipo están omitiendo intencionalmente actividades definidas dentro de las prácticas definidas, si las herramientas no están siendo utilizadas de manera adecuada, etc.
  • Control de calidad : las auditorías enfocadas an control de calidad se enfocan en las revisión de los incrementos que se entregan como resultado de la ejecución del proyecto, validando que son acordes con los criterios de terminados o los criterios de calidad que se hayan definido.

Excelencia técnica

La épica de excelencia técnica abarca aquellos marcos de trabajo, metodologías, técnicas, herramientas, etc. que se pueden incluir dentro del proyecto de adopción de Scrum para enriquecer el desarrollo del mismo en sus diferentes fases, a continuación tenemos algunos ejemplos de las técnicas que se podrían considerar para la ejecución del proyecto de adopción:

• Técnicas para el levantamiento de requerimientos

  El levantamiento de requerimientos es una de las etapas más relevantes dentro del desarrollo de cualquier proyecto, pues de la claridad de estos requerimientos dependerá en gran medida la conformidad de las salidas del proyecto. Algunas técnicas que se pueden considerar para el levantamiento de requerimientos son:

  • Design Thinking: es una actitud hacia el diseño con relación a la empatía, la creatividad y la racionalidad, permite el diseño de productos, sistemas y problemas más abstractos como los servicios. Esta técnica facilita el entendimiento de las necesidades de los usuarios y la experimentación para mejorar los entregables realizados.
  • Grupos focales: esta técnica que permite captar el sentir, pensar y vivir de los individuos a través de su opinión, por lo general es una entrevista grupal donde participa el investigador, quien a partir de las respuestas que los individuos dan a las preguntas, además de su lenguaje corporal, puede recolectar información valiosa sobre lo que desean o necesitan (requerimientos).
  • Entrevistas: las entrevistas buscan a través de una conversación entre dos personas realizar un intercamio de ideas u opiniones, esta técnica permite recolectar los requerimientos de forma directa con el involucrado, mediante un encuentro cara a cara.

• Técnicas/Herramientas para diseño de producto

  Otro tipo de técnicas a considerar son las enfocadas al diseño del producto, están enfocadas en la generación y desarrollo de una idea para transformarla de manera efectiva en un producto funcional que satisfaga los requerimientos de sus consumidores o usuarios, algunas de estas técnicas son:

  • Mockup: es un modelo estructural a escala de un producto, el cuales se sitúa en el entorno donde será utilizado el producto para poder observar su funcionamiento, por lo general se realiza para que por una parte el resposanble del diseño pueda asegurar la capacidad del desarrollo del trabajo y por parte el usuario pueda tener una visión mucho más acertada y realista de lo que obtendrá al final del proceso de desarrollo del producto.
  • Lego: este tradicional juego infantil puede ser usado como un mecanismo de simulación del diseño de productos e incluso procesos de manufactura, facilitando plasmar ideas en un concepto más tangible.
  • Arquitectura: consiste en identificar los elementos funcionales de un producto así como sus principales componentes y las interacciones entre estos.

• Técnicas/Herramientas de desarrollo de producto

  Además de la técnica de diseño del producto es importante considerar el mecanismo a través del cual se pasará del diseño al producto funcional. Por ejemplo, en el caso que el producto a entregar sea un software, se debe decidir qué entorno de desarrollo integrado (Integrated Development Enviroment (IDE)) se utilizará o si es un servicio, cuáles serán los mecanismos para la prestación del mismo.

• Técnicas/Herramientas Pruebas de producto

  Al finalizar el desarrollo del producto, es necesario garantizar que el resultado cumple con los requerimientos, para esto se deben realizar pruebas al producto con el objetivo de detectar garantizar su conformidad con los requisitos e identificar posibles fallas o defectos para que sean corregidos antes de que el producto llegue a manos del usuario o cliente final, dentro del desarrollo de software existen múltiples tipos de pruebas, por ejemeplo:

  • Pruebas automatizadas: estas pruebas son ejecutadas a través de una herramienta de automatización, por la ejecución manual queda de lado.
  • Pruebas de integración: este tipo de pruebas validan que al poner en funcionamiento de manera conjunta los elementos unitarios que componen el software lo hacen de manera correcta.

• Técnicas DevOps DevOps es un enfoque basado en principios ágiles y lean en los que se promueve una colaboración constante entre los equipos de desarrollo, operaciones y calidad que permita la entrega de software de manera estable y continua. Algunas técnicas de este enfoque son:

  • Integración continua: esta práctica hace referencia a la integración, creación y prueba del código dentro del entorno de desarrollo cada vez que se realizan cambios, logrando descubrir fallos y subsanar posibles errores en el menor tiempo posible.
  • Despliegue continuo: va más allá de la entrega continua pues a diferencia de esta, se reduce la intervención humana, es decir que el despliegue se realiza de manera automática en el momento que el código para todas las pruebas.
  • Chaos Monkey: es una herramienda desarrollada por Netflix que permite probar la resistencia de la infraestructura de T.I al exponerla a fallas intencionales y pseudoaleatorias para probar como responden los sistemas ante dichas interrupciones; estas fallas permiten detectar debilidades en los sistemas para su futura solución.
  • Microservicios: es un enfoque que busca desarrollar una aplicación de software como una serie de pequeños servicios que se ejecutan de forma autónoma pero se comunican entre sí. Dentro de las principales ventajas de este enfoque está en hecho de que al ser independiente el código de cada microservicio puede ser deplegado sin afectar a los demás.

1.3. Definir y priorizar el backlog del proyecto

En la fase anterior, inicio de la adopción, se genera la lista de los elementos que harán parte del backlog considerando cada una de las siete épicas (clima y entorno, prácticas, motivación, relación con el cliente, mediciones, calidad y excelencia técnica).

En esta fase del ciclo de vida de la adopción de Scrum se realiza la definición y priorización de las tareas y temas que fueron definidos en el Backlog.

El Consultor Scrum es el responsable del Backlog del proyecto, incluyendo su contenido, disponibilidad y ordenación, sin embargo es importante que en la definición de estos elementos, se hagan partícipes todos los miembros del equipo de adopción.

Otro aspecto que es importante resaltar es que el backlog no es un elemento estático, sino que por el contrario, evoluciona a medida que el entorno en el que se adopta Scrum cambia. Los cambios a los elementos del Backlog dependen principalmente de los cambios a las reglas y objetivos de negocio, condiciones del mercado o la tecnología, y el avance que muestre el entorno de adopción.

1.3.1. Definición del backlog

Como resultado del inicio de la adopción, se obtiene una lista de épicas o componentes los cuales son revisados, asegurando que se hayan contemplado todos los elementos que serán necesarios para la adopción de Scrum, esto implica eliminar aquellos componentes que si bien en un comienzo fueron considerados, luego de analizar mejor el análisis GAP, la visión del proyecto y las necesidades del equipo es conveniente eliminar, o por el contrario, quizá existan elementos que es necesario incluir.

Lo ideal es que el backlog sea lo más completo posible desde el inicio del proyecto, sin embargo, como ya se mencionó anteriormente, el backlog es dinámico por lo que a través de la ejecución del proyecto se pueden incluir componentes.

1.3.2. Priorización del backlog

Una vez ya se tienen los componentes del backlog se debe proceder con su priorización, para esto como se presentó en The Scrum Map 2021 se contemplan elementos como el tiempo, esfuerzo, valor funcional, dependencias, riesgos, opinión de los Stakeholders, opinión de los desarrolladores, etc.

Para priorizar las épicas o componentes del backlog se puede hacer uso de las siguientes preguntas asociadas a indagar sobre el costo y el valor:

• Asociadas al costo:
  • ¿Cuántas personas se ven afectadas?
  • ¿Qué tan difícil de adoptar es el componente?
  • ¿Qué tan costosa es la épica? aquí se deben considerar, por ejemplo, la compra de un software, el costo de contratar un colaborador, el costo de implementar un marco de trabajo, etc.
• Asociadas al valor:
  • ¿Qué tan valioso resulta para el proyecto de adopción?

La respuesta a cada pregunta se puede dar en forma cuantitativa, por ejemplo, asignar una calificación en una escala de 1 a 5, de tal manera que se pueda asignar un valor a cada épica, para luego clasificarlas dentro de una de las cinco categorías a continuación:

• Momentum Builders: las opciones de bajo costo y bajo valor pueden contribuir a ayudar a la gente a preocuparse por el cambio que ayuda con la alineación. Estos son fáciles de ejecutar pero tienen pocos resultados tangibles.
• Victorias rápidas: esta opción ayudará a mostrar el progreso visual temprano.
• Malos necesarios: estos pueden considerarse como un despilfarro, sin embargo, para una organización grande o con mayor aversión al riesgo pueden ser necesarios.
• Disruptores: estas pueden ser opciones seguras o riesgosas, son grandes cambios que afectan a muchas personas o departamentos. Estas opciones pueden necesitar dividirse en experimentos más pequeños si se seleccionan para la implementación.
• Puentes: estas opciones son más seguras y ayudarán a las personas afectadas por el cambio a construir un puente mental entre el lugar donde se cura la organización.

Si se realiza la cuantificación de las épicas es posible presnetar la clasificación mediante una gráfica

Cuando las épicas ya se encuentren cuantificadas por el costo y valor que tienen, se puede proceder a la su priorización, que está en función de las necesidades y recursos disponibles en la organización, así por ejemplo, si la organización tiene un presupuesto muy ajustado, lo ideal sería priorizar las victorias rápidas, si el presupuesto es algo, se podrían priorizar los disruptores, todo dependerá de la naturaleza y contexto de la organización.

Los resultados más importantes de esta fase son el Backlog Priorizado, que incluye lo necesario para la adopción Scrum, en conjunto con el mapa de ruta de la adopción (muy parecido al cronograma de entregas de un producto).

1.4. Ejecución del proyecto

En esta fase se ejecutan los elementos que se priorizaron en la fase anterior (Definición y priorización del backlog).

1.4.1. Ejecución.

Tal como se realiza en el desarrollo de un producto, es necesario realizar una reunión de Planificación del Sprint, en este evento el Consultor Scrum debe reunirse con el equipo de adopción para seleccionar aquellos elementos del backlog de la adopción que serán desarrollados durante el Sprint, estos elementos conformarán el Sprint backlog, adicionalmente se deben identificar las tareas que ejecutará cada miembro del equipo para completar los elementos del Sprint backlog. Es válido que se aborden varias épicas en paralelo, por lo que será necesario planificar con cuidado para evitar fallas, incumplimientos o falsas expectativas con las partes impactadas.

Durante la ejecución de los Sprints el equipo de adopción debe llevar a cabo los Scrum diarios, donde como ya se revisó previamente, se revisa el progreso diario, las actividades a ejecutar el día siguiente y si existe algún impedimento que pueda afectar el desarrollo del proyecto de adopción.

Lean Change Management

En la adopción de Scrum la experimentación juega un papel relevante, por lo que una recomendación es tomar el enfoque de Lean Change Management. Este enfoque creado por Jason Little se basa en la experimentación, el feedback y la co-creación haciendo un énfasis particular en las personas, por lo que integra las mejores ideas de Agile, Lean, Gestión del cambio y Design Thinking. La experimentación constate permite que el aprendizaje de los resultados sea mayor, fortaleciendo la capacidad de adaptación rápida al entorno. A continuacion se presenta el ciclo del Lean Change Management:

• Ideas: antes de planificar el cambio, es necesario comprender el estado actual de la organización, para esto la información recolectada durante el análisis GAP es de gran utilidad.
• Opciones: para cada opción, en el caso de la ejecución del proyecto de adopción se podrían considerar como opciones todas las alternativas que se tienen para ejecutar las tareas del Backlog, de las cuales se debe analizar su costo, valor, impacto y beneficios esperados.
• Experimentar: una vez se ha seleccionado una alternativa, se procede a su implementación para validar si funciona. La ejecución del cambio tiene tres fases:
  • Preparar: se prepara qué se hará durante el experimiento y como se abordará a las personas impactadas.
  • Introducir: se desarrolla el experimento en conjunto con las personas impactadas, lo ideal es no ejecutar muchos cambios al mismo tiempo.
  • Revisión: se revisan los resultados del experimento según lo planeado, se recopila en feedback y se valida el aprendizaje.

1.4.2. Revisión de los Sprints.

Al finalizar el Sprint, se realiza la reunión de revisión del Sprint, donde se revisará con las partes interesadas el avance del proyecto de adopción, se realizá una refinación al backlog del proyecto de adopción y se recopilará el feedback de las partes interesadas, para finalmente difundir los resultados del Sprint y su revisión, en este punto es importante considerar las recomendaciones relacionadas en la correcta definición de Sistemas de Feedback que se realizaron dentro de la épica de relación con el cliente en el numeral 1.2. Inicio de un proyecto de adopción Scrum.

Otra ceremonia que tiene lugar en esta etapa es la retrospectiva del Sprint donde se identifican las posibles mejoras que se pueden incorporar al equipo en los próximos Sprints.

Durante la revisión de los Sprints, se puede hacer uso del tablero Kanban en caso de que se esté utilizando este artefacto para la planeación del trabajo, por ejemplo, se puede adoptar un sistema de convenciones por colores para revisar las tareas, así:

• Si el entregable fue un éxito se le asigna una marca de color verde, caso en el cual la tarjeta kanban con la tarea pasará a la columna de terminado.
• Si no se revisó la tarea y queda pendiente para ser revisada en la siguiente iteración se asigna una marca de color azul.
• Si en definitiva la tarea representa un fallo, se le asigna una marca color rojo y la actividad debe ser devuelta a su fase de preparación o ejecución.

1.5. Evaluación de madurez

La evaluación de madurez de Scrum es una fase que se debe ejecutar a medida que el proyecto de adopción de Scrum avanza y no solo al final, pues es necesario medir constantemente el impacto de las diferentes acciones y experimentos sobre las personas y el negocio el general. La medición del impacto puede ser del tipo:

• Impacto cualitativo: El impacto cualitativo evalúa aspectos relacionados con los comportamientos y las relaciones que se dan entre todos los individuos que están involucrados en el proyecto de adopción de Scrum, a continuación, se presentan algunos aspectos que se pueden evaluar:

  • El comportamiento de la alta dirección considerando si en el proceso de desarrollo del proyecto de adopción de Scrum ha existido un aumento en el apoyo por parte de los gerentes hacia las iniciativas de cambio, con un enfoque hacia el cliente y la entrega de servicio.
  • La relación con los clientes, evaluando si estas se han fortalecido a través de un trabajo colaborativo que genere un mayor valor tanto para los clientes como para la organización.
  • El índice de felicidad laboral, cada colaborador involucrado en el proyecto de adopción, puede manifestar diariamente a través de algún mecanismo como una encuesta o un tablero de puntos su nivel de felicidad, esto arrojara información valiosa quer permitirá soportar la toma de algunas de las decisiones que tienen un impacto directo sobre la creatividad, productividad, motivación y compromiso del equipo.

• Impacto cuantitativo: el impacto cuantitativo se realiza a través del diagnóstico de agilidad que incluye los elementos de las siete épicas del Backlog y adicionalmente un diagnóstico que incluye las dieciséis prácticas planteadas en Scrum, esto permitirá conocer qué tan alineada está la organización con la cultura ágil y en qué grado se han adoptado las prácticas de Scrum. Para evaluar el impacto cuantitativo del proyecto de adopción se presenta en el Capítulo 2 Evaluación de madurez una herramienta que permite realizar la medición del impacto cuantitativo del proyecto de adopción de Scrum.

Dentro de esta fase de evaluación de madurez del ciclo de vida del proyecto de adopción de Scrum, además de evaluar el impacto cualitativo y cuantitativo de la adopción se debe realizar un análisis de los resultados del proyecto y la definición de una estrategia de sostenibilidad.

1.5.1. Análisis de los resultados del proyecto

Aunque no haya terminado el proyecto de adopción Scrum, es necesario no perder de vista los resultados que se van generando a lo largo del tiempo, ya que las personas se sienten más motivadas cuando perciben lo que han logrado. Si los resultados se ven pronto, el optimismo y el apoyo de las partes interesadas irá en aumento, y se fortalecerá la credibilidad en la adopción.

El seguimiento de la transformación ágil se debe dar a diferentes frecuencias durante la ejecución del proyecto, para ello es importante considerar los eventos propuestos por Scrum.

Algunas maneras de medir los resultados son:

Seguimiento a las restricciones Tiempo-Costo-Alcance

Es importante realizar un seguimiento constante a las restricciones del proyecto (no solo al final), para evitar desviaciones o incumplimientos, dado que el cambio en uno de los tres factores (tiempo – costo – alcance) tiene repercusión inversa (positiva o negativa) en al menos uno de los otros dos factores (o ambos).

	Aumentar	Reducir
Alcance	Aumentar el alcance implica retraso en la entrega, un aumento de costo o ambos.	Reducir el alcance supone una mejora en costo, adelanto en la entrega o ambos
Presupuesto	Aumentar el presupuesto implica extender el alcance, adelantar la entrega o ambos.	Reducir costo implica reducir el alcance, retrasar la entrega o ambos.
Plazo de entrega	Extender el plazo de entrega puede mejorar el costo, aumentar el alcance o ambos.	Adelantar una entrega implica aumentar el costo, reducir el alcance o ambos.

Informes regulares / informe final

Los informes son una herramienta importante para la comunicación con la alta dirección pues son una fuente de información para la toma de decisiones.

Se debe tener especial cuidado al construir informes pues aunque existen muchos formatos diferentes, existe el riesgo de hacerlos pesados, molestos y en última instancia, que no sean leídos o entendidos. La clave esta en:

• Incluir elementos críticos relevantes
• Evitar los elementos poco importantes (sobrantes)
• Generarlos en poco tiempo (de preferencia casi automáticos)

La frecuencia con la cual se generan los informes depende de la duración del proyecto, pues se debe cuidar que no sea muy corta como para sobrecargar a los responsables de la elaboración de los informes y quienes los revisan, ni muy larga como para que no se puedan tomar decisiones a tiempo que permitan corregir desviaciones durante la ejecución del proyecto. Lo recomendable es:

• Para proyecto cortos, con duración entre 1 a 6 meses, se pueden presentar informes quincenales.
• Para proyectos medios, con duración entre 6 meses a 2 años, se pueden presentar informes mensuales.
• Para proyectos largos, con duración de más de 2 años se pueden presentar informes trimestrales.

Los mejores informes de un proyecto crean responsabilidad y compromiso dentro del equipo. Al mismo tiempo, descubren problemas, reducen los riesgos y, sobre todo, garantizan que te encuentres encaminado a cumplir los objetivos del proyecto.

Otras recomendaciones para la elaboración de informes son:

Elementos críticos	Elementos opcionales	Elementos a evitar
* Nombre del proyecto. * Visión del proyecto. * Estado del proyecto. * Avance. * Proyección para el corto plazo o próximos Sprints. * Problemas u obstáculos. * Próximas tareas o actividades.	* Enlace al cronograma global del proyecto. * Entregas completas hasta la fecha. * Notas de apoyo. * Gráficas con métricas relevantes (costo-tiempo-alcance).	* Demasiado texto o lenguaje ambiguo. * Errores de gramática, ortografía y puntuación. * Sobrecarga de información. * Exceso de gráficos. * Rumores sobre posibles cambios o ajustes al proyecto.

Retrospectiva

A diferencia de la retrospectiva de Sprint, esta retrospectiva tiene un enfoque global, es decir que no está orientada solo a que participen los miembros del equipo de adopción Scrum, pues se busca que participen las partes interesadas que han sido impactadas (proyectos, equipos, gerencias, etc). Durante este evento:

• Se generan conversaciones poderosas, en cuanto a personas, relaciones, procesos y herramientas.
• Se comparten los desafíos y dificultades del día a día.
• Se proponer acciones para potenciar los buenos resultados y acciones para remover las barreras o limitantes del proyecto.
• Se socializa el progreso de la adopción con respecto a los resultados de las acciones y experimentos.

Según la duración del proyecto lo idean es que la frecuencia sea entre 3 y 6 meses, con una duración aproximada de entre 1 y 2 horas. A continuación se presentan algunas recomendaciones para realizar una buena retrospectiva:

• Establecer el escenario: consiste en dar tiempo a las personas para “llegar” y ponerse en el estado de ánimo adecuado antes de iniciar los temas de la retrospectiva, antes de iniciar.
• Circulo de apertura: lo ideal es empezar haciendo un círculo, para que todos pudieran verse entre ellos y hacer una breve introducción de lo que tratará durante la sesión.
• Recolectar datos: contar con datos a la mano ayuda a todos a “acordarse” de los aspectos relevantes a abordar, además crea un conjunto compartido de información desde diferentes perspectivas.
• Compartir experiencias: se recomienda constituir sub-grupos heterogéneos para que compartan sus experiencias.
• Indagar: entender por qué las cosas ocurrieron, cómo ocurrieron, identificar tendencias y patrones (mirar el bosque y no el árbol).
• Decidir qué hacer: elegir pocos aspectos en los cuales trabajar y crear planes concretos de acciones para intentar mejorarlos.
• Cerrar la retrospectiva: agradecer a los participantes, cerrar la reunión y pensar como mejorar las retrospectivas.

1.5.2. Definir la estrategia de sostenibilidad

Esta última parte es crucial para asegurar que todo el esfuerzo realizado durante todo el proyecto de adopción Scrum realmente quede adherido a la organización, ya que los nuevos resultados implicarán hacer las cosas de manera diferente y de forma sostenible.

Se deben considerar diferentes factores que pueden afectar los esfuerzos para sostener el cambio en la organización, como por ejemplo:

• Cambios en la estrategia.
• Cambios en el mercado.
• Cambios en el staff directivo.
• Contratación de nuevo personal.
• Diseño de estrategias y planes de reconocimiento y recompensas.
• Creación o fortalecimiento de canales de retroalimentación.

La mentalidad

En muchos casos, el cambio fracasa porque se intenta ir a las práctica sin antes cambiar la mentalidad, este error se comete por lo general por el afán de la organización en ir más rápido a la adopción de las prácticas y las ceremonias de Scrum.

Es común encontrar la situación en la que un jefe tradicional continua actuando de forma autoritaria sin cambiar su modelo de liderazgo, ni la forma en la que realiza las actividades, aunque su departamento ahora se llame “equipo ágil”.

Vale la pena resaltar que Scrum es un cambio en el paradigma organizacional que está en manos de las personas, y no por cambiar el nombre de una reunión o utilizar elementos como tableros kanban la adopción de Scrum va a tener éxito.

Costos de NO sostener el cambio

Si bien es difícil medir los costos de los esfuerzos perdidos, se debe tener en mente que los riesgos que afectan al sostenimiento del cambio son muy altos y permanecen por mucho tiempo en la memoria colectiva de la organización:

• Resultados peores que los existentes antes del cambio.
• Esfuerzos, duplicados, costos elevados.
• Objetivos más complejos con menos recursos para alcanzarlos.
• Volver a viejas prácticas, lo que implica pérdida de credibilidad y confianza en el cambio.
• Efectos desfavorables en el clima organizacional.

1.6. Gestión del cambio organizacional

La Gestión del cambio organizacional es una fase transversal a todo el ciclo de vida del proyecto de adopción de Scrum, esto se debe a que una adopción exitosa genera un cambio de cultura que permite asegurar que los cambios en la organización se implementan o adoptan sin problemas y de manera exitosa, garantizando que los beneficios sean duraderos.

El cambio es una constante en todas las organizaciones, para el caso del proyecto de adopción de Scrum, los cambios que se pueden presentar en el clima y el entorno, las prácticas, la motivación, las relaciones con las partes interesadas, las tecnologías disponibles, entre muchas otras variables son muy frecuentes y podrían ser de alto impacto, por lo cual, contar con un mecanismo para abordar dichos cambios y promover una cultura que abraza el cambio es fundamental para alcanzar y sostener el éxito del proyecto de adopción.

1.6.1. Modelo de Kotter: 8 pasos para el cambio

John Kotter, profesor de liderazgo de Harvard Business School, diseñó un modelo de ocho pasos para la gestión del cambio, estos ocho pasos son:

Crear el sentido de urgencia

Una forma de despertar la motivación inicial dentro de los miembros de la organización donde se desea adoptar Scrum es creando el sentido de urgencia, esto se logra cuando se resalta la necesidad de cambio y se comunica lo que puede suceder si no se realiza el cambio.

Es importante conocer la posición y necesidades del personal, esto facilitará identificar qué aspectos del cambio van a contribuir a satisfacer las necesidades del personal, así como las posturas que podrían utilizarse como puntos de apalancamiento para la adopción del cambio o por el contrario aquellas posturas que deben ser tratadas con mayor atención por su resistencia al cambio.

Cuando se crea el sentido de urgencia se debe evitar generar falsas expectativas sobre el cambio, por ejemplo, no es correcto exagerar los beneficios de un cambio a los colaboradores pues al culminar el proyecto se puede presentar frustración o desmotivación al no obtener los resultados que habían sido prometidos. Otra conducta que se debe evitar es generar miedo a los miembros del equipo para que se adhieran a la gestión del cambio.

Formar alianzas fuertes

Dentro de los miembros de un equipo de trabajo, por lo general surgen líderes que no necesariamente son los jefes o directivos de la organización, sino que son personas con habilidades de liderazgo y trabajo en equipo que pueden ser referentes o guías para los demás miembros del equipo, identificar estos líderes para pedir su compromiso emocional que permita construir el cambio y fomentar la necesidad de cambio en la organización.

Crear una visión clara

Al inicio del proyecto de adopción de Scrum se define una visión del proyecto, bien, es necesario también que los cambios tengan una visión clara sobre lo que se espera alcanzar y la estrategia que se abordará para adoptar el cambio, por ejemplo, las sensibilizaciones o capacitaciones necesarias, los líderes que ayudarán con la adopción del cambio, etc.

Comunicar la visión

Además de definir la visión, se debe hablar frecuentemente sobre la misma a todos los involucrados en el cambio, de tal manera que se convierta en la directriz a través de la cual se realizará la toma de decisiones y resolución de problemas. La comunicación de la visión debe incluir la disposición a responder preocupaciones y tratar las ansiedades que puedan surgir en el personal.

Eliminar los obstáculos

Cuando todos los miembros del cambio conocen la visión se debe asegurar que están alieados con esta, es decir, no es suficiente con que escuchen y memoricen el estado deseado que se quiere alcanzar con el cambio, sino que realmente todas sus actividades cotidianas son guiadas por esa visión, esto ayudará en gran medida a evitar obstáculos como la resistencia al cambio.

Frente a la visión se pueden encontrar dos casos, el primero es el de aquellos miembros del equipo que apoyan el cambio, en este caso se deben recompensar y reforzar este comportamiento, el segundo caso es de los que se resisten al cambio, caso en el cual es necesario escuchar las razones que los lleva a oponerse al cambio para definir la mejor estrategia que permita mostrarles porqué el cambio es necesario.

Se pueden presentar otros obstáculos diferentes a la resistencia al cambio, por ejemplo falta de disponibilidad de recursos, falta de conocimiento técnico, normativas, etc. sea cual sea el caso, es necesario eliminar dicas barreras para poder adoptar el cambio sin obstáculos.

Generar ganancias a corto plazo

Las metas a largo plazo por lo general suelen ser de alto costo o difíciles de alcanzar, por lo que desagregar una meta en pequeñas iniciativas permitirá alcanzar victorias tempranas, lo cual tiene un impacto en la motivación de los miembros del equipo.

No disminuir el ritmo

La retrospectiva es una herramienta que permitirá analizar qué salió bien y que se puede mejorar, esos elementos deben ser incluidos en la planeación de la ejecución de las siguientes iniciativas que conforman el cambio, lo importante en este punto es que una vez se finalice con una iniciativa, se defina la siguiente meta a alcanzar para aprovechar el impulso que se ha logrado.

Anclar el cambio dentro de la empresa

El cambio debe prevalecer en el tiempo, no puede ser solamente un proceso de gestión del cambio que se ejecuta por el tiempo que demora el proyecto, sino que se debe convertir en parte importante de la cultura empresarial de tal manera que cualquier cambio futuro sea bien recibido dentro de la organización, para esto es importante:

• Resaltar continuamente los logros alcanzados.
• Incluir los ideales y valores que se relacionan con la adopción del cambio.
• Definir planes para cuando los líderes eventualmente se vayan de la organización.

1.6.2. Resistencia al cambio

La resistencia al cambio se da cuando una persona se niega por miedo o dificultad a realizar algo nuevo o adaptarse a nuevas circunstancias, la resistencia puede ser pública, es decir que la persona manifiesta abiertamente su resistencia al cambio, o por el contrario puede ser inconciente, esta se manifiesta a través de las acciones, el lenguaje y en general el desempeño que el colaborador tiene con el cambio, pero no necesariamente el individuo manifiesta su incomodidad con el cambio.

"Una de las maneras más comunes de superar la resistencia al cambio es educar a la gente sobre ello de antemano. La comunicación de ideas ayuda a las personas a ver la necesidad y la lógica de un cambio. El proceso de educación puede incluir discusiones uno a uno, presentaciones a grupos o memorandos e informes".

John P. Kotter

A continuación, se presentan nueve recomendaciones para combatir la resistencia al cambio.

• ¿Es necesario?: si un cambio genera resistencia por una gran parte de los involucrados, vale la pena revisar si el cambio es necesario.
• El diálogo: comunicar todos los aspectos del cambio es fundamental para facilitar la adopción del mismo, pero fomentar el diálogo permitirá escuchar a los involucrados para comprender los posibles motivos por los cuales no están de acuerdo con el cambio.
• La imposición: la imposición llevará al fracaso, por lo que se debe cultivar en las personas el compromiso y el apoyo hacia la iniciativa del cambio, para esto se recomienda seguir los ocho pasos de Kotter revisados en el numeral anterior.
• Buscar alternativas: para hacer frente a la actitud de desinterés se deben buscar alternativas, negociar con las personas que se resisten al cambio, tratando siempre de buscar soluciones y no hacer un problema de ello.
• No discutir: las personas que se resisten al cambio, no tienen una buena percepción del mismo, por lo que podrían realizar malos comentarios o expresarse de manera agresiva sobre el mismo, por esta razón no se puede permitir que el diálogo se convierta en discusión.
• Dales tiempo: la implementación o adopción de un cambio es un proceso que toma tiempo, por lo que se debe ser paciente con las personas que no están de acuerdo con el mismo, una vez se les entrega la información para tratar de persuadirlos o se generan los espacios de diálogo, se les debe dar un tiempo prudencial para que reflexionen sobre la idea.
• Mostrar con claridad: muchas veces la resistencia al cambio se genera por malentendidos, por lo que buscar los canales adecuados para transmitir la información es fundamental.
• Apoyo: si en definitiva no es posible lograr que todas las personas asuman el cambio, se debe seguir adelante, pero sin dejar de apoyar a estas personas en el proceso, seguramente será más difícil para ellos.
• El impulso: encontrar el apoyo en las personas que tienen excelentes relaciones interpersonales con todos los involucrados en el cambio puede ser de gran ayuda para realizar un primer acercamiento a contemplar el cambio.

1.7. Implementación de Scrum en grandes organizaciones.

Scrum está diseñado para funcionar en proyectos de cualquier tamaño, por lo que, haciendo algunos ajustes a lo explicado en las anteriores secciones, puede ser utilizado en grandes proyectos.

A continuación, se encuentra el detalle de cada uno de los elementos que deberían considerarse como parte de la adopción de Scrum en la organización.

1.7.1. Ceremonias Scrum en grandes proyectos

Las ceremonias sugeridas para grandes proyectos de Scrum son:

Scrum de Scrums

El Scrum de Scrums es el evento enfocado en la coordinación de los Sprints para múltiples equipos dentro del mismo proyecto.

• Este evento por lo general tiene una duración de 15 minutos.
• En algunos proyectos donde la necesidad de comunicación entre equipos es vital (ej: cuando existen dependencias), se realiza diariamente.
• Se debe realizar por lo menos 1 vez por Sprint.
• Es dirigida por un Scrum Master.
• Participan los representantes de cada equipo perteneciente al proyecto.

Objetivos de la reunión

• Coordinar el trabajo de múltiples equipos que trabajan para un mismo proyecto.
• Evitar atrasos por dependencias o riesgos no identificados a tiempo.

Para garantizar efectividad en este evento, se realizan las siguientes preguntas:

• ¿En qué ha estado trabajando tu equipo?
• ¿En qué va a trabajar tu equipo?
• ¿Han tenido impedimentos?
• ¿Existen dependencias entre tu equipo y otros equipos?

Coordinación de Sprints

Cuando en un proyecto se cuenta con múltiples equipos, es importante garantizar que sus Sprints se mantienen coordinados en el tiempo, es decir, todos los equipos inician y terminan sus Sprints en las mismas fechas.

Algunas consideraciones a tener en cuenta son:

• Debería realizarse una sola reunión de planificación de Sprint.
• Podría hacerse una sola reunión de revisión del Sprint.
• Cada equipo debe realizar su propia retrospectiva. Sin embargo, es importante hacer una sesión periódica de lecciones aprendidas de todos los equipos para compartir el conocimiento adquirido en cada equipo.

1.7.2. Artefactos Scrum para grandes proyectos

El Product Backlog

A menudo, varios Equipos Scrum trabajan juntos para desarrollar el mismo producto. Para describir el trabajo a realizar sobre el producto se utiliza un único Product Backlog.

• Podría usarse un atributo del Product Backlog para agrupar los elementos que pertenecen a los distintos equipos.

1.7.3. Roles en grandes organizaciones/proyectos

Escalar Scrum en grandes organizaciones es un tema que cada vez ha requerido más atención, pues cada organización tiene sus propias necesidades, puntos de dolor, y distribución de equipos y/o productos. Uno de los puntos a tener en cuenta es la asignación de roles, dado que, para escalar Scrum, no bastará solamente con definir los tres roles fundamentales en los equipos (Development team - Scrum Master - Product Owner), pues se necesitará mejor coordinación en medio de la alta complejidad y saturación que representa un proyecto / organización grande.

Program Owner

Cuando los proyectos hacen parte de un programa, el rol de Program Owner toma bastante relevancia. El Program Owner será el rol responsable de:

• Gestionar el Product Backlog del programa.
• Garantizar la entrega de beneficios.
• Aprobar o rechazar los cambios a nivel de programa.
• Coordinar el trabajo con los distintos Product Owner de cada proyecto perteneciente al programa.

Agile Coach

El Agile Coach (Coach ágil) es quien se encarga de promover la adopción de la agilidad en una organización o proyecto grande, independiente del punto en el que se encuentre, es decir que puede involucrarse en cualquier momento sin importar qué tanto progreso se lleve.

Contar con el apoyo de un Agile Coach conlleva a fortalecer el interés del personal en la adopción de la agilidad, mejorar la ejecución de técnicas y métodos ágiles, e incluso puede brindar un acompañamiento completo en la transformación ágil de una empresa que esté fundamentada en métodos tradicionales y que no haya escuchado antes de agilidad.

Cabe hacer una aclaración importante sobre el Agile Coach, dado que este rol no se encarga de tomar decisiones técnicas, pues su trabajo es guiar a las personas para conseguir que sean ellos quienes tomen las buenas decisiones.

Para que un Agile Coach se desenvuelva con éxito, debe contar con una serie de capacidades, conocidas como “las 11 competencias del Coaching”, una guía desarrollada por ICF (International Coach Federation) para estructurar y desarrollar el proceso de Coaching.

Según ICF, las 11 Competencias del Coaching se clasifican en cuatro grupos según su funcionalidad dentro proceso de Coaching seguido con el cliente, quedando de la siguiente manera:

A. Establecer los cimientos
1. Adherirse al código ético y estándares profesionales.	Capacidad de comprender la ética y los estándares del coaching y de aplicarlos apropiadamente en todas las situaciones de coaching.
2. Establecer el acuerdo de Coaching.	Habilidad de entender lo que se necesita en cada interacción específica de coaching y establecer el acuerdo con cada nuevo cliente sobre el proceso y la relación de coaching.

B. Crear conjuntamente la relación
3. Establecer confianza e intimidad con el cliente.	Habilidad para crear un entorno seguro que contribuya al desarrollo de respeto y confianza mutuos.
4. Estar presente en el Coaching.	Habilidad para tener plena conciencia y crear relaciones espontáneas de coaching con el cliente, usando un estilo abierto, flexible y que demuestre seguridad y confianza.

C. Comunicar con efectividad
5. Escuchar activamente.	Habilidad para enfocarse completamente en lo que el cliente dice y lo que no dice, entender el significado de lo que se dice en el contexto de los deseos del cliente, y apoyar al cliente para que se exprese.
6. Realizar preguntas potentes.	Habilidad de hacer preguntas que revelen la información necesaria para sacar el mayor beneficio para el cliente y la relación de coaching.
7. Comunicar directamente.	Habilidad para comunicarse de manera efectiva durante las sesiones de coaching, y utilizar el lenguaje de modo que tenga el mayor impacto positivo posible sobre el cliente.

D. Facilitar aprendizaje y resultados
8. Crear consciencia.	Habilidad de integrar y evaluar con precisión múltiples fuentes de información y de hacer interpretaciones que ayuden al cliente a ganar consciencia y de ese modo alcanzar los resultados acordados.
9. Diseñar acciones.	Habilidad para crear con el cliente oportunidades para desarrollar el aprendizaje continuo, tanto durante el coaching como en situaciones de la vida o el trabajo, y para emprender nuevas acciones que conduzcan del modo más efectivo hacia los resultados acordados.
10. Planificar y establecer metas.	Habilidad para desarrollar y mantener con el cliente un plan de coaching efectivo.
11. Gestionar progreso y responsabilidad.	Capacidad de poner la atención en lo que realmente es importante para el cliente y dejar la responsabilidad para actuar en manos del cliente.

Tomado y adaptado de: International Coach Federation España. https://www.icf-es.com/mwsicf/ser-coach-de-icf/competencias-coaching-icf-espana

Diferencias entre el Agile Coach y el Scrum Master Es muy común pensar que el Agile Coach es el mismo Scrum Master de un equipo Scrum, y aunque tienen objetivos muy similares, su nivel de actuación no es el mismo:

• El Agile Coach actúa nivel global, suele ser externo al equipo y no pertenece a un proyecto o equipo específico, a diferencia del Scrum master que sí pertenece a un equipo o proyecto.
• El Agile Coach está a un nivel estratégico y táctico, el Scrum Master generalmente está a un nivel táctico.
• El Scrum Master está involucrado directamente con un equipo/proyecto, mientras que el Agile Coach está involucrado más desde un nivel organizativo, por lo que tiene un alcance mucho más amplio que el Scrum Master.

Line Manager:

Un Line Manager (Gerente de Línea) es el rol responsable de gestionar una línea de negocio de la organización, lo cual va desde el manejo y desarrollo del producto, calidad, procedimientos de producción y entrega del producto / servicio, crecimiento, cumplimiento de objetivos, hasta precios y estrategias.

El Line Manager actúa como un engranaje estratégico en dos aspectos:

• Decisiones relacionadas con la línea de negocio, al garantizar que los nuevos programas, proyectos, productos, servicios se desarrollen y ejecuten de manera oportuna y efectiva. Una de sus grandes responsabilidades es identificar problemas relacionados con alcanzar los objetivos de la estrategia.
• Liderazgo del personal que hace parte de la línea de negocio, promoviendo la motivación e influyendo en los empleados para que trabajen en el mejor clima posible y eficazmente hacia la consecución de los objetivos establecidos por la organización.

Dada la criticidad e importancia del Line Manager, es vital que la persona que ocupe este rol tenga un gran compromiso con la organización, muy similar a pensar y actuar como un CEO (para la línea de negocio), con una mirada holística y con mayor foco en el comportamiento de la línea de negocio en el mercado y de cara al cliente final.

Es muy común que en desarrollo de software, el rol de Line Manager tenga diferentes responsabilidades según el ciclo de vida del desarrollo: En etapas iniciales del proceso de desarrollo el Line Manager se encarga de gestionar a los interesados para la recopilación de requerimientos, mientras que en etapas más avanzadas puede coordinar la ejecución de las pruebas de aceptación del producto, o coordinar el despliegue en producción.

En algunos casos se puede confundir el rol del Line Manager con un Gerente de proyecto tradicional, sin embargo cabe la aclaración de que el Line Manager permanece ligado al producto no solo durante el proceso de desarrollo, pues continua al frente del producto en etapas de comercialización, actualización, soporte, servicio, mantenimiento y hasta la eventual salida del mercado, mientras que la responsabilidad del Gerente de proyecto termina cuando el producto se termina de construir y/o el proyecto finaliza.

El Line Manager también asegura un ambiente de cohesión y se centra en la colaboración entre todos los miembros que hacen parte de la línea de negocio (equipos de proyecto, soporte, venta, mantenimiento, etc) con el fin de cumplir con los objetivos de negocio definidos a nivel estratégico.

Diferencias entre el Line Manager y el Gerente de proyecto

Aunque el Line Manager y el Gerente de proyecto tienen responsabilidades muy similares, no se encuentran al mismo nivel de autoridad, ni representan la misma criticidad para la organización:

• El Line Manager es responsable de asegurar que el producto y/o servicio entregado cumple con las necesidades de los usuarios y expectativas del negocio durante la prestación, mientras que el Gerente de proyecto asegura el cumplimiento de los objetivos del proyecto en cuanto a tiempo, alcance, costo.
• En una estructura jerárquica típica, el Gerente del proyecto da instrucciones de trabajo a los miembros del equipo del proyecto, independientemente del departamento o grupo funcional del que provengan, mientras que el Line Manager tiene autoridad solamente sobre el personal que hace parte de la línea de negocio que tiene bajo su responsabilidad.
• El nivel de autoridad del Line Manager tiene mayor alcance en la organización, pues puede tomar decisiones sobre el producto según la estrategia del negocio, lo cual implica que puede afectar la forma en que se desarrolla, soporta, comercializa, entrega el producto / servicio; mientras que el Gerente de proyecto únicamente puede tomar decisiones a nivel de proyecto, es decir, en la construcción del producto / servicio, según lo definido por el Line Manager o equivalente.

Release Manager

El Release Manager (Gestor de versiones) es el encargado de administrar el ciclo de vida de las versiones de los productos a través de los entornos de desarrollo, prueba y producción

Es muy común que el rol de Release Managere se confunda con el de un Project Manager, sin embargo, el Release Manager se considera que tiene mayores responsabilidades ya que se involucra en distintos aspectos de la organización, como la planificación, coordinación, seguimiento, gestión de riesgos, pruebas, comunicación y lanzamiento / implementación de las diferentes versiones de los productos en la organización; mientras que el Project Manager se ocupa

El Release Manager debe contar con la capacidad necesaria para colaborar y negociar adecuadamente entre diversos equipos, con partes interesadas tanto externas a la empresa como internas.

Algunas de las funciones más representativas que debe cumplir el Release Manager, son:

• Planificar las ventanas de lanzamiento y el ciclo de vida de lanzamiento general de la versión del producto.
• Gestión de riesgos que pueden afectar el alcance de la versión.
• Comunicar todos los planes, compromisos y cambios clave del proyecto, incluidos los requisitos.
• Medir y monitorear el progreso de la versión.
• Manejar relaciones y coordinar los proyectos entre distintos equipos, para asegurar coordinación en las entregas que se realizan en los diferentes entornos (construcción, pruebas, producción)

1.7.4. Distribución de equipos

Cuando un Proyecto es muy grande y un solo Equipo Scrum no es suficiente para desarrollar todo el trabajo, será necesario contar con múltiples equipos. Algunas de las consideraciones que se deben tener en cuenta para realizar la distribución de los equipos son:

• Hasta donde sea posible, se debería contar con un solo Product Owner para el proyecto.
• El tamaño de los equipos debería mantenerse equilibrado.
• No deberían conformarse equipos especializados, los equipos multifuncionales avanzan más rápido y generan menos dependencias.
• No deberían cambiarse los miembros de equipo durante la ejecución del proyecto.

El equipo Scrum en grandes proyectos

A menudo, varios Equipos Scrum trabajan juntos para desarrollar el mismo producto. Para describir el trabajo a realizar sobre el producto se utiliza un único Product Backlog.

• Podría usarse un atributo del Product Backlog para agrupar los elementos que pertenecen a los distintos equipos.