Scrum en la practica

Has estado haciendo mal el Sprint Review… y lo sabes

Algo curioso que ocurre en muchos de mis clientes es que me preguntan: ¿Por qué no funciona Scrum? o ¿Cómo podemos mejorar la calidad con Scrum? y cosas similares. Mi respuesta es comúnmente la misma: ¿Cómo haces Scrum?

El Sprint Review es un caso paradigmático. En Scrum, es la reunión de negocio por excelencia. La mecánica es muy sencilla: El Equipo Scrum muestra el incremento para ser inspeccionado y adaptado, explican cuales han sido los problemas que han tenido y cómo los han resuelto; después los stakeholders discuten con el PO y el Equipo de desarrollo cuales son las condiciones actuales de negocio y actualizan el Product Backlog. Está todo mucho mejor explicado en esta receta para conseguir un buen Sprint Review.

Y entonces empiezan los problemas. El Product Owner no puede estar en el Review. ¿Stakeholders? No me hagas reír. Nadie sabe las condiciones actuales del negocio. El equipo de desarrollo no ha completado un incremento de Software. No hay Product Backlog. Pero la culpa la tiene Scrum.

Es muy curioso que con todas esas vías abiertas en la capacidad competitiva de la empresa y de dar servicio a sus clientes, le echen la culpa a Scrum. Como si el capitán del Costa Concordia hubiera dicho que la culpa es del mar. No hay nada que pudiéramos haber hecho.

Si quieres hacer un buen Sprint Review, ya sabes:

Al principio del Sprint había un Sprint Goal contra el que trabajar.
Asegurate de que el equipo Scrum ha trabajado en tener un incremento terminado
Los stakeholders están invitados y asisten al Sprint Review
Hay una conversación acerca de qué ha ido bien y mal durante el Sprint.
Se actualiza el Product Backlog y se explican las siguientes prioridades acorde con las condiciones de negocio

Por supuesto, si eres Scrum Master y te enfrentas a una de las situaciones descritas arriba, puede que pienses: “Pero esto es imposible, yo no puedo cambiar la organización”. Entonces ve buscando otro trabajo porque no vas a durar mucho en la industria. Cuando hablamos de eliminar impedimentos, hablamos de ayudar a mejorar y cambiar a la organización, no de arreglar teclados y organizar reuniones.

La diferencia entre un Scrum Master experimentado y uno que no tenga experiencia es la capacidad de influenciar a la organización sin el poder para ello. Esa es la característica que hace a un Scrum Master ser excelente.

El verdadero sentido de los equipos cross-funcionales

Cuando usamos Scrum, la pregunta ¿Qué significa un equipo cross-funcional está siempre presente. La respuesta es muy sencilla: un equipo cross-funcional es aquel que tiene todos los perfiles necesarios para entregar un incremento de Software terminado al final de cada Sprint.

La complejidad de entregar Software

En el artículo sobre DevOps y Scrum, uno de los puntos más importantes a favor de la integración de desarrollo y operaciones es la capacidad de hacer software que esté orientado a la puesta en producción.

Anteriormente, también hemos hablado de como Scrum es una herramienta de gestión de la complejidad. Desarrollar software es complejo. Más que construir un edificio o cualquier otro tipo de ingeniería. Al ser un proceso completamente abstracto, las posibilidades son ilimitadas. Y las limitaciones son desconocidas. Gestionar esa complejidad es una tarea complicada. Merece la pena echar un vistazo a la Matriz de Stacey para entender este punto

El ciclo de vida del software

El ciclo de vida del software normalmente conlleva cuatro o cinco pasos fundamentales: Planificar, diseñar, desarrollar, probar y poner en producción. En Scrum todos estos pasos ocurren cada Sprint y todos los Sprints. Si no somos capaces de ejecutar todos ellos en un sólo Sprint, entonces tenemos que reconocer que existe un problema organizacional. Estos son los impedimentos que un Scrum Master ayuda a una organización a eliminar. No arreglar teclados o gestionar reuniones.

