Agile Adoption Framework

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

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:

Elementos del ámbito de la organización

Ilustración 1 - Elementos involucrados en una transformación ágil

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.

Ciclo de vida de la adopción de Scrum

Ilustración 2 - Elementos involucrados en una transformación ágil

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.

Componentes típicos de la adopción de Scrum

Ilustración 3 - Modelo core de Scrum

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

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:

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:

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 que deben ser considerados a la hora de adoptar Scrum en la organización son:

Factores de adaptación de Scrum

Ilustración 4 - Factores de adaptación de Scrum
1. Adoptando Scrum

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.

Inicio de la adopción

Ilustración 5 - Elementos involucrados en el inicio de la adopción de Scrum (inicio del proyecto)

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

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

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.

Ilustración 6 - Elementos involucrados en el inicio de la adopción de Scrum.

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:

Trade-off de los elementos de la calidad

Ilustración 7 - Variaciones de los elementos que conforman la calidad del 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:

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.

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:

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:

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.

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.

Componentes del Backlog

Ilustración 8 - Componentes del Backlog

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:

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

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:

Ilustración 9 - Tablero de delegación.
Propiedad intelectual de © Management 3.0. Todos los derechos reservados

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:

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:

Ilustración 10 - Moving Motivators - CHAMPFROGS.
Propiedad intelectual de © Management 3.0. Todos los derechos reservados

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:

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:

Ilustración 11 - Tablero Kanban.

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:

1. Adoptando Scrum

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

Ilustración 12 - Resumen de las épicas/componentes del Backlog.

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.

Ilustración 13 - Ciclo de vida de la adopción de Scrum (Definir y priorizar 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:

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:

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

Ilustración 14 - Gráfica costo-valor de los elementos del Backlog.

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

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

Ejecución de la adopción

Ilustración 15 - Ciclo de vida de la adopción de Scrum (Fase de Ejecución)

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:

Ilustración 16 - Ciclo de Lean Change Management.
Propiedad intelectual de leanchange.org Todos los derechos reservados

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í:

Ilustración 17 - Tablero Kanban con revisión.
1. Adoptando Scrum

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:

Ilustración 18 - Componentes del modelo de madurez 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:

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:

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:

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:

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:

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:

1. Adoptando Scrum

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.

Ilustración 19 - Ciclo de vida de la adopción de Scrum (Gestión del cambio).

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:

Ilustración 20 - Pasos del modelo de Kotter.

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:

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.

1. Adoptando Scrum

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.

Objetivos de la reunión

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

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.

Ilustración 21 - Coordinación de Sprints.

Algunas consideraciones a tener en cuenta son:

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.

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:

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:

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:

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:

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:

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:

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.

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. Evaluación de madurez

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:

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:

Motivación y desarrollo del equipo de trabajo

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

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:

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:

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:

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:

2. Evaluación de madurez

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:

Conformar el equipo Scrum

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

Construir el Product Backlog

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

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:

Definir la arquitectura del producto

Dentro de esta práctica se evalúa:

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:

Desarrollo del Sprint

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

Sprint (Scrum diario)

En esta práctica se evalúan:

Validar los entregables del Sprint

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

Retrospectiva del Sprint

Los elementos contemplados dentro de esta práctica son:

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:

Retrospectiva del proyecto

En esta práctica se evalúa que:

2. Evaluación de madurez

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.

Ilustración 22 - Niveles de madurez de agilidad.

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.

Ilustración 23 - Niveles de madurez de la adopción de las prácticas de Scrum.

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. Evaluación de madurez

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:

Ilustración 24 - Niveles de agilidad.
  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:

Ilustración 25 - Instrumentos de recolección de informació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).

Ilustración 26 - Respuesta a las preguntas del diagnóstico de agilidad.

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.

Ilustración 27- Sección Resultados del diagó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:

Ilustración 28 - Tabla de resultados: Porcentaje de adopción de agilidad por nivel.
  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 segunda tabla, presenta los porcentajes del nivel de madurez alcanzado por cada una de las épicas del Backlog, se compone de:

Ilustración 29 - Tabla de resultados: Nivel de madurez de cada épica del Backlog.
  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:

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.

Ilustración 30 - Sección Diagnóstico de las prácticas de Scrum.

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:

Ilustración 31 - Componentes de la herramienta para el diagnóstico de la adopción de las prácticas de Scrum.
  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.

Ilustración 32 - Ejemplo del diligenciamiento del diagnóstico de la adopción de las prácticas de Scrum.

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

Ilustración 33 - Sección Resultados del diagóstico de adopción de las prácticas de Scrum.

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:

Ilustración 34 - Tabla de resultados: Porcentaje promedio de adopción de las prácticas de Scrum por nivel.
  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:

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:

Ilustración 35 - Tabla de resultados: Porcentaje global de adopción de las prácticas de Scrum.
  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:

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:

Ilustración 36 - Tabla de resultados: Porcentaje de cumplimiento por práctica de Scrum.
  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:

Ilustración 37 - Gráfico Radial.

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.

Ilustración 38 - Gráfico de barras.

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.

Ilustración 39 - Sección Resultados generales del diagnóstico.

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.

Ilustración 40 - Resumen de resultados.

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

Ilustración 41 - Resultados generales (Agilidad + prácticas de Scrum).

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

Ilustración 42 - Convenciones de los cuadrantes.

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.

3. Retos en 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í:

Ilustración 43 - Obstáculos de la adopción de Scrum.

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:

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:

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:

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,

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: