Agile Adoption Framework

• 1. Adoptando Scrum
• 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.
• 2. Evaluación de madurez
• 2.1. Evaluación de las épicas del Backlog
• 2.2. Evaluación de la adopción de las prácticas
• 2.3. Niveles de madurez
• 2.4. Modelo de madurez de Scrum
• 3. Retos en la implementación de Scrum
• ¿Por qué fallan los proyectos de adopción de Scrum?

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.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.

2. Evaluación de madurez

En este capítulo se presenta el mecanismo que permite realizar un diagnóstico para determinar el grado de calidad con el cual se ha adoptado Scrum en una organización. Para ello se presentan dos componentes sujetos de evaluación: las épicas del Backlog y el cumplimiento de las prácticas de Scrum, que permiten conocer qué tan ágil es la organización y a qué nivel se están adoptando las prácticas de Scrum. Adicionalmente, se presenta una herramienta diseñada con el propósito de medir la madurez de Scrum en una organización. Descarga la herramienta desde el siguiente enlace: https://tinyurl.com/scrum-maturity-model

2.1. Evaluación de las épicas del Backlog

En la sección 1.5. Evaluación de madurez del capítulo anterior, se mencionó que para la evaluación cuantitativa de la madurez de Scrum se realiza la medición de la adopción de dos aspectos: las épicas del Backlog y las prácticas propuestas por Scrum.

El primer aspecto a evaluar es el nivel de adopción de las épicas o componentes del Backlog, el cuál determinará qué tan ágil es la organización, para esto se define una serie de preguntas relacionadas con cada una de las épicas, como se verá a continuación.

Clima y entorno de trabajo

En esta épica se evalúan aspectos como:

• Clima de trabajo: evalúa el tipo de ambiente en el cual los equipos de trabajo desarrollan sus actividades cotidianas, pueden ser uno de cinco tipos:

  • Combativo: es un clima de trabajo caracterizado por la presencia de conflictos, la ausencia de confianza por parte de los líderes hacia sus colaboradores, la ausencia de comunicación, y la toma de decisiones por parte de los jefes de los equipos.
  • Orientado a la cooperación: es un clima laboral caracterizado por la cooperación entre los colaboradores de la organización, las relaciones entre jefes y subordinados se desarrolla a través de conductos regulares, por lo que la comunicación suele ser buena dentro de las áreas, pero no entre las mismas. Por parte de la dirección se tiene poco o nulo interés en las necesidades u opiniones de los colaboradores.
  • Dirigido por resultados:
  • Amigable: en este ambiente de trabajo existe confianza entre los líderes y sus colaboradores, aunque las decisiones son tomadas por los líderes, tienen en cuenta la opinión y comentarios de los colaboradores, el ambiente es dinámico y proactivo donde la comunicación y la confianza fluye entre los equipos.
  • Abierto y creativo: este clima de trabajo se caracteriza por la existencia de relaciones de confianza entre los líderes y sus colaboradores, las opiniones de todos los colaboradores son tenidas en cuenta para la toma de decisiones, de hecho, es posible que las decisiones sean tomadas en conjunto. La comunicación es efectiva y se percibe el compromiso y motivación de los colaboradores, es un lugar feliz para trabajar.

  Este elemento evalúa también la existencia de un mecanismo que permita identificar el clima laboral entre los equipos de trabajo.

• Visión de la organización: busca indagar sobre el conocimiento y apropiación que tienen los miembros del equipo sobre la visión de la organización y qué tan involucrados se sienten en el proceso de alcanzar dicha visión.

• La comunicación: este elemento evalúa como se comunican los equipos de trabajo, indagando por los canales a través de los cuales se da la comunicación, por ejemplo, si solo se hace por medio de canales tradicionales como las llamadas o el correo electrónico, si se utilizan herramientas colaborativas o se aplica el principio de agilidad que hace referencia a que la mejor forma de comunicación es hacerlo cara a cara.

• Condiciones ambientales: indaga acerca de las condiciones físicas del ambiente en el que los equipos ejecutan sus actividades cotidianas, para ello evalúa no solo que existan condiciones favorables para la mayoría o todos los equipos de trabajo, sino también la disposición de la organización por mejorarlas y la cultura en los colaboradores de reportar las insuficiencias que evidencien en estas condiciones.

• Rotación del personal: la medición de la rotación del personal es una forma de conocer que tan bueno es el ambiente laboral, pues en un lugar de trabajo donde los colaboradores se sienten motivados y a gusto con la labor que realizan, la rotación es mínima, casi nula, por el contrario en ambientes laborales conflictivos y problemáticos, la rotación del personal es alta.

• Autoridad y toma de decisiones: el tipo de liderazgo presente en la organización influye en el nivel de agilidad de la misma, por lo que identificar cómo se toman las decisiones es fundamental para comprender qué tan flexible es el entorno de trabajo. En este elemento la pregunta está enfocada al nivel de consulta que realizan los encargados de la toma de decisiones a los miembros de su equipo antes de decidir.

Automatización y procesos

En el capítulo anterior se mencionó que la adopción de las prácticas de Scrum es un elemento dentro de la épica de automatización y procesos, sin embargo, la medición del nivel de adopción de las prácticas propuestas por Scrum en el modelo de madurez se hace aparte, dada la complejidad e importancia que tienen al momendo de definir el nivel de madurez con el que una organización está "haciendo agilidad".

Haciendo esta aclaración dentro de esta épica se evalúan los siguientes elementos:

• Procesos: este aspecto evalúa la existencia de procesos, procedimientos y en general reglas de operación que le permitan a los colaboradores realizar sus actividades bajo instrucciones claras, adicionalmente se evalúa qué tal flexibles son los procedimientos.

• Estructura de la toma de decisiones: además de contar con procesos definidos se indaga sobre la manera en la que se toman decisiones, es decir si existe o no un procedimiento que proporcione claridad sobre los responsables de cada tipo de decisión.

• Automatización de procesos: evalúa la capacidad que tienen los equipos de trabajo de identificar necesidades de automatización y la gestión que realiza la organización para satisfacer dichas necesidades.

Motivación y desarrollo del equipo de trabajo

Dentro de esta épica del Backlog se evalúan elementos como lo son:

• Mecanismos para medir la motivación: es importante que dentro de la organización exista un mecanismo para concer el nivel de motivación de los equipos de trabajo, por lo que este elemento busca indagar sobre la forma en la que los equipos manifiestan qué tan motivados están o los mecanismos que les permite a los líderes conocer el nivel de motivación de su equipo.

• Evolución de los equipos de trabajo: una organización para ser ágil necesita promover la evolución de sus equipos de trabajo, por lo que este elemento evalúa el nivel de acompañamiento y preocupación que tiene la organización en generar espacios de formación e interacción para propiciar la evolución de cada miembro del equipo de trabajo.

• Capacitación del personal: identificar y gestionar las necesidades de capacitación es una característica de las organizaciones ágiles, por lo que ese elemento indaga sobre la forma en la que la organización atiende las necesidades de capacitación de los equipos de trabajo.

• Manejo de conflictos: este elemento evalúa la forma en la que se resuelven los conflictos dentro de la organización, si se realiza de manera proactiva, identificando aquellas situaciones que podrían convertirse en un conflicto y solucionandolas entre todos los involucrados de manera anticipadad o si por el contrario un conflicto es abordado solo hasta que genera un indicidente o problema.

• Manejo de roles: evalúa la forma en la cual la organización tiene definidos los roles dentro de su estructura, si existe una jerarquía marcada o si por el contrario se conforma de roles flexibles.

• Flujos de información: indaga sobre la forma en la cual se realiza en intercambio de información, si se utilizan medios convencionales como el correo electrónico o las llamadas, si se utilizan plataformas, reuniones o si se dispone de la tecnología suficiente para acceder a la información en tiempo real.

Relación con el cliente y las demás partes interesadas

Esta épica del Backlog evalúa cómo es la comunicación con las partes interesadas, para lo cual se consideran dos elementos:

• Comunicación con las partes interesadas: este elemento busca identificar el canal a través del cual el equipo se comunica con los clientes o las partes interesadas, al igual que la comunicación entre los miembros del equipo, lo recomendable desde los principios del manifiesto ágil es que sea cara a cara, adicionalmente se puede apoyar en una herramienta colaborativa.

• Involucramiento con el cliente y las demás partes interesadas: trata de identificar la frecuencia con la cual el equipo de trabajo se comunica con los clientes o las partes interesadas, es decir si se hace únicamente al inicio y finalización del proyecto, con una frecuencia definida, por ejemplo semanal o mensual o durante cada iteración.

Mediciones

La medición de esta épica busca conocer la gestión que se realiza la organización sobre sus indicadores, para ello contempla tres elementos:

• Métricas relacionadas con los equipos de trabajo: indaga sobre la existencia y gestión de indicadores que permitan conocer aspectos clave sobre el desempeño del equipo de trabajo, contempla aspectos como la existencia de fichas de indicadores y el nivel de implementación de las mismas.
• Métricas relacionadas con el proyecto: la diferencia con el ítem anterior está en que los indicadores por los que se indaga están relacionados con la ejecución del proyecto.
• Frecuencia de medición: busca establecer la frecuencia con la que se realizan las mediciones dentro de la organización, esto para determinar si los períodos entre mediciones son muy cortos, muy largos, no existen o son adecuados.
• Fuentes de información: este elemento busca indentificar si en la organización existe facilidad en el acceso a los datos que permiten el cálculo de las métricas.

Planeación

En esta épica del Backlog, el modelo de madurez busca evaluar cómo se realiza la planeación del proyecto y la estimación de los requerimientos, para lo cual se contemplan los siguientes elementos:

• Planeación del proyecto: evalúa la manera en la cual se planifican las actividades necesarias para la ejecución del proyecto, esto contempla situaciones como la ausencia de planificación, una única planeación general durante todo el proyecto, la planificación a medida que se avanza en el proyecto o una combinación de las últimas dos.

• Estimación de los requerimientos: evalúa la existencia de un mecanismo para la estimación de los requerimientos y si en este proceso se hace o no participe al cliente. Adicional a esto, identifica el grado de conformidad que tienen los integrantes del equipo sobre el mecanismo utilizado para la estimación de requerimientos.

• Histórico de las estimaciones: indaga sobre la existencia de repositorios o herramientas que permitan almacenar los datos históricos de las estimaciones, de tal manera que sea posible utilizar esta información en futuros proyectos para estimar los requerimientos.

• Reuniones del equipo: este elemento busca identificar la efectividad de las reuniones dentro de la organización, su frecuencia, relevancia y en general el valor que aporta tanto al equipo como a la organización.

Excelencia técnica

Este componente del backlog se enfoca en conocer el nivel de experticia técnica de los equipos y el manejo de los requistos de calidad del producto, los elementos que lo componen son:

• Conformación de los equipos de trabajo: busca identificar la composición de los equipos de trabajo en cuanto a la relación de personal experto técnico, novato e intermedio.
• Diseño del producto: este elemento está enfocado en conocer el manejo que le da el equipo al diseño de producto, es decir si se utilizan maquetas o mockups y en caso de que así sea cuáles son las partes interesadas responsables de su ejecución.
• Calidad del producto: busca identificar los responsables y el mecanismo a través del cual se realizan las pruebas de calidad del producto.
• Entendimiento de los requerimientos: es necesario que que todo el equipo comprenda los requerimientos del cliente, razón por la cual este elemento evalúa el mecanismo utilizado por el equipo para garantizar que los requisitos son claramente entendidos por todos.

2.2. Evaluación de la adopción de las prácticas

El segundo aspecto a evaluar dentro del modelo de madurez de Scrum es el cumplimiento de las prácticas, como se mencionó en el numeral anterior, aunque en el ciclo de vida de un proyecto de adopción de Scrum, las prácticas hacen parte de la épica del Backlog "Automatización y procesos", debido a la complejidad e importancia de adoptar estas prácticas, en el modelo de madurez se consideran como un componente adicional, el cual indicará a qué nivel se esta "haciendo agilidad", en síntesis la evaluación de la adopción de las épicas del Backlog indica "qué tan ágil es una organización", mientras que la evaluación de la adopción de las prácticas de Scrum indica "qué tanta agilidad está haciendo la organización".

La evaluación de la adopción de las prácticas incluye una serie de preguntas por cada práctica, como se verá a continuación.

Definir el objetivo del producto

Dentro de esta práctica se indaga sobre:

• Se define un objetivo del producto de manera previa al inicio del proyecto donde se expliquen las necesidades a satisfacer y la calidad esperada del proyecto.
• La identificación y garantía de que todos los recursos necesarios para la ejecución del proyecto están disponibles.
• Se identifican claramente las partes interesadas en el proyecto.
• Se definen los criterios de terminado.
• Se establece el presupuesto del proyecto así como el Retorno de la inversión (ROI).
• Se definen los parámetros para la gestión de cambios durante la ejecución de los procesos.
• Se define un proceso para la gestión de riesgos.

Conformar el equipo Scrum

Las preguntas relacionadas con la conformación del equipo Scrum busca comprender:

• La definición del rol del Scrum Máster con base en lo sugerido en el marco de trabajo.
• La definición de un Product Owner como único interlocutor entre los desarrolladores y las partes interesadas en el proyecto.
• Se realiza la reunión de inicio del proyecto (kickoff).
• La comunicación directa del Product Owner con el cliente y con los desarrolladores.
• La existencia de una visión y reglas de trabajo compartidas por todos los miembros del equipo Scrum.
• La definición de un plan de colaboración donde esté claramente descrita la forma en la que se llevarán a cabo las comunicaciones y la colaboración entre todas las partes interesadas en el proyecto.
• La existencia de una cultura de auto-gestión dentro del equipo que facilite la asignacion de tareas y las actividades de investigación y capacitación.
• La identificación de las competencias necesarias para la ejecución del proyecto.
• El nivel de energía y motivación del equipo de Scrum.
• La existencia de un mecanismo para la medición del rendimiento del personal.

Construir el Product Backlog

Dento de esta práctica se evalúan dos aspectos:

• La existencia de un Product Backlog que contenga las características, funcionalidades, requisitos, mejoras y correcciones sobre el producto.
• la disponibilidad del Product Backlog para su consulta por parte de todos los desarrolladores.

