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

A continuación, les dejo una lista que puede ser usada inicialmente para validar si se está usando Scrum. La lista no es prescriptiva en el sentido que no puede medir la cultura ágil, pero es un buen punto de partida para resolver las dudas más frecuentes.

Fundamentos de Scrum

  1. ¿Existe un equipo de Scrum con un Product Owner y un Equipo de Desarrollo?
  2. ¿Existe un equipo de Scrum con un Equipo de Desarrollo y un Scrum Master?
  3. ¿Existe un Product Backlog priorizado?
  4. ¿Existe un Sprint Backlog que muestra el trabajo restante?
  5. ¿Los Sprints son de un mes o menos?
  6. ¿Se define un Sprint Backlog en el Sprint Planning?
  7. ¿Se realiza un plan diario en el Daily Scrum?
  8. ¿Se produce un incremento de Producto funcional y usable en cada Sprint?
  9. ¿Los “Stakeholders” inspeccionan el Incremento?
  10. ¿Se realiza un Sprint Retrospective al final de cada Sprint?

Definición de Terminado (DoD Definition of Done)

  1. ¿Existe una definición de Done?
  2. ¿La DoD ha sido acordada con la organización de desarrollo?
  3. ¿La DoD ha sido acordada con el Product Owner?
  4. ¿La DoD cubre aspectos para todas las actividades que permiten producir un incremento usable?
  5. ¿Es DoD visible y disponible por el equipo?
  6. ¿La DoD está siendo usada?
  7. ¿La DoD ha sido revisada y actualizada durante el Sprint Retrospective?
  8. ¿Los criterios de Done incluyen los estándares de la organización?
  9. ¿Los criterios de Done incluyen los estándares de ingeniería?
  10. ¿Los criterios de Done incluyen elementos requeridos por la organización?

Sprint Retrospective

  1. ¿Hay una Retrospectiva en cada Sprint?
  2. ¿Está presente el equipo de Scrum completo?
  3. ¿Facilita el Scrum Master la reunión?
  4. ¿Se identifican áreas tangibles de mejoras?
  5. ¿Están presentes los usuarios involucrados y que no pertenecen al equipo de Scrum?
  6. ¿La reunión tiene un tiempo máximo definido?
  7. ¿Se tocan aspectos relacionados al proceso y de herramientas usadas y necesarias?
  8. ¿Se tocan aspectos realizados al comportamiento del equipo y la auto organización?
  9. ¿Se refinan los criterios de Done?
  10. ¿Se integran las acciones de mejora definidas como parte del plan del Nuevo Sprint?

Sprint Review (Retro alimentación de los “stakeholder”)

  1. ¿Hay un Sprint Review en cada Sprint?
  2. ¿Se encuentra presente el equipo de Scrum completo?
  3. ¿Se encuentran presente los involucrados requeridos?
  4. ¿Es una sesión de demostración de producto usable (sin presentaciones)?
  5. ¿Los criterios de “Done” están claramente identificados?
  6. ¿Se produce un Product Backlog re priorizado al final del Sprint Review?
  7. ¿El PO conoce el estado del producto en base a los criterios de Done?
  8. ¿El Sprint Review se realiza con el producto que fue usado y aprobado por los usuarios?
  9. ¿Se mencionan los problemas para lograr el incremento y como se afrontaron?
  10. ¿La reunión tiene un tiempo máximo definido?

Equipos auto organizados de Scrum (Cross-functional Team)

  1. ¿Tiene el equipo de Scrum todas las competencias necesarias para construir el producto?
  2. ¿Las estimaciones son creadas por el equipo de Desarrollo de Scrum?
  3. ¿Se encuentra todo el equipo disponible según se requiera y disciplinados en el marco Scrum?
  4. ¿Tiene el equipo que inter cambiar de un Proyecto a otro (continuidad del equipo)?
  5. ¿Hay tiempos muertos en el equipo debido a la dependencia de especialistas?
  6. ¿Todos los miembros del equipo actúan conforme a los criterios de “Done”?
  7. ¿Los miembros del equipo realizan programación en pares?
  8. ¿Es el equipo auto organizado?
  9. ¿Cada miembro del equipo toma una responsabilidad para lograr el resultado del Proyecto y los entregables del Sprint?
  10. ¿Los miembros del equipo ayudan a otros miembros de otros equipos o áreas de la empresa si es necesario?
  11. ¿Los miembros del equipo piensan pro activamente en soluciones / oportunidades de mejora para todos los procesos inclusive los que no están relacionados a Scrum?

