La misma naturaleza del enfoque Scrum crea una cultura de autodirección, autogestión y aseguramiento de la calidad en los equipos de trabajo.

En este sentido, los Scrum Teams rompen el paradigma de ser equipos de trabajo encabezados por un administrador de proyectos, quien es el que dicta la forma en la que se debe organizar el trabajo y al que se le deben de rendir cuentas precisas. Por el contrario, en este enfoque los equipos se vuelven autodirigidos y autogestionados, porque reconocen su responsabilidad individual y colectiva sobre los resultados que generan, las decisiones que se toman en consenso, así como las asignaciones de trabajo que fijan para sí mismos con base en sus competencias y experiencias previas.

Adicionalmente, la cultura de trabajo Scrum también se enfoca en la entrega de productos con calidad, desde la planeación del sprint hasta la revisión de los resultados.

En este tema verás las características de los equipos de Scrum, las cuales permiten que su organización sea flexible y se adapte a situaciones diversas, afrontando los retos de una manera creativa e innovadora. Lo anterior les permite responder con rapidez a las exigencias del mercado y entregar productos de alta calidad.

Equipos autogestionados

Los equipos Scrum están integrados por miembros con diferentes capacidades y habilidades. Ninguno es mejor que otro. Todos se complementan en un ambiente de simbiosis organizacional, que les permite trabajar en colaboración para crear productos de valor para las compañías e industrias contemporáneas. Precisamente, el enfoque ligero de Scrum les permite organizarse, lo que minimiza el control excesivo y da la libertad suficiente para que puedan innovar y expresar toda su creatividad. Aspectos favorables que son aprovechados en cada sprint.

Según Francia (2021), los equipos Scrum, además de ser autoorganizados, son autogestionados, lo que implica mayor compromiso a la hora de tomar decisiones, en comparación con otros enfoques de gestión de proyectos.

En el caso de los miembros de un Scrum Team, saben que deben involucrarse en las decisiones que afectan el resultado y los objetivos que persigue cada sprint, por lo que no distinguen límites cuando se trata de aportar opiniones y ayudar a sus compañeros a lograr el éxito colectivo, sin importar el rol que tengan.

Como podrás advertir, en el enfoque Scrum se crea una dinámica de trabajo en la que no existe una jerarquía autocrática, es decir, no existe la figura de un jefe que dicte cómo deben trabajar, qué tareas deben realizar o qué productos deben generar. Son los mismos miembros los que deciden cómo gestionar su propio trabajo, mientras que ayudan a otros a terminar sus actividades, mantienen un proceso de mejora continua, reorientan sus propios esfuerzos y establecen vías de comunicación directa con los interesados del proyecto, tal y como se aprecia en el siguiente esquema:

Para lograr esta autogestión, Scrum establece diversos límites de intervención por parte de la persona que se desempeñe como Product Owner. Aquí cabe aclarar que este rol no se asemeja a la figura tradicional del administrador del proyecto, ya que en el enfoque Scrum no puede intervenir en los Daily Scrum para pedir avances del proyecto ni decide cómo se debe desarrollar el producto.

De acuerdo con Vargas (s.f.), los equipos autogestionados son exitosos y son considerados equipos de alto rendimiento, puesto que saben gestionar situaciones complejas e imprevisibles, son capaces de decidir sus procesos, establecen sus propios objetivos, aprenden de sus errores y pueden cambiar el rumbo si consideran que no les está ayudando a lograr la meta previamente acordada.

Para ubicar mejor las características de este tipo de equipos, revisa con detenimiento la siguiente tabla:

Integración de equipos distribuidos

Hasta ahora se ha centrado la atención en el enfoque Scrum, desde la perspectiva de un equipo de trabajo local cuyos integrantes comparten la misma ubicación, sin embargo, en muchos proyectos las personas se encuentran en ubicaciones geográficas distantes.

La integración de un mayor número de equipos puede generarse duplicando la cantidad de equipos que existen en una misma ubicación, lo que implica que el enfoque Scrum debe ser enseñado, guiado y retroalimentado por un Scrum Master con experiencia.

En algunos casos conviene duplicar los equipos conforme van terminando algunos sprints. En la siguiente imagen podrás observar el incremento gradual de equipos conforme van concluyendo los sprints de un proyecto.

Entre los tipos de equipos distribuidos también encontrarás aquellos que se encuentran ubicados en diferentes localidades, pero que forman parte del mismo Scrum Team. Para ello, es necesario mantener una comunicación directa apoyándose en las tecnologías de la información.

Tal como refiere el International Scrum Institute (2019), las organizaciones suelen tener estos equipos por alguna de las siguientes razones:

Herramientas de comunicación

Como podrás imaginar, los equipos distribuidos enfrentan retos relacionados con la comunicación, por lo que deben contar con herramientas que les permitan evitar errores de interpretación de la información. La organización debe proveerles una plataforma de videoconferencias con herramientas para compartir pantalla, sobre todo en los eventos Scrum: Product Backlog, Scrum Planning, sprint Reviews y sprint Retrospectives.

Otra herramienta que debe estar presente son los repositorios comunes para almacenar información en la nube, por ejemplo, SharePoint, GitHub, Google Drive, Dropbox, etc. Son herramientas que te permitirán compartir y acceder a la información más actualizada, además de que es posible colaborar en el mismo documento en tiempo real.

Aseguramiento de la calidad

La calidad hace referencia al nivel de cumplimiento de las expectativas del cliente con los resultados obtenidos. En Scrum se busca que el equipo que participa en el proyecto enfoque sus esfuerzos hacia la generación de valor para la organización en todos sus entregables, lo que implica que debe hacer un gran esfuerzo por construir un software libre de errores, que al mismo tiempo exceda las expectativas del cliente. En síntesis, la calidad se planea, se gestiona y se controla.

Planeación de la calidad

Desde que el Product Owner va colocando los elementos del Product Backlog, debe asegurarse de que se incluyan criterios de aceptación bajo los cuales se evaluará el cumplimiento o no cumplimiento de las expectativas del cliente. Cuando se planea la calidad, se espera que se reduzca la deuda técnica del producto, es decir, cuando se produce algún entregable deficiente por los developers que se ven presionados por el tiempo e intentan llegar a resultados lo antes posible. Lo anterior genera retrabajo, mayores costos y una disminución en la confianza del cliente. Los criterios de aceptación determinan la definición de terminado (DoD), lo que obliga al equipo a entregar productos adecuadamente.

Gestión de la calidad

El Scrum Team debe conocer los criterios de aceptación esperados, que tendrán que ser claros, precisos y libres de ambigüedades. Por ejemplo, si declara que al final del proyecto se espera obtener una interfaz gráfica amigable, dicho término podría conducir a criterios subjetivos. En cambio, si se declara que se espera contar con una interfaz que permita la navegación en solo tres pasos sencillos, es mucho más simple de evaluar y permite declarar si el equipo cumplió o no con lo estipulado.

Es responsabilidad del Product Owner vigilar que cada incremento cumpla con los criterios de aceptación del cliente. De no cumplirse, se agregarían al Backlog para que sean considerados en el siguiente sprint Planning.

Al presentar el resultado de un sprint, tanto el Product Owner como los interesados del proyecto pueden verificar y validar que el producto o funcionalidad ofrecida cumpla con los criterios para aceptarlo, de lo contrario, se aprovecharía el sprint Retrospective para corregirlo en la siguiente iteración.

La calidad no es negociable

Un proyecto de software siempre deberá situar a la calidad como un factor que no puede variar, es decir, el resultado siempre deberá cumplir lo esperado o incluso excederlo.

¡Aquí hasta los detalles más pequeños pueden hacer una gran diferencia! Y para muestra, conviene revisar con atención el siguiente hecho histórico:

Este es un ejemplo que ilustra hasta qué grado puede afectar negativamente un error en la claridad de los criterios de aceptación. Como pudiste observar, el diseño del módulo de aproximación orbital debió especificar que la unidad de medida en la calibración tenía que corresponder al sistema inglés en lugar del sistema métrico.

Control de la calidad

Las funcionalidades entregadas en cada sprint deben pasar por pruebas unitarias, de integración y de usuario las veces que sean necesarias, esto para asegurarse de que el entregable no tiene Bugs o errores que puedan llegar a afectar el funcionamiento o el resultado esperado. Osbourn (2020) precisa que los errores son inevitables y que gran parte del proceso de desarrollo consiste en experimentar diferentes tipos de errores. Algunos de ellos son los siguientes:

• 

  Son errores que aparecen cuando el programador omite o cambia una sentencia o una línea de código. Por lo general, este tipo de errores hacen que el programa no se compile de manera adecuada.

• 

  Las operaciones deben arrojar resultados congruentes y sin errores. Cualquier cálculo debe pasar por varias pruebas basadas en diferentes escenarios y estas deben arrojar resultados consistentes.

• 

  Se relacionan con la presentación de los datos al usuario. Estos, a su vez, se dividen en:

