¿Cómo sobrevivir ante el cambio utilizando Scrum?

Sobrevivir a un cambio en transformación digital implica valorar un nuevo método de trabajo, se tiende a ver los casos de éxito y las bondades del mismo.

Pero es más importante, es estudiar y contemplar los errores típicos tras la implantación en otras compañías ya que nos ayudarán a llevar a buen puerto el trabajo evitándonos:

  • sin sabores,
  • retrasos
  • y lo que es peor al no obtener resultados en el tiempo previsto el abandono.

 

Esta idea me surgió, tras preguntar a mis alumnos como te han ido tus experiencias con lo aprendido en nuestro curso de Scrum y cómo has evolucionado tras lo aprendido. Mi sorpresa es recibir esta respuesta en una de las valoraciones.

Creo que sería interesante recopilar experiencias sobre errores comunes…. es típico encontrar presentaciones de buenas prácticas, a la gente le gusta contar lo que le ha salido bien, pero los errores ya cometidos creo que son interesantes, así ya intento no equivocarme en lo mismo. Esto sería referente a la implantación de Scrum y de cualquier otra metodología, claro.

Me pareció absolutamente genial la propuesta y he realizado un resumen de los errores o impedimentos que se producen bajo mi experiencia y considerando los más importantes bajo mi punto de vista.

Sobredimensionar el trabajo a los equipos

Quizá, el más común es el sobredimensionar el trabajo a los equipos o el miedo de no tener tareas en el sprint y acabar antes de tiempo.

Es necesario recordar que Scrum es un framework o conjunto de buenas prácticas, tiene unas reglas fijas, pero me deja libertad para modificarlas sin perder la esencia de la metodología, el primer principio del manifiesto ágil nos dice:

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
Reflexionando sobre el tema y aplicando siempre lo que da resultado, la experiencia y el sentido común me indica.

Estamos hablando de Scrum. Esto es, el propietario de producto comparte y está implicado con el equipo (es una relación de colaboración más que acuerdo contractual).

El sprint tiene un seguimiento diario. En la reunión diaria se va viendo el avance del sprint de forma que el que al final no hayan terminado todo lo comprometido no es algo que se hayan encontrado de golpe al final, lo estaban viendo venir.

Cuando el equipo (propietario de producto incluido) ven que el sprint estaba subestimado, pueden ir tomando opciones: alargar el sprint, o mantener la fecha pero acortar funcionalidad. No caigas en el dogmatismo-talibanismo de que no se puede

Esta es una solución reactiva es buena y nos da un primer acercamiento de la solución que por cierto no es mala, pero es una solución desde el punto de vista técnico.

Pero podemos tener una solución mejor, esto una solución proactiva con esta propuesta probablemente evitaremos que ocurra, además mentalizaremos al equipo junto con la organización en el trabajo, y lo más importante damos las pautas para el cambio en la mentalidad no sólo del equipo sino en la organización.

 

Mejora contínua, esa gran olvidada

Esta propuesta aunque ya me rondaba por mi cabeza y la estaba utilizando pero no acababa de aterrizarla me abrió definitivamente los ojos mi buen amigo Alex Mendisky, básicamente se introduce el concepto de holgura, también conocida como Slack Time, Alex lo deja todo muy claro en su artículo ¿Hay alguna dinámica que muestre la importancia de la holgura o aire en los sprints?

Básicamente, un equipo de alto rendimiento debe obtener un ritmo de entrega sostenible e ir mejorando continuamente aportando valor al proyecto, siendo además uno de los principios de Scrum y de todas las metodologías ágiles, muchas veces olvidado.

La técnica Slack Time u holgura, trata de no cargar al equipo con un porcentaje superior al 80% de su carga, este resultado sólo unos pocos equipos lo consiguen los denominados equipos de alto rendimiento, pero esto puede llegar a ser una trampa si se toma ese colchón en las valoraciones del trabajo alargando las tareas como dice el principio de Parkinson

Uno de los pilares de Scrum es la mejora continua, y para que se produzca esta es necesario espacios de tiempo que nos permitan reflexionar y hacer aquellas cosas que nunca hacemos por falta de tiempo porque parecen poco importantes, pero resulta que mejoran sensiblemente nuestra forma de trabajar: siempre suele haber actualizaciones pendientes, herramientas que probar, mejoras que queremos hacer pero no encontramos el tiempo, ideas y experimentos que queremos realizar, artículos que leer…

Como resumen podemos decir que Scrum, Kanban, Agilildad y Lean buscan imprimir flujo de forma sostenible a la construcción de cosas.

El flujo viene a ser el ritmo con el que progresan las tareas o el trabajo. El flujo recorre la cadena de valor y puede estar afectado por impedimentos como los cuellos de botella, las restricciones y las políticas empresariales.

 

La cadencia, que viene a ser marcar un ritmo de tiempo fijo a nuestras tareas, hace que acometamos estas de principio a fin maximizando el ratio de entrega y calidad, como lo hacemos con los sprints de Scrum. La cadencia nos permite poner flujo a tareas que tengan alta variabilidad, como lo son las tareas en el desarrollo TI.

Para hacer posible la cadencia necesitamos pequeñas holguras o aire con cada golpe de ritmo, entre cada sprint, no podemos concebir un solo de batería sin silencios, sería un ruido constante y ensordecedor carente de estructura.



Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies