August 14, 2017

¿Estamos usando Scrum?

Antes de iniciar la lectura del siguiente artículo sugiero la lectura de la guía de Scrum en http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf

En muchas ocasiones durante conferencias, talleres, conversaciones y consultoría en empresas he podido observar muchas interrogantes acerca del uso de Scrum.

Algunas personas deciden no hacer un Daily Scrum diario o lo hacen en más de 15 minutos. Me decían: “Porqué debo seguir lo que dice la guía de Scrum”, ellos piensan que pueden cambiar Scrum y seguir usando Scrum. Es decir, muchas personas empiezan a crear su propia versión de Scrum.

Scrum es un marco de trabajo que se basa en un modelo de proceso empírico y que se sustenta en los valores de Scrum así como los valores, principios y prácticas ágiles. Cada parte de Scrum tiene un objetivo y propósito específico que ayuda a adoptar la agilidad. Scrum es un camino hacia la agilidad. Scrum no es metodología, Scrum es una herramienta para adoptar la agilidad.

Una de los argumentos más frecuentes en el uso de Scrum es el siguiente: "Pero eso no lo dice la guía de Scrum". Efectivamente la guía de Scrum creada por Ken Schwaber y Jeff Sutherland contiene las reglas y principios del juego, no contiene la estrategia, cada equipo decide como jugarlo pero siempre buscando lograr un objetivo. Tomemos un ejemplo, la guía no dice que criterios de Done usar, pero si usamos el manifiesto ágil sabemos que el software funcionando es más importante que la documentación y que el software funcionando es la medida principal de progreso. Por ello los criterios de terminado deberían incluir todos los aspectos necesarios para lograr software funcionando en cada Sprint sin ningún trabajo pendiente. Otro principio ágil es "La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad". Esto nos guía a mejorar la calidad en cada Sprint y dado que los criterios de terminado son la base de calidad en Scrum entonces estos criterios deberían idealmente extenderse en cada Sprint Retrospective. Scrum se basa en la agilidad, para entender Scrum hay que entender la agilidad. Un equipo que tiene como criterios de terminado:

  1. Software desplegado en el ambiente de UAT
  2. Manual de instalación y de usuario aprobado por los usuarios.
  3. Que toda la funcionalidad del producto haya sido probado sin errores.

No está cubriendo todos los aspectos necesarios para lograr la excelencia técnica. Si bien es cierto puede iniciar con esos criterios es labor del Scrum Master motivarlos y retarlos para buscar nuevas formas para mejorar la calidad técnica del producto. Algunos criterios como:

  1. Refactoring completado
  2. Despliegue continuo implementado
  3. Configuración de la aplicación automatizada
  4. Integración continua
  5. Pruebas de Regresión completadas

Serían necesarios para mejorar la excelencia técnica. Diferentes equipos pueden encontrar formas diferentes de lograrlo, no hay una receta si hay una guía. La idea no es usar algunos criterios de Done específicos sino buscar la mejora en cada Sprint y en base a esto proponer nuevas y creativas formas de lograrlo. Los criterios de terminado recogen estas mejoras de calidad para crear transparencia en el equipo y ayudarlos a planificar diariamente además de fomentar el compromiso con la calidad.

En mi trabajo como trainer de Scrum.org al principio tenía las mismas dudas, usaba un Scrum mecánico, creía que estaba haciendo un buen trabajo con Scrum, mi idea era que si lograba usar todos los eventos de Scrum podría lograr un buen uso del marco de trabajo. A medida que he venido trabajando con otros trainers de Scrum.org, y recibiendo coaching pude darme cuenta que la verdadera naturaleza de Scrum no está en hacer todo lo que dice la guía de Scrum sino en cómo se hace, también he podido apreciar lo simple de Scrum y que no es necesario cambiarlo sino adquirir la disciplina para usarlo. Debo reconocer que al principio me sentía muy animado a cambiar partes de Scrum y en mi idea de mejorarlo crear mi propia versión de Scrum. Probablemente muchas personas tengan las mismas dudas y busquen respuestas. En este momento luego de varios años puedo tener un mejor entendimiento de Scrum. La esencia de Scrum no está en que hacer sino en como hacerlo.