Las organizaciones que usan metodologías ágiles tienen que adaptar su mapa organizacional a un método que les permita ser ágiles. Tener un Sprint de diseño, uno de desarrollo, uno de testing y uno de operaciones no es utilizar Scrum, es hacer waterfall en Sprints. No hay que confundirse. Probablemente tenga un beneficio para la organización y en muchos casos esto acorte en buena medida el ciclo de vida del desarrollo de software, pero sigue sin ser Scrum.

Decidir la duración de un Sprint

Parece aceptado que el tiempo estándar de un Sprint es de dos semanas, sin cuestionamiento. Esta ha sido la recomendación clásica de autores como Mike Cohn o Roman Pichler. Sin embargo, tenemos que ir un paso más allá y ver cuales son los dos factores fundamentales para decidir la duración del Sprint:

El tiempo mínimo que necesita el equipo de desarrollo para entregar una pieza de Software terminado. Esto incluye los pasos expuestos más arriba: Planear, diseñar, desarrollar, probar y poner en producción.
Un horizonte aceptable de riesgo para el Product Owner. Quizás el Product Owner no considere oportuno entregar Software más allá de dos semanas. O quizás esté bien que se tarden 30 días o menos.

La realidad es que Scrum dice: Software en 30 días o menos. No dice Sprints de dos semanas. El objetivo es tener ciclos cortos de feedback que permitan transparencia, inspección y adaptación.

Los equipos cross-funcionales son la manera de entregar software en 30 días o menos

Ahora es más fácil ver por qué los equipos cross-funcionales significan cosas distintas para empresas distintas. Mientras que para una start-up un equipo cross-funcional puede ser todo desarrolladores junto con una persona de producto, para un banco, los equipos cross-funcionales deben de incluir un business analyst, alguien de compliance, un dba, un tester y alguien de operaciones.

La única manera de preguntarnos si tenemos equipos cross-funcionales es mirar si estamos entregando software terminado cada Sprint. Si no, es un impedimento a eliminar. En muchas ocasiones, eliminar ese impedimento supone desafiar el status quo de la organización para mejorar y optimizar procesos.

Este proceso es agilidad y transformación en estado puro. Scrum es simple pero no es fácil.

Comparativa de certificaciones ágiles – ¿Cuales son las mejores?

Cuando se trata de certificaciones ágiles es difícil saber elegir una que se adecue a las necesidades que tenemos. Hace unos años, la única opción eran las certificaciones de la Scrum Alliance. Veamos el panorama de certificaciones ágiles que hay hoy en día

Scrum Alliance

A partir de 2002, Ken Schwaber creó el curso Certified Scrum Master, para divulgar Scrum por todo el mundo. La idea del Certified era ofrecer una formación práctica sobre Scrum y el rol del Scrum Master. Al poco tiempo, Ken empezó a recibir propuestas para permitir que otros trainers enseñaran el curso CSM. En 2004, Ken funda la Scrum Alliance -previamente habas fundado la Agile Alliance- para gestionar todo el proceso de enseñanza y certificación en Scrum.

Actualmente, la Scrum Alliance ofrece varias certificaciones:

Certified Scrum Master

El CSM es el curso estrella de la Scrum Alliance. El enfoque es enseñar el framework Scrum y el rol del Scrum Master. Cada Trainer decide y elabora su propio material para enseñar. Hace unos años no había revisión del mismo, aunque actualmente para ser trainer, hay que pasar un proceso de revisión de pares.

El curso CSM dura dos días y para obtener la certificación final, hay que realizar un examen de 10 preguntas sobre los contenidos de Scrum. El coste ronda los 950-1.500€, y hay que pagar cada dos años para mantener la certificación.

Ver el curriculum del CSM

Certified Scrum Product Owner

Hacia 2007, la Scrum Alliance incorporó una nueva certificación, la de Product Owner, orientada a profesionales que ejercen este rol en el día a día. De nuevo, el contenido varía de un trainer a otro, aunque hay unos objetivos de aprendizaje que todas las clases deben de cumplir.