Priorizar el Product Backlog

Las preguntas dentro de la priorización del Backlog evalúan la existencia de una técnica para priorizar las historias de usuario haciendo participes a las partes interesadas en este proceso, además, valida que priorización se realice únicamente con la autorización del Product Owner.

Definir el cronograma de entregas

Se consideran dos tipos de cronograma:

• Cronograma de alto nivel: este cronograma se realiza durante la plenación del proyecto y determina de manera estimanda la duración que tendrá cada uno de los Sprints.
• Cronograma detallado de lanzamiento: durante las reuniones de planificación del Sprint se realiza un cronograma detallado sobre las actividades, compromisos y las tareas asignadas a cada miembro del equipo.

Definir la arquitectura del producto

Dentro de esta práctica se evalúa:

• La ejecución del Sprint 0 donde se defina la arquitectura del producto y las tecnologías a utilizar.
• La re-definición del diseño técnico del producto durante la ejecución del proyecto si fuera necesario.
• La definición del producto mínimo viable entre el cliente y el Product Owner.
• La metodología, marco de trabajo, proceso, etc. utilizado para realizar el desarrollo del diseño del producto/proyecto.

Escribir y priorizar las historias de usuario y tareas

Las preguntas de esta práctica están enfocadas en la evaluación de la existencia de un mecanismo que permita la creación de historias de usuario y que estas últimas a su vez puedan ser desglosadas en tareas. Adicionalmente, se debe contar con un mecanismo que permita priorizar las historias de usuario considerando el valor que aportan al negocio, así como su riesgo y dependencias.

Planear el Sprint (Sprint Backlog)

Dentro de esta práctica se evalúa:

• La ejecución de la ceremonia de planificación del Sprint en la que participan todos los miembros del equipo Scrum y cuyo objetivo es seleccionar las actividades a desarrollar así como el plan para su ejecución.
• Se cuenta con un Backlog para cada Sprint, el cual es actualizado por todo el equipo.
• La ceremonia de planificación del Sprint tiene una duracion de 2 horas por cada semana de duración del Sprint.
• Se cuenta con un mecanismo para estimar el trabajo de las tareas del Backlog, considerando criterios como el tamaño, la complejidad, la duración, la cantidad de recursos, los riesgos, limitaciones, etc.
• Durante la planificación del Sprint se tienen en cuenta los riesgos asociados mediante el uso de una metodología de gestión del riesgo.

Desarrollo del Sprint

Las preguntas de está práctica buscan evaluar algunos aspectos de la ejecución de los Sprints como lo son:

• La duración del Sprint oscila entre 1 y 4 semanas.
• Se monitorean y gestionan las métricas.
• Se cuenta con una herramienta de software que permite la gestión de los proyectos de manera ágil y simple.
• Se informa a las partes interesadas durante la ejecución del Sprint acerca de los riesgos.

Sprint (Scrum diario)

En esta práctica se evalúan:

• La realización del Scrum diario para dar seguimiento al avance del proyecto, con la participación del Scrum Máster y los desarrolladores.
• Se cuenta con un Burndown Chart del Sprint que se mantiene actualizado a medida que el trabajo avanza.
• Se ejecuta una reunión diaria y corta que no sobrepasa los 15 minutos donde se abordan los aspectos más relevantes del avance diario del proyecto.
• Todos los desarrolladores conocen en qué están trabajando sus compañeros.
• El Burndown chart está disponible para todos los desarrolladores.
• El Sprint Backlog es actualizado diariamente por los desarrolladores.
• Se tienen implementados artefactos como Scrum board y/o diagramas de flujo acumulado que permitan realizar seguimiento al avance y resultados del proyecto.

Validar los entregables del Sprint

Los elementos con templados dentro de ésta práctica son:

• Se realiza la ceremonia de la revisión del Sprint, en la cual se realiza la demostración del incremento al Product Owner y las partes interesdas invitaras a la ceremonia.
• En caso de que se genere deuda técnica, esta es incluida en el Backlog junto con los nuevos elementos de la iteración para saldar la deuda técnica.
• Durante la revisión del Sprint se realiza un refinamiento del Product Backlog por parte del Product Owner y los desarrolladores.
• Durante la revisión del Sprint el Product Owner y/o las partes interesadas realizan una retroalimentación a los entregables realizados.

Retrospectiva del Sprint

Los elementos contemplados dentro de esta práctica son:

• Al finalizar cada Sprint se realiza la ceremonia de Retrospectiva del Sprint en a que se discuten las lecciones aprendidas a lo largo del Sprint. Se evalúa también la participación del Scrum Master y los desarrolladores.
• Se evalúa que las lecciones aprendidas queden debidamente documentadas.
• Se realiza seguimiento a las métricas para hacer seguimiento y control al desempeño del equipo y la ejecución del proyecto.
• Se implementan las iniciativas de mejora sugeridas durante la Retrospectiva del Sprint.

Planificación de la implementación

En esta práctica se evalúa que exista una planeación de los elementos necesarios para realizar una implementación exitosa de los incrementos generados en cada Sprint.

Implementación de entregables

En esta práctica se evalúa la implementación, es decir que una vez se finalice un entregable se ponga a disposición de los usuarios para su uso y la satisfacción de las partes interesadas con los resultados obtenidos en cada iteración del proyecto.

Cierre del proyecto

En esta práctica se evalúa:

• Al finalizar el proyecto se realice una reunión donde se oficialice el cumplimiento de todos los compromisos por parte del equipo Scrum.
• Se genere un acta de cierre del proyecto elaborada por el Product Owner y revisada y aceptada por el cliente.

Retrospectiva del proyecto

En esta práctica se evalúa que:

• Al finalizar cada proyecto exista una reunión de los socios de la organización y el equipo Scrum para la retrospectiva del proyecto en su totalidad.
• Se genere una base de conocimientos con las lecciones aprendidas de los proyectos.

2.3. Niveles de madurez

Los niveles de madurez presentan una escala a través de la cual se puede medir la capacidad que tiene la organización, en este caso, de adoptar la agilidad en su operación por un lado y por el otro de adoptar las prácticas de Scrum en su cotidianidad.

Conocer el nivel de madurez de una organización no debe ser visto únicamente como una forma de diagnóstico o de conocimiento del estado actual, sino un ejercicio que permita identificar las oportunidades de mejora y el camino para alcanzar el nivel de madurez deseado para la organización.

A continuación se presentan los niveles de madurez tanto para la adopción de la agilidad como de las prácticas de Scrum.

2.3.1. Niveles de madurez de la adopción de agilidad

En el numeral anterior se presentaron los elementos que el modelo de madurez evalúa en cuanto a las épicas del Backlog del proyecto de adopción de Scrum, según las características que la organización tenga de cada uno de los elementos, se puede clasificar en uno de estos cinco niveles, es importante resaltar que cada nivel de madurez agrupa todas las épicas del Backlog, por lo que presenta un panorama general de lo que sería, por ejemplo un nivel 1 para todas las épicas, de aquí la importancia que adicionalmente se observe el nivel obtenido para cada épica, pues se podrían dar situaciones donde por ejemplo, la relación con los clientes o partes interesadas es Nivel 4, pero las demás épicas son nivel 2, en este caso la organización a nivel general será ubicada en en Nivel 2, pero al momento de definir los planes de acción el esfuerzo por mejorar la relación con los clientes o partes interesadas será menor que el necesario para mejorar los demás componentes del Backlog.