• Errores de comunicación: cuando los datos a ingresar son confusos o tienen acrónimos, el usuario debe contar con un mecanismo para reconocer qué datos se esperan, ya sea que se utilice un tooltip, o bien, una sección de ayuda.
• Errores gramaticales o de redacción: la interfaz debe mantenerse sin errores ortográficos y conservar una adecuada redacción, pues esto mejora la comunicación de la información.
• Errores de navegación o secuencia: la navegación entre ventanas debe ser clara y debe permitir que el usuario reconozca dónde se encuentra en todo momento, por lo que es importante incluir breadcumbs o rutas de navegación. De igual manera, la secuencia de la información debe apegarse al estándar de lectura: de arriba abajo, de izquierda a derecha.
• Errores de funcionalidad: son errores relacionados con el funcionamiento coherente de la interfaz y los resultados esperados. Por ejemplo, si encuentras un botón con el título "Cancelar", lo que se espera es que no grabe la información ingresada y cierre el cuadro de diálogo
• Manejo de errores: en cada paso el usuario debe entender cuál es el error cometido. La interfaz debe ayudar al usuario con mensajes claros que le permitan recuperar el control de la aplicación.



• 

  El programa debe administrar de manera adecuada los recursos disponibles, tanto de almacenamiento como de procesamiento. Este tipo de errores son difíciles de detectar, por lo que es recomendable vigilar el consumo de los recursos al momento de probar el software.

Conviene recordar que el proceso de testing en Scrum es una actividad que se realiza de manera constante en cada sprint y no al final, como lo hacen los equipos que parten del enfoque de desarrollo de Cascada.

La cultura de trabajo del enfoque Scrum permite que las personas que forman parte del Scrum Team (Product Owner, Scrum Master y developers) se conviertan en un equipo autogestionado con altos estándares de productividad, que, además, generan entregables de alto valor para las organizaciones. La misma filosofía Scrum los impulsa a tomar decisiones consensuadas que se enfocan a la estimación del esfuerzo, la autoasignación del trabajo, la colaboración y la gestión de la calidad.

Evidentemente, los beneficios de usar el marco de trabajo Scrum no se obtienen de la noche a la mañana, se requiere del compromiso de los tres niveles de la organización: de la alta dirección, el Scrum Master y los mismos integrantes de los Scrum Teams.

En especial, de la alta dirección se espera que les brinde empoderamiento, autonomía y confianza; del Scrum Master se necesita que asuma un liderazgo servicial, dedicándoles tiempo, trabajando con ellos para mantener el orden, supervisando que se mantengan vigentes los valores Scrum (compromiso, coraje, enfoque, apertura y respeto) y siempre partiendo de los pilares del enfoque (transparencia, inspección y adaptación). Por último, se espera que los developers den muestra de tener una mente abierta, así como una actitud de motivación y compromiso.

Asegúrate de:

• Reconocer las características de autogestión de los equipos de Scrum para garantizar sus resultados.
• Conocer cómo trabajar con equipos distribuidos para aprovechar las competencias de sus miembros.
• Aprovechar la cultura Scrum sobre la gestión de la calidad para obtener resultados que excedan las expectativas de los clientes.

Los siguientes enlaces son externos a la Universidad Tecmilenio, al acceder a ellos considera que debes apegarte a sus términos y condiciones.

Videos

Para conocer más acerca de la Cultura Scrum, te sugerimos revisar lo siguiente:

• Agilemania. (2022, 1 de agosto). Quality Management In Agile| What Is Quality Management| Everything you need to know| Agilemania [Archivo video]. Recuperado de https://www.youtube.com/watch?v=4G8jlvHtA0U
• Dayana Cabeza. (2019, 24 de septiembre). Equipos Autogestionados [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=1V9J81WwP4U
• Planisware. (2020, 14 de mayo). What is a Distributed Agile team? [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=5mfo9wOetzA

Lecturas

Para conocer más acerca de la Cultura Scrum, te sugerimos revisar lo siguiente:

• Gantayat, S. (2022). Everything You Need to Know About Quality Management in Agile. Recuperado de https://agilemania.com/quality-management-in-agile/
• Harris, Ch. (s.f.). Distributed scrum: how to manage scrum remote teams. Recuperado de https://www.atlassian.com/agile/scrum/distributed-scrum

• Francia, J. (2021). Scrum define límites para la Autogestión. Recuperado de https://www.scrum.org/resources/blog/scrum-define-limites-para-la-autogestion
• International Scrum Institute. (2019). The scrum framework (3ª ed.). Suiza: International Scrum Institute.
• NASA. (1998). 1998 Mars Missions. Recuperado de https://mars.nasa.gov/internal_resources/818/
• Osbourn, T. (2020). The 7 Most Common Types of Errors in Programming and How to Avoid Them. Recuperado de https://textexpander.com/blog/the-7-most-common-types-of-errors-in-programming-and-how-to-avoid-them
• Vargas, V. (s.f.). ¿Cómo dirigir equipos autogestionados? Recuperado de https://emocionalscrum.es/dirigir-equipos-autogestionados/