El coste del CSPO es similar al de CSM, y hay que pagar cada dos años para mantener la certificación.

Ver el curriculum del CSPO

Certified Scrum Developer

El CSD se centra en el rol del desarrollador como parte del equipo Scrum. En este caso, los contenidos y la calidad cambian significativamente dependiendo de los conocimientos y las habilidades del trainer.

El curso tiene dos días -o más, dependiendo del trainer-, y cubre el curriculum que un desarrollador tiene que saber sobre Scrum, aunque en muchas ocasiones se limita a una mezcla entre los contenidos del CSM y CSPO. Para obtener la certificación final, es necesario asistir también al CSM. El coste varía, pero supera fácilmente los 2.000€. También hay que pagar para mantener la certificación.

Ver el curriculum del CSD

Scrum.org

Con la salida de Ken Schwaber de la Scrum Alliance en 2008, se abrió una nueva vía de certificación. Ken, fundador original junto a Ester Derby y Mike Cohn de la Scrum Aliance, funda Scrum.org, desde donde intenta mejorar la forma que existe de formar y certificar a profesionales ágiles.

La gran ventaja de Scrum.org es que el proceso para ser trainer es mucho más transparente. Sus examenes de certificación son mucho más rigurosos y realmente demuestran la capacidad de conocer y aplicar Scrum.

Professional Scrum Master

Es la certificación más extendida de Scrum.org. El objetivo no es tanto aprender sobre las mecánicas de Scrum -se supone que hay que venir estudiado al curso-, sino saber temas avanzados de Scrum, desde valores hasta excelencia técnica, pasando por casos de implantación y problemas típicos.

Este curso se encuentra un paso por encima de la mayoría del mercado, ya que no sólo enseña, sino que habilita a los alumnos para implementar Scrum. El coste del PSM es de 150$ o gratuito si el alumno ha asistido a un curso oficial. La certificación se puede obtener sin necesidad de asistir al curso. Aquí tienes consejos para superar el PSM.

Además, existen otras dos certificaciones por encima.

El PSM II, de reciente introducción, certifica que el alumno no sólo poder conocimientos (PSM I) sino que además tiene experiencia en la implantación y el uso de Scrum en un entorno real. Tiene un coste de 250$. El PSM III es una certificación de evaluación manual orientada a la maestría en Scrum y tiene un coste de 500$. Preparar estas dos certificaciones es complicado, casi imposible si no se tiene experiencia real trabajando en un entorno con Scrum durante al menos dos años. No hay que pagar por mantener la certificación. Es vitalicia.

Ver las áreas del PSM

Professional Scrum Product Owner

El PSPO, de nuevo contrapuesto al CSPO, es una certificación orientada a Product Owners. Para superarla, no es sólo necesario conocer el framework, sino tener un conocimiento detallado de cual es el papel de un Product Owner dentro de un equipo Scrum. Tiene un coste de 150$ o gratuito si se asiste a un curso de Product Owner.

El PSPO II certifica una experiencia real en un entorno Scrum a través de un examen de evaluación manual, en el que se tratan temas reales y casos a través de respuesta escrita, no de respuesta múltiple. Tiene un coste de 500$. Los alumnos que asisten a los cursos, tienen un descuento.

Ver las áreas del PSPO

Professional Scrum Developer

El PSD es un curso técnico, en el que los alumnos aprenden técnicas de desarrollo de software en un entorno Scrum. Dura 3 días y existen tres versiones: PSD.Net, PSD Java y genérico. Es necesario un conocimiento técnico para asistir al curso, donde se aprenden las técnicas a través del desarrollo de software en un stack real.

La certificación cubre los aspectos técnicos necesarios para utilizar Scrum. Desde el framework hasta preguntas relacionadas con buenas prácticas de desarrollo de software, testing y despliegue del software. Tiene un coste de 150$.

Ver las áreas del PSD

Scaled Professional Scrum