¿Se puede modificar Scrum? ¿Por qué la guía de Scrum no dice paso a paso lo que hay que hacer? ¿Puedo crear mi propia versión de Scrum? ¿Si hago todo lo que dice la guía de Scrum estoy usando Scrum correctamente? ¿Puedo crear nuevos roles además del Product Owner y del Scrum Master?

Ken Schwaber funda Scrum.org con la idea de evitar el Scrum flácido, esta denominación trata de reflejar un Scrum que se basa mucho más en la parte mecánica que en la parte ágil, también refleja el uso particular o modificado de Scrum que no sigue el enfoque incremental. Scrum es un marco iterativo e incremental, en cada Sprint se busca producir un incremento de producto completamente usable y potencialmente desplegado. Un equipo que decide dejar de lado aspectos de calidad por la presión de las fechas y un Product Owner que decide “bajar la calidad” para lograr los resultados está dejando de lado los valores de Scrum, el compromiso es el compromiso con la calidad, con la transparencia, con los valores ágiles. El trabajo pendiente que se va dejando puede resultar siendo perjudicial en Sprints posteriores y podría llegar afectar el trabajo del equipo, esto por lo tanto crearía una falta de transparencia afectando el trabajo en equipo y podría provocar una falsa percepción de progreso. De cara a los usuarios finales se cumple con las fechas y de cara al equipo se dejan cosas “pendientes” que se van a realizar en Sprints posteriores. Esto es parte de la cultura no ágil.

Cuándo se crea un documento que detalla completamente lo que el equipo debe hacer en Scrum, se convierte a Scrum en una metodología y por lo tanto deja de ser Scrum, deja de ser ágil. La guía de Scrum es corta simple, porque se busca promover la auto organización, el empirismo el trabajo en equipo, usar los valores de Scrum para crear el ambiente el equipo pueda lograr los mejores resultados posibles. Scrum es como el ajedrez, las reglas son simples, aprender a dominar el juego y ser un maestro puede llevar bastante tiempo. Si alguien quiere cambiar las reglas de juego porque le parece que esto mejoraría el juego lo puede hacer, pero en ese momento ese juego ya no se llamaría ajedrez y más aún todos aquellos que jugamos ajedrez no podríamos jugar con aquellos que crearon su propia versión del ajedrez porque no lo entenderíamos.

Cuando Ken Schwaber crea Scrum.org intenta mantener la consistencia y fundamentos del marco ágil en la comunidad y entre los trainers, para ello todos los trainers debíamos reunirnos con Ken cada año en una reunión que se llama “Face 2 Face”, en esta reunión los trainers junto con uno de los creadores de Scrum discutimos la evolución de Scrum y las mejoras que podrían ser incorporadas a partir del aporte de todos los trainers. Cada trainer de Scrum.org tiene una visión que proviene del mismo co- creador de Scrum Ken Schwaber.

¿Porque hacer un Daily Scrum todos los días? Scrum tiene tres pilares, Inspección, adaptación y transparencia. Estos pilares sirven para gestionar un proceso empírico, diariamente el equipo inspecciona el trabajo terminado y no termina y adapta el plan de trabajo como equipo y crea transparencia a partir de la auto organización y colaboración como equipo. El dejar de lado esta reunión diaria se corre el riesgo de introducir elementos de control dentro de la ejecución de Scrum y con ello convertir el marco ágil en una metodología que usa un modelo de control para gestionar el proceso en lugar de promover el empirismo. Cada reunión de Scrum sirve para la transparencia, inspección, y adaptación continua, dejar de hacer alguna reunión iría en contra de los pilares de Scrum y nuevamente en contra del empirismo.