Nivel 1: Organización pasiva

Este nivel se caracteriza por tener un clima laboral donde no existe la comunicación entre los miembros de los equipos, sus líderes y los clientes o partes interesadas. Por parte de la organización no existe preocupación por conocer y gestionar un buen ambiente laboral, las personas solo ejecutan tareas sin tener una visión clara de su trabajo a lo que sumado con condiciones ambientales deficientes, se traduce en colaboradores desmotivados que esperan una oportunidad para salir de la organización. Por la parte de los procesos, los colaboradores ejecutan las tareas que se les asigna sin instrucciones claras, muchas veces las tareas son repetitivas y de poco valor, además existe una alta confusión sobre la toma de decisiones. No se realizan mediciones, lo que dificulta promover las mejoras. No se realiza planeación, por lo general se improvisa sobre la marcha.

Nivel 2: Organización reactiva

En este nivel, la comunicación entre los miembros de un mismo equipo es buena, pero existen brechas de comunicación tanto con los líderes como con otros equipos, la comunicación con el cliente se da únicamente en caso de que presente algún problema o incidente. Si bien aún no se gestiona un buen ambiente laboral por parte de la organización, ya se contempla como una necesidad, por lo que se mide el desempeño de los colaboradores para conocer su nivel de motivación, la capacitación está en manos de los líderes de equipo. La visión es conocida por los líderes de equipo, pero no la transmiten a sus colaboradores, son encargados de dictaminar las ordenes que sus subalternos deben cumplir. En cuanto a los procesos, se tienen estructurados aquellos que son críticos. Los equipos evidencian necesidades de automatización, pero la organización no cuenta con los recursos necesarios para implementar este tipo de iniciativas. Existen indicadores, pero los mismos no se miden a menos que se solicite por un superior. Se realiza una única planeación al inicio de cada proyecto que por lo general se queda corta, durante la ejecución de los proyectos se hacen reuniones largas y frecuentes que no generan valor.

Nivel 3: Organización funcional

En este nivel la comunicación es más efectiva entre los equipos de trabajo y las partes interesadas pues se cuenta con una herramienta colaborativa. Los miembros más antiguos del equipo conocen la visión de la organización y en los equipos algunas veces se siguen órdenes y en otras ocasiones existe autonomía, sin embargo no hay claridad en qué casos aplica cada alternativa. Solo una parte de los equipos cuenta con condiciones físicas adecuadas en su lugar de trabajo. En cuanto a los procesos, los colaboradores ejecutan las actividades bajo procedimientos estandarizados que no son flexibles, se llevan a cabo procesos de automatización pero la solicitud de los mismos es demorada y con exceso de burocracia. En este punto los líderes de los equipos están más comprometidos con la motivación de su equipo y el logro de los objetivos. Existen métricas que son generadas manualmente con una frecuencia mensual. Se realiza la planeación del proyecto a partir del surgimiento de los requerimientos del cliente, las reuniones durante la ejecución del proyecto son poco frecuentes y concisas.

Nivel 4: Organización flexible

Las organizaciones pertenecientes a este nivel se caracterizan por tener un clima laboral amigable, la mayoría de los colaboradores conocen la visión de la organización, la comunicación se realiza cara a cara y la mayoría de los equipos cuentan con condiciones de trabajo adecuadas, existe un plan de capacitación y la resolución de conflictos se da de manera reactiva, la tasa de rotación de personal es baja pues la organización se considera un buen lugar para trabajar. Los equipos tienen autonomía sobre su trabajo aunque tienen un líder guía que les despeja dudas e inquietudes. En cuanto a los procesos, se ejecutan bajo estándares, pero los mismos pueden ser ajustados de acuerdo a las necesidades y el contexto de la organización, también se implementan procesos de automatización. Los líderes de equipo involucran a todos los colaboradores en la toma de decisiones. Se realiza la medición semanal del desempeño tanto del equipo como el avance del proyecto de manera automatizada a través de diferentes herramientas. La planeación se realiza de manera mensual y se manejan técnicas de estimación que no siempre resultan precisas. Las reuniones son más informales pero tienen a ser puntuales y enfocadas.

Nivel 5: Organización ágil

Las organizaciones clasificadas en este nivel se caracterizan por tener un clima laboral abierto y creativo en el que la comunicación es efectiva entre todos los miembros de la organización y las partes interesadas pues se da cara a cara y con ayuda de una herramienta colaborativa, lo que facilita la solución de conflictos de manera proactiva, la organización se preocupa por identificar y gestionar un buen ambiente laboral, la visión de la organización es compartida y adoptada por todos los colaboradores, quienes cuentan con condiciones ambientales adecuadas para la ejecución de sus actividades, existe autonomía en los equipos de trabajo para la definición de sus objetivos y su opinión es considerada por los líderes para la toma de decisiones y aceptación de requerimientos por parte del cliente. En cuanto a los procesos, se ejecutan bajo procedimientos flexibles, se identifican y gestionan de manera rápida y eficaz las necesidades de automatización. Los líderes son serviciales, su rol es de acompañamiento más no de mando y control. La organización cuenta con métricas para medir el desempeño de los equipos y el avance de los proyectos las cuales son generadas por una única herramienta de manera automatizada. Una planeación de alta visión es realizada al inicio de cada proyecto y una planeación detallada al inicio de cada iteración, las estimaciones se realizan entre todo el equipo y el cliente, lo que genera que sean precisas.

2.3.2. Niveles de madurez de la adopción de las prácticas de Scrum

Los niveles de madurez de la adopción de las prácticas de Scrum, presentan el grado en el que una organización ha adoptado las prácticas en sus actividades cotidianas, al igual que se mencionó en el numeral anterior si bien el nivel presenta el panorama general de una organización con todas sus prácticas en un mismo nivel, se puede dar el caso en el que una organización tiene cada una de las prácticas en un nivel de madurez particular, por lo que el análisis se debe hacer desde las dos perspectivas, una global y una en mayor detalle para cada una de las prácticas.

Nivel 1: Inicial

Es el nivel más bajo y corresponde a aquellas organizaciones que han adoptado muy pocas prácticas de Scrum o están iniciando en el proceso de adopción de Scrum. Este nivel se caracteriza por carecer de un objetivo del producto, la comunicación entre las partes interesadas es baja, no se tiene bien estructurado el equipo Scrum, no se realiza la planificación ni la retrospectiva del sprint y no se realizan juiciosamente los sprints diarios. Por lo general se puede presentar un bajo nivel de satisfacción de las partes interesadas.

Nivel 2: Básico

En este nivel las prácticas cuentan con una mejor estructura que en el nivel 1, se cuenta con un objetivo de producto y se garantiza la disponibilidad de los recursos antes de iniciar el proyecto, los roles de Scrum están definidos así como las reglas de trabajo, se llevan a cabo las ceremonias aunque estas no necesariamente cumplan con lo recomendado por el marco en cuanto a duración y contenido, se cuenta con un Product Backlog cuya priorización es autorizada por el Product Owner y se utilizan algunos artefactos para el seguimiento de los proyectos como el Burndown.