El SPS es una certificación orientada al conocimiento de escalado de Scrum a través del framework Nexus. Más adelante publicaré un artículo específico sobre escalado, pero mientras tanto puedes leer esta comparativa entre frameworks ágiles de escalado. Tiene un coste de 250$.

Ver las áreas del SPS

Project Management Institute

Posteriormente, el Project Management Institute (PMI) sacó su propia certificación. El PMI-ACP. Junto con la salida del PMBoK v5, esto supone un cambio de rumbo en la política del instituto de Project Management más grande del mundo, que hasta entonces había renegado de los métodos ágiles.

PMI Agile Certified Practitioner

El PMI-ACP es una certificación Omnibus. No solamente cubre Scrum, sino otros métodos ágiles, en un formato pesado más parecido al PMP® que a un formato ágil. Para completarla es necesario tener un mínimo de unidades de aprendizaje y pasar un examen. Para mí, el principal problema del ACP es que se centra más en pasar el examen, al igual que su hermano mayor el PMP, que en realmente saber aplicar alguno de los frameworks.

Ver PMI ACP Handbook

Scrum Manager, Scrum Study, European Scrum, Otras…

Últimamente, cada vez más empresas se han apuntado al carro de la certificación. Pocas de ellas cuentan con un respaldo real de líderes en el mercado. Scrum Manager tiene muchos años pero se quedó en versiones antiguas del framework Scrum. Hasta donde yo conozco, no incorpora las revisiones de Scrum de 2011, 2013 y 2016. El enfoque es todavía muy basado en procesos. Scrum Study es una submarca de VMEdu Inc., una empresa India que tiene un modelo de certificación muy similar, incluso han desarrollado un Scrum Body of Knowledge, al margen de Scrum y de lo que se usa en las empresas. Un Español, David Martí, ha fundado una marca llamada European Scrum, de la que al parecer es el único trainer. Todas estas certificaciones, al margen del conocimiento, no tienen reconocimiento en la industria.

Formar equipos ágiles cuando estás empezando en Scrum

Tu compañía ha decidido aplicar Scrum para transformar el proceso de desarrollo de producto e intentar mejorar así la agilidad organizacional. Pero nadie tiene claro como empezar a hacerlo.

Quizás hayáis recibido formación o quizás hayáis visto algunos videos de introducción a Scrum. En cualquier caso hay dudas sobre cuales son los pasos adecuados. Esta guía te ayudará a enfocarte en los puntos correctos y ahorrarte quebraderos de cabeza.

Asegurate de que tienes un compromiso de la organización para acometer el cambio

Lamentablemente, es muy normal ver cómo hay compañías que intentar implementar Scrum y hacen un gran esfuerzo, sólo para descubrir que tienen todo en su contra. Hay autores como Mike Cohn que abogan por un “Stealth Scrum”, lo que puede funcionar con muchas limitaciones.

Es mejor si existe un compromiso expreso de dar una oportunidad al framework. Lo mejor es empezar con un proyecto pequeño. Que no sea crítico para la organización pero que no sea tan irrelevante como para que a nadie le importe el éxito del mismo.

Selecciona un Product Owner, la persona responsable del desarrollo del producto

Este es el primer paso fundamental para hacer Scrum. Nombrar a alguien para que sea el representante de las necesidades de negocio y que actué de Product Owner de negocio. El Product Owner se va a encargar de preparar un backlog priorizado para desarrollar. Es probable que al principio sus responsabilidades también toquen las de Product Management, aunque si puede trabajar con un Product Manager es mejor.

Evita:

Los comités de personas que deciden el Product Backlog
Una persona que no pueda dedicar el 100% de su tiempo al desarrollo
Alguien que realmente no tenga autoridad.

Si Scrum es bueno en algo, no es en agilizar organizaciones, sino en hacer transparentes los verdaderos problemas de las mismas. Si en tu organización el management no tiene el liderazgo suficiente para tomar una decisión de ese calibre, deberías de enfocar el esfuerzo en eliminar ese impedimento antes de seguir.

Resolver estos impedimentos ayudará a incrementar la agilidad organizacional.