Las reuniones de Scrum tienen un “timebox” porque buscan que el equipo se enfoque y concentre en un objetivo a la vez y se promueva la transparencia al final de cada reunión. El “Daily” Scrum es corto, solo 15 minutos porque tiene como objetivo que el equipo se centre en identificar los impedimentos rápidamente y luego de esta reunión pasar a resolverlos rápidamente. Es decir, alargar un Daily Scrum más allá de su caja de tiempo podría generar una clara falta de enfoque y más peligroso aún podría evitar que el equipo se centre en resolver los impedimentos inmediatamente. Una forma de afrontar esta reunión diaria es hacerla en 15 minutos y luego pasar rápidamente a otra reunión donde se busque solucionar los impedimentos si se requiere y con las personas que se requieran, no necesariamente con todo el equipo.

Si se cambia alguna parte de Scrum ya no es Scrum. Es totalmente válido aceptar que las personas puedan escoger cambiar partes de Scrum, pero en ese momento deja de ser Scrum. El objetivo no es usar Scrum como lo indica un manual sino entender la agilidad para usar Scrum.

Probablemente lo que exista es una interpretación individual de Scrum para adaptarla a su propia cultura. Estas interpretaciones podrían en algunos casos basarse en el desconocimiento de parte del marco de trabajo o en la creencia de que se obtendrán mejoras. Por ejemplo, el “Daily Scrum” no es “Daily Stand Up”, en esta reunión no hay una regla en la forma, pero si bases sobre cómo hacerlo, en el Daily Scrum se propone lograr una comunicación osmótica dentro del equipo, ya sea que estén parados, sentados en el piso o echados. Otro ejemplo es cuando algunas empresas sostienen que Scrum no funciona, que Scrum no se adapta a su realidad y que sería mejor tener un modelo prescriptivo como una metodología. Scrum es una herramienta que depende de quien la usa y como la usa, si Scrum no funciona probablemente el problema no sea Scrum sino la cultura donde se desarrolla Scrum. Scrum no transforma a las personas, las personas deciden transformarse y usar Scrum.

Otra pregunta que recibo es porque Scrum es tan restrictivo. Porque Scrum impide hacer otras reuniones. En realidad, Scrum no prohíbe ni promueve otras reuniones, lo que se sugiere usar los tres pilares continuamente y con ello tener una herramienta para reducir las reuniones y el control. Por ejemplo, un Jefe de Proyecto que solicita información constantemente al equipo y para ello planifica varias reuniones para obtener esa información debería usar Scrum para mediante los tres pilares encontrar la forma de trabajar con el equipo.

Otro escenario común que he observado son empresas que dicen que han creado su "metodología Scrum" para trasladarla a los equipos de desarrollo para que inmediatamente usen Scrum y hagan las cosas más rápido. Cuesta tiempo entender que en una cultura de control es difícil que germine Scrum. En una cultura donde se busca la metodología ágil sin un cambio cultural no habrá cambios. La tolerancia a las discrepancias y a los errores es uno de los procesos de transformación más complicados de lograr. Me ha costado entenderlo, tengo la suposición que también a otras personas les cuesta entenderlo.

Finalmente mi intención no es afirmar que un modelo de Scrum es mejor que otros modelos ágiles, tampoco afirmar que si no se usa Scrum las personas están equivocadas, eso seria falta de tolerancia, mucho menos que una organización posee la verdad absoluta. El objetivo de este artículo es tratar de aclarar que es Scrum desde el punto de vista de uno de los creadores de Scrum y como usarlo. Mi objetivo es ayudar a las personas a entender Scrum y facilitar su uso. Es ayudar a las personas a buscar la agilidad como la base para usar Scrum. También evitar que las personas pierdan tiempo tratando de modificar Scrum y en lugar de eso iniciar la transformación ágil para usarlo.

Otro aspecto importante es que Scrum es abierto y flexible. Scrum no tiene un dueño, tiene autores, no se paga una licencia por usarlo, Scrum es gratuito, justamente estos aspectos lo han hecho tan popular y ampliamente usado.

Joel Francia H. es Trainer de Scrum.org. Puedes escribir a Joel en el correo jfrancia@3devnet.com

Joel ha participado en la traducción de la guía de Scrum al español http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Spanish.pdf

Joel Francia es Trainer de Scrum.org en el Perú y Enterprise Agile Coach.

https://www.facebook.com/joe.familia1