Nivel 3: Definido

En este nivel se involucran más activamente las partes interesadas en el proyecto ya que se definen claramente las comunicaciones y se establecen los criterios de terminado. Durante la planeación se utilizan técnicas para el cálculo de aspectos financieros del proyecto, se establecen mecanismos para el control de cambios y la gestión del riesgo. El equipo Scrum cuenta con la autonomía para gestionar su trabajo y capacitarse en temáticas que le darán valor al equipo. El product backlog se encuentra disponible para todos los desarrolladores y su priorización se realiza con una técnica definida. Se utilizan historias de usuario que son creadas de manera efectiva, desglosadas en tareas y priorizadas según el valor que aportan al negocio. Las ceremonias son realizadas bajo la estructura propuesta por Scrum.

Nivel 4: Gestionado

En este nivel se cuenta con mecanismos definidos para el seguimiento del desempeño del proyecto, de hecho, se utilizan herramientas de software para la gestión del proyecto y el seguimiento y monitoreo de métricas, además se utilizan artefactos que son actualizados diariamente y que permiten hacer un mejor seguimiento al avance del proyecto. La relación con las partes interesadas en más estrecha pues se informa además de los avances y entregables de los Sprints aspectos como los riesgos. En cuanto al equipo Scrum se estructuran planes de capacitación y sus respectivos mecanismos de seguimiento. Se cuenta con metodologías para el diseño de producto/proyecto y las lecciones aprendidas son consolidadas en una base de conocimiento.

Nivel 5: Mejorado

Este nivel se enfoca en la mejora continua de los aspectos que afectan la ejecución del proyecto, por lo que se mide el rendimiento tanto de equipo Scrum como de la ejecución del proyecto lo cual permite definir iniciativas de mejora que son implementadas buscando aumentar el nivel de satisfacción de todas las partes interesadas y mejorar el rendimiento de proyectos futuros mediante la documentación de lecciones aprendidas. En este nivel las partes interesadas se encuentran altamente satisfechas y el equipo Scrum se caracteriza por tener un alto nivel de energía y de satisfacción.

2.4. Modelo de madurez de Scrum

El Modelo de Madurez de Scrum (Scrum Maturity Model - SMM) descrito en los anteriores numerales de este capítulo, permite medir el grado de calidad con el que se han adoptado la agilidad y Scrum en la organización, para ello se presenta una herramienta que permite realizar una evaluación cuantitativa.

La herramienta permite identificar las bases y el modelo bajo los cuales operan e interactúan las diferentes áreas y equipos en una organización, evaluando qué tan alineadas están con la estrategia del negocio, la eficiencia de los prácticas y la aceptación de la agilidad en la organización.

No es solo revisar documentos o realizar una entrevista con las partes interesadas, el objetivo es entender el porqué del estado actual de la organización y lograr un acercamiento emocional con las partes interesadas, para capturar información valiosa sobre sus comportamientos y forma de actuar.

El resultado más importante de realizar el Análisis de Madurez de Scrum, es un conjunto de oportunidades de mejora para aplicar en tu organización, el cual representa la base para estructurar un mapa de ruta para mejorar las prácticas ágiles en una organización.

- Descarga la herramienta "Modelo de Madurez Scrum - SMM": https://tinyurl.com/scrum-maturity-model

2.4.1. Diagnóstico de agilidad

El diagnóstico de agilidad se encuentra en la pestaña "D. Agilidad" del archivo de excel y cuenta con la siguiente estructura:

1. Sección: cada pestaña de la herramienta presenta una sección, para este caso la pestaña "D. Agilidad" es la que contiene el cuestionario sobre el diagnóstico de agilidad.
2. Recomendaciones: se mencionan algunos aspectos a tener en cuenta antes y durante el diligenciamiento del diagnóstico.
3. Épica del Backlog: muestra la épica del Backlog que está siendo evaluada.
4. Pregunta: presenta la pregunta o situación que se debe contestar de acuerdo al contexto de la organización.
5. Opción de respuesta: cada pregunta tiene asignadas cinco opciones de respuesta, una por cada nivel.
6. Calificación: en esta columna, el responsable de aplicar la herramienta de diagnóstico en la organización, deberá colocar el número uno (1) frente a la casilla de la opción de respuesta que mejor describa la situacion de la organización.

Ahora que ya se conocen los componentes de esta sección de la herramienta, el siguiente paso es diligenciarla, para ello se debe tener en cuenta que cuando de recolectar información se trata, se debe evitar caer en el error de no utilizar los instrumentos adecuados según los interesados impactados y su disponibilidad de tiempo, o de utilizar un único instrumento para todos los momentos, lo que resulta menos efectivo, por esta razón a continuación, se presentan algunos instrumentos recomendados, los cuales pueden ser utilizados de manera individual o combinados, la decisión dependerá del contexto de la organización:

Una vez se ha seleccionado el o los instrumentos de recolección se debe asignar a cada pregunta la descripción que mejor se ajusta a la organización, para ello en la columna de opción de respuesta, se debe desplegar un menú que tiene dos valores (0 y 1), así por ejemplo, como se observa en la siguiente imagen, a la primera pregunta se le asigna el valor de "1" a la opción descrita en el Nivel 1 (valor encerrado en color verde), luego en la opción de respuesta de la segunda pregunta, esta desplegada la lista de opciones, allí la persona o equipo responsable de diligenciar la herramienta deberán seleccionar el número 1 en la lista desplegable en caso de que la opción de respuesta descrita en el nivel 2 sea la que mejor describe la situación actual de la organización, de lo contrario debe seleccionar 0 o simplemente dejar la celda en blanco (ambas acciones son equivalentes).

Este proceso se debe llevar a cabo con cada una de las preguntas descritas en esta sección de la herramienta.

Nota: es importante que al momento de seleccionar la opción que mejor describe la organización en cada pregunta, se seleccione una única respuesta, es decir que por cada fila debe existir solo un "1" asignado, en el caso que dos situaciones representen la situación de la organización, se debe seleccionar la que mejor lo hace.

2.4.2. Resultado del diagnóstico de agilidad

Una vez se ha diligenciado esta sección de ha herramienta (D. Agilidad) se procede a realizar la consulta de los resultados del diagnóstico de agilidad.

Lo primero que presenta esta sección de la herramienta es una tabla que describe los niveles de madurez que se explicaron en el numeral anterior del libro (2.3 Niveles de madurez). Esto con el objetivo de que el usuario tenga un acceso rápido a esta información para una mejor interpretacion de los resultados obtenidos con el diagnóstico.

Posteriormente se presenta la siguiente tabla:

1. Nivel: indica en nivel de madurez.
2. Elementos evaluados: muestra la cantidad de elementos evaluados durante el diagnóstico (cantidad de preguntas).
3. Calificación obtenida: muestra la totalidad de respuestas obtenidas para el nivel.
4. Porcentaje alcanzado: indica que porcentaje representa la calificación obtenida de la totalidad de los elementos evaluados.
5. Descripción: resume el nivel en el cual la organización tuvo un mayor porcentaje.