El Product Owner tiene que buscar al equipo de desarrollo

Ya sea mediante voluntarios o mediante convencimiento uno a uno, el Product Owner debe buscar al equipo en el que va a confiar e invertir para desarrollar el producto. Recuerda, el PO es el último responsable del retorno de la inversión de ese equipo, así que es quien debe tomar la decisión de trabajar con equipo con el que se sienta cómodo.

Evita:

Seleccionar al PO por un lado y al equipo por otro y decirles que trabajen juntos.
Coger gente de aquí y de allí sin saber que tienen todas las skills necesarias para entregar software terminado.
En general, cualquier atajo que no sea reconocer la situación de tu organización.

¿Cómo decide el PO quien es el adecuado para formar el development team? Fácil. El Development Team tiene que tener de 3 a 9 miembros que tengan todas las habilidades necesarias para entregar un incremento terminado de Software, por pequeño que sea. Es el propio equipo y las personas técnicas de la organización quienes ayudaran al PO a entender esto.

El equipo de desarrollo busca a un Scrum Master

El papel del Scrum Master es dar servicio al equipo de desarrollo y gestionar Scrum. Éste responde exclusivamente al equipo de desarrollo y trabaja para mejorar el uso de Scrum y aumentar el valor del producto.

Evita:

Seleccionar a un Scrum Master que nunca haya hecho Scrum.
Reutilizar una persona existente sin experiencia. Sólo volverá a lo que hacía antes
Pasar del Scrum Master porque no es justificable.

Comienza con Scrum

Cumplir estos elementos te llevará unas semanas. Durante este tiempo, las personas de tu organización se irán acostumbrando a escuchar hablar de Scrum y eso es positivo. Una vez que todo el mundo esté preparado y el Product Owner tenga claro cual es el Sprint Goal del primer Sprint, podéis comenzar con el primer Sprint Planning.

Evita:

Sprint 0. No existe en Scrum y es una práctica que sólo sirve para reafirmar los modelos en cascada. Demuestra inmadurez.
Intentar hacer predicciones. Por mucho que quieras predecir que va a pasar, sólo el histórico de incrementos terminados te dará datos reales.
Presionar a través de la motivación. Lo mejor es dejar que el equipo haga al ritmo que puedan. Intentar presionar a través de una falsa motivación sólo llevará a la frustración.

Llegado este momento, ya habrás hecho un largo recorrido de cambio que habrá hecho que, en general, aumente la agilidad organizacional. A partir de entonces se abre un abanico muy amplio de opciones que tendréis que ir explorando utilizando los tres pilares de Scrum: Inspección, Adaptación y Transparencia.

Quizás después de leer esto pienses que no es posible hacer Scrum así, que necesitáis adaptarlo. Este es un atajo común que muchas organizaciones siguen y es, sin duda, el más costoso, doloroso y caro que hay. No afrontar los problemas de forma temprana llevará a perpetuar un modelo basado en la incertidumbre y la baja calidad si cabe aún durante más tiempo.

Métricas ágiles fundamentales (I)

La principal medida de progreso en marcos de trabajo ágiles no son los puntos de historia, sino el software terminado. Muchos equipos siguen utilizando una medida de estimación subjetiva como una métrica absoluta para predecir. Malas noticias. Los puntos de historia (story points) no sirven para nada. Las buenas. Existen varias métricas ágiles que son fundamentales y pueden empezar a usarse inmediatamente. Veámoslas.

Métricas Macro

Las métricas macro son aquellas que permiten obtener información a alto nivel de una pila de tareas por hacer, lo cual permite tomar decisiones o plantear teorías para el conjunto de equipos que desarrollan un producto.

El Cumulative Flow Diagram (CFD)

Este diagrama indica cuantos Product Backlog Items hay en cada uno de los estados del backlog. Para obtenerlo, se puede usar software -en el caso de la imagen, JIRA- o de forma manual de forma muy sencilla. Esto es, dibujando un diagrama, y al final de cada día, actualizando el valor acumulado de cada uno de los elementos que tenemos en el Product Backlog.