Historias de Usuarios.

  1. ¿Los requerimientos son elaborados en conjunto con los clientes/usuarios?
  2. ¿Existe y es visible una visión de Producto definida por el Product Owner en conjunto con los usuarios?
  3. ¿Se han definido los objetivos y métricas con el Product Owner y los usuarios?
  4. ¿Los requerimientos son redactados de una forma entendibles por todo el equipo de desarrollo, equipo de soporte y usuarios en historias de usuario?
  5. ¿Por cada historia de usuario/requerimiento se lleva un seguimiento del estimado de la cuanto falta para terminar la implementación?
  6. ¿Existe un Release Plan aprobado por los usuarios y el PO?

Product Owner & Product Backlog

  1. ¿El Product Owner es realmente una persona que conoce el negocio y la visión del producto?
  2. ¿El Product Owner asiste a todas las reuniones que define Scrum y acordadas con el equipo?
  3. ¿Es el Product Backlog transparente (disponible y entendible)?
  4. ¿El Product Backlog se encuentra priorizado y cuenta con una definición para el Valor de Negocio?
  5. ¿El Product Owner está disponible durante el Sprint cuando lo requiera el equipo?
  6. ¿Se refina y se crean las tareas para el Product Backlog Ítem ordenado como el más importante durante el Sprint Planning Meeting?
  7. ¿Los Product Backlog Ítems del Sprint Backlog tienen definido el valor de negocio y ROI ?
  8. ¿Las prioridades de los requerimientos de arquitectura más importantes son balanceadas con los requerimientos de negocio y el valor de negocio a entregar al cliente?
  9. ¿Cada incremento potencialmente usable consiste en los requerimientos más valiosos y estos requerimientos crean una solución usable con la mínima funcionalidad requerida?
  10. ¿El progreso del producto es visible y está disponible a través de un “Burndown”?

Daily Scrum

  1. ¿El “Daily Scrum” se realiza diariamente?
  2. ¿El “Daily Scrum” se lleva a cabo a una hora predeterminada?
  3. ¿Se encuentra presente todo el equipo de desarrollo?
  4. ¿El “Daily Scrum” se realiza aun si el Scrum Master no se encuentra presente?
  5. ¿El Product Owner asiste regularmente al Daily Scrum?
  6. ¿Hay otros roles que no son del equipo de Scrum presentes?
  7. ¿Se respeta el límite del tiempo?
  8. ¿Se actualiza el tablero de Scrum durante el Daily Scrum?
  9. ¿Se actualiza el Sprint Backlog y el trabajo restante se muestra en herramientas como por ejemplo el Sprint Burndown?
  10. ¿El Daily Scrum da lugar a una reunión para resolver los impedimentos luego de esta reunión?

Sprint Planning

  1. ¿Hay un Sprint Planning Meeting en cada Sprint?
  2. ¿Se encuentra presente el equipo completo de Scrum?
  3. ¿Se respetan las dos partes del Sprint Planning?
  4. ¿Se establece el objetivo del Sprint en la Parte 1?
  5. ¿Se cuenta con los criterios de Done iniciales como una entrada?
  6. ¿La reunión tiene un marco de tiempo límite?
  7. ¿El Sprint Planning termina con un Sprint Backlog visible y disponible y se refleja correctamente en el Burndown?
  8. ¿La visión y los objetivos del Producto alineados al negocio se encuentran disponibles y son visibles en esta reunión?
  9. ¿Se estima el esfuerzo usando una estimación relativa como los Story Points?
  10. ¿Cada PBI tiene establecido el ROI en base al valor de negocio?

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