De la información descrita anteriormente es importante resaltar:

• La herramienta asigna un porcentaje a cada nivel de madurez, por lo que el nivel de madurez que haya tenido el mayor porcentaje será presentado como el más representativo para la organización, lo cual no significa que TODOS los elementos de la organización estén dentro de dicho nivel de madurez, pues pueden existir elementos en niveles de madurez inferior o superior.
• La información debe ser tomada como el punto de partida para definir las estrategias o planes de ruta que le permitan a la organización alcanzar el nivel de madurez deseado.

La segunda tabla, presenta los porcentajes del nivel de madurez alcanzado por cada una de las épicas del Backlog, se compone de:

1. Épica del Backlog: presenta cada una de las épicas del Backlog.
2. Nivel: presenta los niveles de madurez.
3. Porcentajes: están conformados por las intersecciones entre las épicas del Backlog y los niveles de madurez, cada intersección muestra el porcentaje en el que la épica se ajusta al nivel de madurez.
4. Descripción: presenta una recomendación para considerar al momento de analizar los resultados obtenidos.

De la información presentada en la tabla, es importante resaltar:

• Cada épica del Backlog puede estar presente en la organización a través de diferentes acciones que pertenecen a diferentes niveles de madurez. La tabla presenta con un mayor énfasis (tonalidad verde más intensa) el nivel de madurez que mejor representa la adopción de la épica dentro de la organización, sin embargo, pueden existir acciones de menor o mayor nivel.
• El propósito de la información de la tabla es presentar a la organización fortalezas y oportunidades de mejora existentes dentro de cada épica del Backlog, para que apartir de la identificación de estos elementos, se pueda formular una estrategia o plan de ruta que permita adoptar cada épica del Backlog en el nivel deseado por la organización.

2.4.3. Diagnóstico de la adopción de las prácticas de Scrum

Esta sección de la herramienta, permite levantar la información relacionada con la adopción de las prácticas de Scrum en la organización. Esta sección de la herramienta del Modelo de madurez está en la pestaña "D. Prácticas de Scrum" como se muestra en la siguiente imagen.

A diferencia del diagnóstico de agilidad que busca indagar sobre las características, la cultura o la forma en la que se realizan las actividades dentro de la organización, el diagnóstico de la adopción de las prácticas de Scrum busca identificar la existencia o no de aquellos elementos que son sugeridos en las prácticas de Scrum.

A continuación, se presenta la estructura y componentes de esta seccion de la herramienta:

1. Recomendaciones: se mencionan algunos aspectos a tener en cuenta antes y durante el diligenciamiento del diagnóstico.
2. Identificación: es la numeración asignada a la pregunta.
3. Práctica: es la práctica de Scrum que está siendo objeto de evaluación.
4. Actividad clave: es una subcategoría asignada a la descripción que permite realizar un mapeo del componente de Scrum al que pertenece la descripción de la pregunta.
5. Descripción: presenta la situación sobre la que se deberá determinar si la organización cumple o no, es decir si la situación descrita se ajusta a las actividades actuales de la organización.
6. Calificación proyecto A: si la situación descrita se ajusta al contexto de la organización se debe asignar el número 1 (uno) a la celda de la columna cumple, en caso contrario el número 1 se asigna en la columna no cumple.
7. Calificación proyecto B: en el caso que la organización desee realizar la evaluación de la adopción de las prácticas de Scrum en diferentes proyectos, se pueden adicionar, por ejemplo, en la imagen se observa que la evaluación es realizada para dos proyectos: A y B.

Ahora que se conocen los elementos que conforman la evaluación, el siguiente paso es diligenciar la herramienta con los valores que mejor representen la situación de la organización, para ello al igual que se mencionó en el numeral anterior, se deben seleccionar los instrumentos de recolección de información adecuados y posteriormente en la columna de calificación de cada proyecto, se debe desplegar un menú que tiene dos valores (0 y 1) asignado el número 1 a la casilla de la columna "Cumple" en el caso que la descripción se ajuste a la situación de la organización, o en la casilla de la columna "No cumple" si por el contrario la organización carece o no ejecuta los aspectos relacionados en la descripción.

Por ejemplo, como se observa en la siguiente imagen, a la primera descripción se le asigna el valor de "1" en la columna de cumple (valor encerrado en color verde), esto significa que en el proyecto A antes de inciar la ejecución se estructura una visión que considera las necesidades y la calidad esperada por el patrocinador del proyecto. La tercera descripción por el contrario tiene asignado el número 1 a la casilla de la columna "No cumple" (valor encerrado en rojo), lo que significa que el proyecto no cuenta con una matriz de partes interesadas. Es importante que se verifique que por descripción solo se asigne el número 1 a una sola casilla, es decir a la de "Cumple" o a la de "No cumple" pero no a las dos, esto para evitar errores en los resultados.

2.4.4. Resultado del diagnóstico de la adopción de las prácticas de Scrum

Una vez se han calificado todas las descripciones, se procede a consultar los resultados obtenidos por el diagnóstico en la pestaña "Resultados Prácticas".

Lo primero que presenta esta sección de la herramienta de Madurez de Scrum es una tabla con la descripción de los niveles de madurez que ya se explicaron en el numeral anterior, posteriormente, se presenta la primera tabla de resultados, que tiene la siguiente estructura:

1. Nivel: relaciona el nivel de madurez de la adopción de las prácticas de Scrum.
2. Puntaje máximo: es la cantidad de descripciones por práctica, significa que en un estado ideal la organización debería tener la calificación de "Cumple" en cada descripción, lo que representa el puntaje más alto.
3. Calificación obtenida: presenta el número de descripciones que se cumplen dentro de la organización por cada nivel.
4. Porcentaje alcanzado: presenta la relación entre la calificación obtenida y el puntaje máximo.
5. Porcentaje de cumplimiento promedio: es el promedio de los porcentajes alcanzados y representa el nivel de adopción global de las prácticas de Scrum dentro de la organización o dentro del proyecto.
6. Explicación: presenta una breve reseña sobre el porcentaje promedio de cumplimiento de las prácticas de Scrum.

De la información descrita en la tabla, se presentan las siguientes consideraciones:

• Para concluir que una organización o proyecto está en un nivel particular, no es suficiente con cumplir únicamente con las descripciones de ese nivel, sino las descripciones de los niveles que le preceden, por ejemplo, una organización o proyecto está clasificado en un nivel 3 de madurez en la adopción de las prácticas de Scrum únicamente si ha adoptado en un 100% las actividades descritas en los niveles 1, 2 y 3.
• El porcentaje alcanzado para cada nivel de madurez es valioso pues permite conocer el punto de partida de las mejoras, ya que presenta el valor numérico que ayuda a dimensionar la distancia que se tiene de la meta en cada uno de los niveles, por ejemplo, para el caso presentado en la imagen anterior, de los elementos que le permiten a una organización concluir que está haciendo Scrum en un nivel de madurez 1 tiene adoptados solo la mitad, es decir, que debe revisar cuáles son los elementos que conforman la otra mitad y que aún no han sido adoptados.

La segunda tabla de resultados, presenta el grado de adopción de cada nivel asignando a cada uno de estos una ponderación, esto se justifica en el hecho que cada nivel tiene una cantidad de elementos diferente, haciendo más compleja la adopción de aquellos niveles que están conformados por una mayor cantidad de elementos de las prácticas de Scrum, por ejemplo, para cumplir con lo descrito en el nivel 1 solo hace falta adoptar 6 elementos, mientras que para adoptar el nivel 3 se deben adoptar 30 elementos. Los elementos que conforman la tabla son:

1. Nivel: relaciona el nivel de madurez de la adopción de las prácticas de Scrum.
2. Puntaje máximo: es la cantidad de descripciones por práctica, significa que en un estado ideal la organización debería tener la calificación de "Cumple" en cada descripción, lo que representa el puntaje más alto.
3. Calificación obtenida: presenta el número de descripciones que se cumplen dentro de la organización por cada nivel.
4. Porcentaje alcanzado: presenta la relación entre la calificación obtenida y el puntaje máximo.
5. Ponderación: mide el pocentaje de participación que tiene el nivel (puntaje máximo) dentro de la totalidad de los elementos de todos los niveles (74 descripciones), por ejemplo, el nivel 1 presenta 6 elementos dividido en el total de los 74 elementos, lo que en porcentaje arroja el 8.11%.
6. Porcentaje de cumplimiento: este valor representa el grado de adopción del nivel, con respecto al total global de la adopción, su cálculo se da como el producto entre el porcentaje alcanzado del nivel y la ponderación.
7. Porcentaje de cumplimiento global: es la suma de todos los porcentajes de cumplimiento y refleja cuál es el porcentaje de adopción que tiene la organización con respecto a todos los elementos presentes en una organización con un nivel 5 de madurez en la adopción de las prácticas de Scrum.
8. Explicación: presenta una breve reseña sobre el porcentaje de cumplimiento de las prácticas de Scrum alcanzado.

De la información que proporciona esta tabla es importante resaltar que:

• El porcentaje de cumplimiento global permite a la organización determinar qué tan lejos o cerca se encuentra de adoptar Scrum en un nivel 5, es decir de adoptar los 74 elementos descritos en el diagnóstico.

La tercera tabla presenta los resultados desde otra perspectiva: la adopción de las prácticas, la estructura de la información es la siguiente:

1. ID de la práctica: es un número asociado a cada práctica.
2. Práctica: cada una de las prácticas sugeridas por Scrum.
3. Puntaje máximo: son el total de elementos asociados a la práctica.
4. Calificación: es la cantidad de elementos asociados a la práctica que la organización ha adoptado.
5. Porcentaje alcanzado: es el porcentaje de elementos que han sido adoptados por la organización con respecto al total de elementos de la práctica (puntaje máximo).
6. Porcentaje promedio de adopción por práctica: es el porcentaje promedio de adopción que cada una de las prácticas de Scrum en la organización.

Adicional a la tabla, se presentan dos emisores de información:

El primero es un gráfico radial, donde cada punto es una práctica y sobre cada eje se representa el porcentaje de adopción de la práctica en la organización, al unir los puntos se crea la figura de contorno morado que delimita el área de cumplimiento de las prácticas. La circunferencia azul permite tener una referencia para observar a qué distancia se encuentra la adopción de la práctica del estado ideal.

En el segundo gráfico, cada barra representa una práctica, su altura corresponde al porcentaje de adopción que se tiene en la organización de la misma.

Al momento de definir la hoja de ruta para realizar mejoras en la organización que se traduzcan en un aumento del nivel de madurez de la adopción de Scrum en la organización, es importante considerar la perspectiva del grado de madurez actual y el deseado, así como la adopción de los elementos de las prácticas, lo ideal es que cada organización defina según sus necesidades cuál es el nivel de adopción de Scrum que desea alcanzar, y en este sentido hacer que el plan se convierta en un proceso incremental, acompañado con una adecuada gestión del cambio que garantice la sostenibilidad de las adopciones realizadas a través del tiempo.

2.4.5. Resultados generales (Agilidad + prácticas de Scrum)

La última sección de la herramienta presenta una combinación de los resultados alcanzados en el diagnóstico de agilidad y en el diagnóstico de las prácticas de Scrum, es decir que para poder utilizar este emisor de información, es necesario que la organización haya realizado los dos diagnósticos que propone la herramienta. Esta seccion se encuentra en la pestaña "Resultados Generales" de la herramienta.

Lo primero que se observa es una tabla con dos filas, la primera con los valores que representan el estado ideal de una organización, es decir que tenga un nivel 5 de agilidad y el 100% de las prácticas de Scrum adoptadas, la segunda fila presenta los resultados obtenitos por la organización tanto para el diagnóstico de agilidad como el de adopción de las prácticas de Scrum.

Posteriormente, se presenta un gráfica donde el eje x representa los niveles de agilidad y el eje y el porcentaje de adopción de las prácticas de Scrum, de esta manera el gráfico permite ubicar la organización en uno de los cuatro cuadrantes; la ubicación de la organización dentro del gráfico se representa por una estrella de color rojo (en la ilustración se puede observar dentro de una circunferencia de color rojo).

Finalmente, se presentan una explicación para cada uno de los cuadrantes teniendo en cuenta las convenciones de color, así:

• Incipiente: Tanto el nivel de agilidad como el nivel de adopción son bajos dentro de la organización, por lo que se recomienda definir dentro de la hoja de ruta actividades que permitan un crecimiento paralelo tanto de la adopción de la agilidad como de las prácticas de Scrum. Cuando la organización se encuentra en la parte superior de este cuadrante se evidencia que la organización ha manifestado la adopción de Scrum como una necesidad, lo que ayuda con el compromiso en la ejecución del proyecto de adopción.
• Baja agilidad: El trabajo en la adopción de las prácticas se encuentra avanzado, sin embargo, la cultura en la organización aún no se caracteriza por un tener un alto nivel de agilidad. Por anterior se recomienda considerar acciones que permitan adoptar los elementos de las épicas del Backlog dentro de la hoja de ruta de la organización.
• Baja adopción de Scrum: La organización se caracteriza por tener un ambiente donde se evidencia un alto nivel de agilidad, pero aún no se tienen adoptadas en un alto nivel las prácticas de Scrum, se recomienda considerar el modelo core de Scrum para iniciar con la adopción de Scrum, posteriormente se pueden considerar los elementos de Scrum aplicados a proyectos.
• Íntegro: Las organizaciones ubicadas en este cuadrante ya han realizado esfuerzos valiosos para llevar su cultura hacia la agilidad, de igualmanera se evidencia un progreso enorme en la adopción y mantenimiento de Scrum. Aquellas organizaciones que se encuentran en la parte superior derecha del cuadrante deben esforzarse por mantener y mejorar tanto su cultura como la ejecución de sus procesos, mientras que si están en la parte interior del cuadrante significa que aún se deben realizar esfuerzos para adoptar aquellos aspectos faltates, aunque estos esfuerzos no serán tan desafiantes como los requeridos para inciar de cero el proyecto de adopción de Scrum.

3. Retos en la implementación de Scrum

En este capitulo se presentan algunas consideraciones sobre aquellos aspectos que podrían generar fallas durante el ciclo de vida de la implementación de Scrum.

