Transparencia en Scrum

Scrum  se basa en el empirismo, que se basa en los tres aspectos más importantes (también conocidos como los  tres pilares  que se muestran en la figura a continuación) y respalda cada implementación del control empírico de procesos: transparencia, inspección y adaptación.

Cuando  los equipos de scrum  encarnan y practican los  valores  de compromiso, coraje, enfoque, apertura y respeto, los pilares de transparencia, inspección y adaptación de Scrum emergen y generan confianza para todos. Los miembros del equipo de Scrum aprenden y exploran estos valores cuando se ocupan de los roles, eventos y artefactos de Scrum.

Garantizar la transparencia — Equipo Scrum

Scrum mejora la transparencia dentro y fuera del equipo. La transparencia es fundamental para el proceso de Scrum porque permite que todos vean y comprendan lo que realmente sucede en cada sprint, lo que lleva a una mayor y mejor comunicación y confianza dentro del equipo.

Los equipos pueden ser transparentes de muchas maneras. Aquí enumero algunas cosas que podemos hacer para lograrlo:

Trabaje más cerca y retroalimente más rápido

Los equipos Scrum deben ser transparentes en la forma en que trabajan: acercar a las partes interesadas, trabajar con ellas a diario, dejar que la retroalimentación fluya en ambas direcciones y compartir el riesgo de tomar una dirección u otra.

Haga que el progreso del trabajo sea más visible

Los equipos pueden hacer visible el progreso: los gráficos de trabajo pendiente y las pizarras son la forma tradicional de mostrar el progreso de los objetivos del sprint. Estas sencillas herramientas pueden mostrar el progreso de cada etapa del plan, desde el sprint hasta la visión, lo que puede reducir de manera efectiva «¿cuándo se puede completar?» Diálogo.

El equipo puede hacer que el progreso sea visible: los gráficos de quemado y una pizarra son los métodos tradicionales para mostrar el progreso con respecto a  los objetivos del sprint . Un informe simple para mostrar el progreso en todos los niveles de planificación, desde el sprint hasta la visión, puede ser increíblemente eficaz para reducir el número de «¿cuándo se hará?» conversaciones

Libre Flujo de Información Actualizada

La información debe viajar en ambas direcciones. Las partes interesadas y aquellos en roles de productos, especialmente aquellos que trabajan directamente con un equipo, también deben ser transparentes. La dirección del producto en forma de hojas de ruta, planes de lanzamiento o  definición de hecho  se puede hacer visible para el equipo para que estén al tanto de los objetivos generales y las expectativas que se comprometieron a cumplir.

Scrum Master puede ayudar

En Scrum, no es el equipo el que trabaja para el  Scrum Master , es el Scrum Master quien se esfuerza por facilitar el trabajo del equipo de desarrollo. Scrum Master debe trabajar con el  propietario del producto , el equipo de desarrollo y otras partes involucradas para comprender si los eventos y los artefactos son completamente transparentes. El Scrum Master debe ayudar a todos a aplicar las prácticas más adecuadas en ausencia de una transparencia total. Un Scrum Master puede detectar una transparencia incompleta al inspeccionar los artefactos, detectar patrones, escuchar atentamente lo que se dice y detectar diferencias entre los resultados esperados y los reales.

Transparencia en Eventos

Sprint  es un contenedor para todos los demás eventos y cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar algo. Estos eventos están diseñados específicamente para permitir una transparencia e inspección críticas. Si no se incluye ninguno de estos eventos, se reduce la transparencia y se pierde la oportunidad de inspeccionar y adaptar.

La transparencia es el primer aspecto significativo en el proceso Scrum que debe ser visible para los responsables del resultado. La transparencia requiere que esos aspectos se definan en sus actividades y artefactos cotidianos para que el equipo pueda compartir una comprensión común de lo que se ve.

Por ejemplo:

Reunión de planificación de Sprint

La  reunión de planificación del Sprint  se lleva a cabo al comienzo del Sprint para comprender y documentar los  elementos del Backlog del Sprint  . Se lleva a cabo para asegurarse de que todos los involucrados sin duda saben lo que se debe hacer de su parte para contribuir al desarrollo de esa iteración incremental particular del

Reunión diaria de Scrum Standup

El  Daily Scrum  se centra en el reflejo del día a día de las contribuciones del equipo al Sprint en particular. Responde a tres cosas:

• ¿Qué he desarrollado durante las últimas 24 horas para cumplir con la meta diaria de Sprint?
• ¿Qué haré hoy para lograr mi próximo objetivo de Sprint?
• ¿Cuáles son los impedimentos en el trabajo de ayer que impiden el logro de mi meta?

Daily Scrum es muy importante en términos de compartir todas estas cosas sin tener miedo a admitir los errores. Si no se comparte, el proyecto se complica, lo que provoca demoras y, finalmente, riesgos de fallas en el proyecto.

Reunión de revisión de sprint

La  reunión de revisión de Sprint  se lleva a cabo al final de un Sprint para reflejar lo que se ha hecho para completarlo como un incremento del producto. El equipo invita a las partes interesadas a obtener sus comentarios sobre el Sprint, que el propietario del producto incorpora a la  cartera  de productos para traer mejoras en los próximos Sprints.

Reunión retrospectiva de Sprint

La  Retrospectiva de Sprint  se lleva a cabo para inspeccionar el último Sprint en orden de su gente, interacciones, procesos y herramientas, y para adoptar medidas de mejora de este Sprint para desarrollar el próximo Sprint. Todo requiere transparencia en los informes y la comunicación.

Transparencia en artefactos

Scrum tiene una serie de  artefactos  que sirven como radiadores de información para todas las etapas de Scrum. La información se hace claramente visible y comprensible para el equipo, por lo que se conocen las tendencias de progreso del proyecto. La disponibilidad y claridad de la información es muy importante para tomar decisiones inteligentes.

Pila de Producto

El  Product Backlog  es una lista ordenada de requisitos priorizados en función de su precedencia e importancia por parte del propietario del producto, así como del equipo. Todas las características, atributos, correcciones y mejoras más conocidas se documentan en el Backlog del producto para que el equipo lo entienda claramente y lo entienda bien.

Pila de Sprint

El  Sprint Backlog  se desarrolla después  de que se haya llevado a cabo la reunión de planificación del Sprint  y se finalice el Product Backlog. Contiene historias de usuarios necesarias para desarrollar un incremento completo del producto. Por lo general, algunos de los elementos del Product Backlog se descomponen en las tareas o historias de usuario acordadas por el equipo para trabajar.

Gráficos de evolución: estado de desarrollo

Use  gráficos de trabajo pendiente  para ser honesto sobre el desempeño del equipo en un Sprint determinado. Un gráfico de trabajo pendiente cuenta la verdadera historia de cómo se está desempeñando el equipo. Los gráficos de quemado muestran la cantidad de esfuerzo restante en el futuro para completar el Sprint.

Tablero de tareas de Scrum

Los  Scrum Boards  también se utilizan para reflejar tres cosas mientras se trabaja en un Sprint:

• ¿Qué hacer?
• ¿Qué está en progreso?
• ¿Qué se hace?

Definición de hecho

La transparencia también está fuertemente relacionada con la Definición de Listo. Definir formalmente el significado de ‘hecho’ reduce la variabilidad y la probabilidad de que se deshaga el trabajo, y medir el progreso sin ambigüedades (‘hecho’ o ‘no hecho’) aumenta la transparencia.

Tener una Definición imperfecta  de Terminado  implica que hay Trabajo Deshecho en su sistema. Este Trabajo Deshecho también provoca una falta de transparencia. Los riesgos están ocultos en él. Por ejemplo, si las pruebas de rendimiento se dejan sin hacer, retrasa el riesgo de un sistema que no funciona hasta que esté cerca del lanzamiento, cuando más duele.

Conclusión

Scrum se basa en la transparencia representada a través de sus eventos y artefactos, pero no se puede lograr si falta transparencia y comunicación en el equipo. Es difícil establecer y mantener una transparencia total si los miembros dudan o tienen miedo de compartir sus errores. De hecho, todos en el equipo deben mostrar comprensión y respeto mutuo. Propietario del producto y  Scrum Master debe motivar y alentar a los equipos a compartir cualquier riesgo o problema que enfrenten en su trabajo. Si bien los equipos no solo deben centrarse en sus logros individuales, también deben esforzarse por lograr los objetivos compartidos del proyecto. Todos estos comentarios e intercambios son importantes para establecer y mantener una transparencia total del flujo de información, lo que permite la mejora continua de la organización y el equipo.