WIP

La primera de nuestras métricas ágiles es el WIP. El WIP nos indica en cualquier momento el trabajo que está en curso. Si miramos el diagrama detenidamente, podemos obtener el trabajo en curso en cualquier momento midiendo la distancia entre el trabajo pendiente del backlog y el trabajo que todavía no ha sido entregado. Esta medida nos indica, de un vistazo, si los equipos están trabajando en demasiadas cosas a la vez.

Reducir el trabajo en curso contribuye a reducir la frecuencia de entrega. En entornos ágiles, las entregas frecuentes son muy importantes y permiten obtener un feedback rápido del cliente para poder adaptar la estrategia.

Algunas organizaciones tienen 6 o más meses de trabajo en curso. ¿Que significa eso en métricas de negocio? Que existe una inversión que no está produciendo ningún resultado y que conforme pasa el tiempo, reduce su posible retorno (ROI) y por tanto aumenta el riesgo. Reducir el trabajo en curso se hace más fácil relacionando las métricas de producto con las métricas de negocio de esta manera.

De esta manera, se justifica la necesidad de introducir técnicas de Continuous Delivery o DevOps en los equipos de desarrollo, o incluso de refactorizar la base de código para facilitar entregas más frecuentes.

Average Customer Lead Time

Si trazamos una línea horizontal en el diagrama de flujo acumulado, obtenemos el tiempo medio de entrega al cliente para el conjunto de nuestro Product Backlog. A pesar de ser un concepto de Scrum, también se puede utilizar en Kanban u otros métodos.

El tiempo medio de entrega al cliente nos dice cuanto pasa, de media, desde que ponemos algo en el backlog hasta que esto está entregado. Es un concepto macro. Puede que haya elementos del backlog que normalmente tarden mucho menos o mucho más.

Si un equipo no se siente identificado con un customer lead time muy alto ya que normalmente tardan poco en completar los ítems, hay que observar varios factores.

El primero es si la definition of done de ese equipo permite realmente poner el software en producción. Que una tarea esté hecha por el equipo y tenga que esperar un proceso de puesta en producción hace que su ROI descienda con el tiempo.

El segundo puede ser que el Product Backlog se haya convertido en la “carta a los reyes magos”. Eso hace que las posibles ideas junto con el análisis de su beneficio vayan perdiendo sentido con el tiempo y que el Product Owner no esté trabajando lo suficiente para mantener un backlog que aporte valor al negocio.

Cycle time

Si trazamos la diagonal entre el WIP y el Customer Lead Team, obtenemos el tiempo de ciclo. Esto es, el tiempo que el equipo pasa trabajando en la tarea hasta que esta está entregada. Esto no es el tiempo real que un desarrollador tarda en realizar la tarea, sino el total desde que se empezó hasta que se dio por terminada.

Se puede ver la relación obvia entre estas tres métricas. Reducir el WIP afecta al customer lead time y al cycle time. Para reducir el Cycle Time no nos queda más remedio que reducir el Customer Lead Time.

La ley de little

En realidad, todo esto tiene un nombre: la ley de Little. Este señor demostró la relación entre el número medio de clientes en una tienda, su frecuencia de llegada y el tiempo medio que pasaban en la tienda. A pesar de sonar bastante inofensivo, es la base de Kanban.

Por otro lado, aunque usemos Scrum, podemos tratarlo como un sistema Kanban, dado que tenemos acceso a el diagrama de flujo acumulado del cual podemos extraer las métricas. En otro artículo hablaré de cómo hacerlo con números.

Así, si una organización quiere aumentar la agilidad ofreciendo software en ciclos más cortos, no tiene más remedio que invertir en mejorar las herramientas que favorecen que el software se ponga en producción, esto es, operaciones y desarrollo. Aquí entra en juego el factor humano. No se puede simplemente añadir más miembros a un equipos, sino que requiere tener en cuenta otro triángulo de hierro: El de infraestructura/arquitectura, producto y personas. En el próximo de la serie, hablaremos de métricas micro.