¿Por qué fallan los proyectos de adopción de Scrum?

Adoptar Scrum es un proceso complejo dadas las múltiples interacciones que se dan en el camino para alcanzar el objetivo del producto. A continuación, se recopilan algunas cuestiones planteadas por diversos autores (Joey Cho, 2010) (Akif, 2012) (Hanslo & Mnkandla, 2018) que contemplan aquellos obstáculos que afectan tanto el proceso de adopción de Scrum como el buen sostenimiento del cambio a lo largo del tiempo. De acuerdo a lo propuesto por Joey Cho, los obstáculos pueden ser clasificados en cuatro categorías, así:

A continuación, se describe cada categoría.

Cuestiones relacionadas con el recurso humano

La mayoría de obstáculos que afectan un buen sostenimiento del cambio a lo largo del tiempo, suelen ser de carácter interno y directamente relacionados con aspectos humanos:No basta con tener buenas ideas y contar con tecnología adecuada, pues el factor con más peso son las personas. Algunos de los obstáculos a considerar dentro de esta categoría son:

• Colaboración: en algunos equipos Scrum se puede percibir una falta de colaboración entre los desarrolladores, principalmente cuando la labor de un desarrollador debe ser validada por otro, en estos casos los desarrolladores a cargo de la elaboración del producto tienden a omitir detalles sobre las posibles falencias del diseño o el desarrollo del producto a los responsables de su validación. Otra situación en la que se corre un alto riesgo de tener una baja colaboración es dentro de los equipos remotos, por lo que la selección de las estrategias y herramientas de comunicación son fundamentales para evitar este tipo de incidentes.
• Entrenamiento: el entrenamiento se convierte en problema principalmente cuando se vincula personal nuevo a proyectos de alta complejidad, que terminan requiriendo altos tiempos de entrenamiento para familiarizarse con el sistema, es recomendable buscar el equilibrio entre personal experto y personal nuevo, así como diseñar estrategias de formación que incluyan mentorías por parte de los expertos, esto puede reducir considerablemente el tiempo de aprendizaje de los nuevos desarrolladores en el equipo. Esto aplica tanto para el conocimiento técnico como para el conocimiento del Framework de Scrum.
• Falta de responsabilidad: puede ocurrir que durante el proyecto de adopción se empiece a generar una deuda técnica que se transfiere constantemente al siguiente Sprint sin que se responsabilice a alguien de dichas tareas retrasadas, por lo que es importante evitar que la auto-gestión genere problemas de falta de supervisión que al final se traduzca en demoras o incluso en la suspensión del proyecto de adopción de Scrum.
• Idealizar Scrum: generar expectativas demasiado altas sobre la adopción de Scrum puede generar frustraciones con el paso del tiempo por parte del equipo al no alcanzar todos los resultados y/o beneficios que se plantearon al inicio del proyecto.
• Resitencia al cambio: no gestionar adecuadamente la resistencia al cambio puede causar el fracaso del proyecto de adopción de Scrum.

Cuestiones relacionadas con el proceso

También se presentan obstáculos relacionados con la forma en la que se ejecutan los procesos y las actividades cotidianas de la organización, por ejemplo:

• Uso del marco de trabajo: Scrum plantea ceremonias, artefactos, emisores de información, etc. que pueden considerarse por algunos desarrolladores como insuficientes, de poco valor o de difícil cumplimiento debido a los procesos de la organización, por lo que es fundamental el trabajo colaborativo de todos los miembros del equipo Scrum para encontrar los espacios y canales adecuados para que los parámetros trazados por el marco de trabajo se adopten adecuadamente teniendo en cuenta el contexto de la organización.
• Documentación: dado que Scrum es un marco de trabajo ágil, muy posiblemente se realice una simplificación en la información documentada que suele llevarse dentro de la organización, algunas veces en el afán de simplificarla se omite información relevante, por lo que es importante analizar los cambios que se van a realizar y el impacto que tendrá dicho cambio dentro de la operación de la organización.
• Planeación de los productos: una mala planeación y estimación del producto puede generar problemas muy graves, pues se pueden realizar planeaciones poco realistas que a la final se reflejan en demoras y déficit de recursos.
• Ausencia de prácticas técnicas: en algunos casos se realiza la adopción de Scrum, pero no se consideran mejores prácticas o marcos de trabajo del sector, lo que termina dificultando la ejecución de las actividades misionales de la organización o generando resultados poco efectivos.
• Gestión de riesgos: No se realiza una gestión de riesgos por lo que constantemente se presentan desviaciones que podrían haber sido evitadas.

Cuestiones relacionadas con el ambiente interno o externo

Las condiciones ambientales que permiten la ejecución de las actividades cotidianas y la relación entre las partes interesadas del proyecto, tienen una influencia sobre la facilidad de la adopción de Scrum, por ejemplo:

• Involucramiento de las partes interesadas externas: en algunas ocasiones puede ser difícil involucrar en el proyecto de adopción de Scrum a las partes interesadas externas al equipo Scrum, esto principalmente por el tiempo limitado o falta de disposición, por lo que involucrarlos en las sensibilizaciones sobre los beneficios de la adopción y la selección adecuada de los mecanismos de comunicación ayudará a superar este obstáculo.
• Ambiente de trabajo: en algunas oportunidades la adopción de Scrum se dificulta por las condiciones propias del ambiente de trabajo, por ejemplo, alta presencia de distractores, exceso de ruido, déficit de canales de comunicación, ambientes anti-ergonómicos, etc. estas condiciones complican la concentración y motivación del equipo de adopción, por lo que evaluar y garantizar condiciones ambientales adecuadas es fundamental para la correcta ejecución del proyecto de adopción.

Relacionadas con la información

El bajo flujo de información, el déficit de comunicación asertiva y la nula gestión del conocimiento son obstáculos que pueden dificultar la adopción de Scrum,

• Sistemas de comunicación: como se ha referido en varias oportunidades a lo largo del desarrollo del libro, la comunicación efectiva es fundamental para el éxito del proyecto, razón por la cual omitir el uso de herramientas de comunicación o hacer una mala selección de las mismas puede traer consecuencias graves para el proyecto. Si bien es primordial fomentar la comunicación cara a cara, contar con el apoyo de herramientas tecnológicas ayudará a obtener mejores resultados.
• Sistemas de gestión de información y conocimiento: cuando en la organización no se cuenta con sistemas de gestión de información y conocimiento se dificultan actividades como el entrenamiento, capacitación, intercambio de información, consulta de información para la toma de decisiones, gestión de lecciones aprendidas, etc. por lo que contar con este tipo de sistemas facilitará en gran medida la adopción de Scrum.

Para conocer más a profundidad los retos y cuestiones que dificultan la adopción de Scrum se sugiere la lectura de los siguientes trabajos académicos:

• Akif, R. H. (2012). Issues and Challenges in Scrum Implementation. International Journal of Scientific & Engineering Research.
• Hanslo, R., & Mnkandla, E. (2018). Scrum Adoption Challenges Detection Model: SACDM. Federated Conference on Computer Science and Information Systems (FedCSIS).
• Joey Cho, J. (2010). An Exploratory Study on Issues and Challenges of Agile Software. Utah State University.