Scrum Mastery

Scrum y la Business Agility

Muchas veces se tienen dudas como “Y en Scrum se puede…”, “¿y puedo hacer…?”, “¿y se puede…?”. Parece que Scrum es como un conjuro mágico en el que si solo cambias algunas cositas podría seguir funcionando. Y si en vez de ancas de rana pongo ojos de sapo, ¿funcionará? Scrum está lejos de ser una fórmula mágica que soluciona todos nuestros males. Veamos cómo la Business Agility o Agilidad Empresarial puede ayudarnos con estas cuestiones

¿Qué es la Agilidad Empresarial o Business Agility?

El problema real que encierra esta pregunta es que estamos asumiendo que Scrum es un fin. “¿Se puede hacer esto o lo otro y sigue siendo Scrum?”. Cuando a nadie le debería importar si es Scrum o no.

El día que un CEO toma la decisión de reservar una buena parte del presupuesto de los siguientes años para comenzar una transformación, no está buscando que los equipos estén haciendo Scrum, Kanban, Product Owners empoderados o equipos auto-organizados.

Nuestro CEO está buscando la supervivencia de su empresa ganando competitividad e intentando poder luchar de tú a tú algún día con las nativas digitales. Busca alcanzar la Agilidad Empresarial o “Business Agility”:

Capacidad de poner en valor rápidamente nuestro desarrollo (fast revenue)
Alta gestión de riesgos
Poder aprovechar las oportunidades de mercado

Scrum es una herramienta para activar Business Agility en las organizaciones. Lo hace creando al menos un incremento terminado, potencialmente usable, un incremento Done en cada Sprint. De esto va Scrum. No es un fin, es un medio.

Scrum no va de daily, retrospectivas bailando o similares. Va de entregar valor. Scrum nos proporciona elementos: artefactos, eventos y roles, que nos brindan una alta capacidad de inspección, adaptación y transparencia. Los pilares del empirismo. Son las armas que necesitamos para crear incrementos de alto valor y maximizar nuestra capacidad de generar ingresos.

¿Como nos habilita el Incremento “Done” la Agilidad empresarial?

Fast revenue

Los desarrollos de productos se siguen enfocando a proyecto. Primero obtenemos todos los requisitos, creamos un plan para los siguientes meses (o años) y, al final del todo, me voy al mercado a intentar monetizar.

Con el enfoque iterativo incremental que nos propone Scrum y teniendo incrementos terminados, integrados y listos para usarse en cada Sprint, podré ir buscando una version de mi producto que me permita llegar al mercado e ir generando beneficios.

Un ejemplo es el lanzamiento de Amazon Prime Videos. Con poco catalogo, sin soporte para Chromecast o sin aplicaciones nativas para tablets y teléfonos comenzó a poner en valor su nuevo producto lo antes posible.

Alta gestión de riesgos

Podemos hablar de tres grandes riesgos y la manera que tiene Scrum de gestionarlos es resolverlos.

Riesgo de mercado: ¿Estoy creando lo que mis usuarios realmente necesitan? Scrum va de crear un incremento y conseguir feedback real para adaptar mis siguientes pasos si es necesario.
Riesgo financiero: ¿Esto cuánto me va a costar? Por mucha documentación y planes que hagamos ya sabemos que siempre habrá variables que no conozcamos. E incluso las variables que conocemos tienen baja predictibilidad. La única manera de conocer el coste es realmente empezar a hacerlo y luego intentar obtener predictibilidad basada en datos históricos.
Riesgo técnico: ¿Mi idea se puede realizar con las tecnologías que actualmente estoy usando? Una vez más, la única manera de saberlo es empezar a hacerlo e ir obteniendo una nueva versión de mi producto Sprint a Sprint.

Capacidad de aprovechar oportunidades del mercado

Si tienes previsto un desarrollo de más de un año y una oportunidad de mercado llega cuando estás en el sexto mes de trabajo con todo abierto, nada integrado, en definitiva, nada terminado. O Incluso si simplemente has estado documentado lo que vas a hacer los siguientes meses, sumarte a esta nueva ola conlleva muchísimo esfuerzo. Tanto que generalmente se decide dejar pasar o esperar a terminar todo el desarrollo disminuyendo drásticamente tu capacidad de competir.

Conclusion

Una vez que tenemos claro qué Scrum es un medio para hacer crecer Business Agility en nuestra organización, será fácil respondernos a preguntas “¿en Scrum se puede…?”. Simplemente debemos pensar si al introducir un cambio estoy aumentando o disminuyendo mi Agilidad Empresarial.

¿En Scrum se puede tener dos sprints de desarrollo y luego otro de hardening?

Cuando terminen los sprints de desarrollo:

Si viene una oportunidad de mercado…
- ¿Podré sumarme a ella? No.
- ¿Alguien me puede asegurar cuándo podré hacerlo? No. Nadie puede asegurar que el hardening vaya a tomar solo un sprint o dos.
¿Puedo poner en el mercado lo que tengo al final del Sprint de desarrollo? No. Adiós al fast revenue.
¿Estamos tomando decisiones del futuro de nuestro producto basándonos en feedback real? No. No lo hemos podido poner en producción por lo que no tenemos ninguna métrica de negocio real. Al no estar nada terminado no tenemos transparencia de la situación del producto, esto nos llevará a discusiones sin fundamento con los Stakeholders en la Sprint Review eliminando nuestra capacidad de adaptación al mercado.

¿En Scrum se puede hacer la Daily Scrum 2 veces por semana?

La Daily Scrum nos permite inspeccionar el avance de nuestro Sprint para alcanzar la Sprint Goal con nuestro Incremento. El Sprint Goal puede representar una hipótesis sobre nuestro producto que negocio quiere comprobar si realmente es lo que quieren los usuarios y si nos va a otorgar el beneficio esperado. Por ejemplo, que mis usuarios van a querer pagar con Paypal.

La Daily Scrum es una manera de maximizar las posibilidades de que el equipo de desarrollo tenga terminado todo el trabajo relacionado con la Sprint Goal a final del Sprint. Eliminando algunas daily,

¿estoy ayudando a mi Agilidad Empresarial o poniéndola en riesgo?

El Scrum Master vs el Agile Coach

En Septiembre estuve unos días trabajando en Colombia con el equipo de Scotia Bank, formando a futuros Scrum Masters y Product Owners. También estuve en las oficinas de Everis en Bogotá en un Meetup organizado por Agiles Colombia.

En ambos sitios me hicieron una pregunta que creo ronda la cabeza de más de uno, así que me anoté hacer la primera newsletter después de las vacaciones sobre este tema: ¿Que diferencia al Scrum Master del Agile Coach?

Los orígenes

Cuando Takeuchi y Nonaka, con la ayuda de Ken-Ichi Imai hicieron una investigación en 1986 sobre el rendimiento de determinados equipos de compañías líderes en el desarrollo de producto, hicieron un símil con el Rugby, y específicamente con las Melées (Scrum) para definir lo que hacía distintas a estas compañías de otros equipos.

En ese momento no hay ninguna mención a roles fuera del equipo de desarrollo de producto.

Posteriormente, cuando Ken Schwaber y Jeff Sutherland modelan y prueban un proceso de desarrollo de Software que presentan en 1995, tampoco incluyen la necesidad de un actor externo al equipo. Hay que hacer notar que Scrum podía basarse en los roles propuestos por Ian Graham y estaba fuertemente ligado a la programación orientada objetos.

En la primera versión de Scrum, no hay una mención explícita al Scrum Master. Tampoco hay una práctica de retrospectiva, pero de eso hablaré más adelante.

En 1999, Kent Beck publica el libro sobre Extremme Programming. Describe la necesidad de incluir roles claros dentro de XP, entre ellos el de Coach. Por primera vez menciona la necesidad de una persona que se encargue de tomar el rol de “Acompañar y entrenar” a los miembros del equipo. Durante los años 1999 a 2004, XP fue mucho más popular que Scrum.

Después de crear Scrum y con las experiencias acumuladas de Jeff Sutherland en Easel y Ken Schwaber en Fidelity, además de los trabajos de Kent Beck en XP y Martin Fowler sobre la integración continua, todos estos actores, junto con aquellos que había tenía mucho éxito en XEROX y 3M durante finales de los 80 y los 90, empezaron a intercambiar experiencias que dirigirían de manera definitiva todos estos marcos, metodologías y librerías de prácticas.

Un ejemplo de esto es el uso de retrospectivas, que sólamente se popularizó con la publicación del libro de Norman Kerth en el año 2002. Para entonces la Agile Alliance y la Scrum Alliance hacía tiempo que eran una realidad.

Ken Schwaber ya daba cursos de Scrum y hacía tiempo que había incorporado la figura del Scrum Master dentro de sus materiales, como se puede comprobar en este PDF que utilizaba para training en el año 2002.

De hecho, la figura de coach ya era popular en el año 2003 cuando se debatía sobre su rol en el éxito de compañías, como se puede comprobar en este paper resumen de la 18ª conferencia de la ACM.

¿Quien era un Agile Coach? Alguien que tiene una visión global y es capaz de promover cambios competitivos en una compañía a través de su experiencia en el campo de la gestión de desarrollo de producto.

¿Y el Scrum Master? Es, quien siendo miembro de un equipo Scrum, ayuda a éste y a la organización a mejorar el valor entregado a través de la entrega rápida de producto terminado.

Entonces la principal diferencia es que mientras el Agile Coach actúa principalmente a un nivel de departamento o de organización, el Scrum Master lo hace desde la entrega (delivery) y también la organización.

El Scrum Master y el Agile Coach en 2020

Recuerdo poco antes de la última CAS, cuando cenando con unos amigos, uno me dijo: “Después de escucharte he llegado a la conclusión de que yo también soy Agile Coach”. Eso me produjo una sensación de desasosiego. Estaba claro que algo había explicado mal cuando una persona que definitivamente no tenía ninguna característica que la resembrara a esos Agile Coaches de 2003 pudiera pensar que transformaba organizaciones.

Existe una confusión entre disciplinas. Aquellos que llegan de fuera del mundo del Software tras haber recibido una extensa formación de coaching que en algunos casos conlleva hasta cinco fines de semana, comprueban como no hay mercado más allá de formar a otros coaches, consideran que el Agile Coaching es una mezcla de Agile con técnicas de Coaching.

Mientras que las técnicas de Coaching pueden ser ciertamente efectivas como complemento, la figura de Agile Coach necesita tener un conocimiento profundo de Negocio, Procesos y Transformación como parte de su abanico de propuestas.

Es por eso que un rol de Scrum Master puede ser más asequible. Desde un equipo Scrum, es relativamente más sencillo aprender, practicar y adquirir experiencias transformadoras desde la entrega de valor para luego exportarlas al resto de la organización.

Sin embargo, ocurre una paradoja. Mientras que parece que el siguiente paso natural para un Scrum Master es convertirse en Agile Coach, no lo es en absoluto. Esto es porque estos roles se solapan, no expanden uno sobre otro. En ocasiones, el Agile Coach puede carecer incluso de conocimientos necesarios para mejorar el valor de la organización. En otras palabras: Puede que ni siquiera pueda justificar su alto coste.

Por lo contrario, un buen Scrum Master no solamente tendrá una gran demanda, sino que muy posiblemente sea capaz de hablar con distintas capas de la organización. A diferencia del Agile Coach, donde puede (o no) hacerlo en función de su experiencia para transformar, para el éxito de Scrum dentro de la organización, no queda más remedio que hacerlo.

Resumiendo, un buen Scrum Master siempre será un buen Agile Coach, mientras que un Agile Coach será bueno o no dependiendo de sus experiencias, que en mi observación, son extremadamente variables.

Uno de los motivos por los que en Otoño celebramos la primera edición del curso de Professional Scrum Master II es dar la oportunidad a aquellos que ya están experimentando cambios de relevancia en su organización una oportunidad para poder tener un espacio donde reflexionar más allá de las prácticas y aprender nuevas formas de facilitar el cambio en su trabajo diario. Este curso, al igual que el de Professional Agile Leadership, no está tan centrado en el conocimiento como en la práctica.

Como dice Ken Schwaber: “Scrum es simple de entender y muy difícil de dominar”. Hemos querido crear un espacio donde el acompañamiento y la mentorización sean el ingrediente fundamental para proporcionar a nuestro alumnos la posibilidad de seguir creciendo acompañados por nosotros.

El estado de Scrum en 2018

En 1991, Geoffrey A. Moore publicó un libro llamado “Crossing the Chasm” (En Español: Cruzando el Abismo). Es un libro que en su primera edición llegó sólamente a las 5.000 copias vendidas, y que en posteriores revisiones en 1999 y 2014 llegó a alcanzar las 300.000 copias. Este éxito se produjo principalmente a través del boca a boca. Si inicialmente el libro apeló a directivos de empresas tecnológicas, posteriormente lo hizo a ingenieros y por último ha terminado siendo referencia en las escuelas de negocio.

El libro, en resumen, es una descripción de las etapas que tienen que pasar los productos tecnológicos para llegar a la población y cuales son sus características de adaptación en el mercado. Desde los innovadores hasta los rezagados, los productos van evolucionando a través de su adopción en el mercado de esta forma.

La hora de los talibanes y de los agilistas malos

Hace tiempo tuvimos un amplio debate en twitter sobre el Sprint 0. El resumen es que hay quien apoya que Scrum y otros métodos deberían ser flexibles y los que opinan lo contrario.

Éste argumento: “Los agilistas sois talibanes y tenéis que madurar” es un argumento muy común, especialmente entre aquellos que no se sienten cómodos en el lenguaje de todo lo que hacemos. Más sobre este argumento en el blog de Café Ágil.

Lo curioso es que para rebatir, el argumento principal es: “Hay que estar más cerca del negocio”. Como si los que trabajamos en esto no lo estuviéramos. El problema es el mismo que planteaba Moore en “Cruzando el Abismo” y que se ve divertidamente reflejado en la viñeta que preside este artículo.

Las organizaciones se dan cuenta de que cada vez están más rezagadas en la competencia por un mercado -los millenials- que las ve cada vez más anticuadas, y han encontrado en todo lo que se llame digital una salida para intentar recuperar su posición en el mercado.

Como la transformación digital es para cada uno lo que quiere, han ido bajando hasta buscar métodos que les permitan competir en ese mercado, eso si, sin cambiar un ápice sus procesos internos. Así que demandan Scrum y Kanban para el desarrollo de sus productos y esto ha dado pie a un mercado en el que Scrum y Kanban son lo que a cada uno le viene bien. En esta línea iba mi artículo sobre el mercado de limones.

Y en ese lienzo, estamos algunos diciendo: Si no haces Scrum, no lo llames Scrum. Y aquellos que aprovechan esta situación -económicamente- te dicen que eres un talibán.

¿Innovators, Early Adopters, Early Majority o Laggards?

En ocasiones me pregunto, ¿En qué fase estamos con esto de la agilidad? Y creo que ya hemos cruzado definitivamente el abismo. Palabras como Scrum o Kanban, Sprint, Iteración o Scrum Master ya son parte del vocabulario normal de muchas compañías.

Es más, hemos invertido, tal y como describe Moore en su modelo, el proceso en el cual en lugar de vender innovaciones son los clientes los que las exigen. A su manera, pero lo hacen. Eso también abre la oportunidad a vender lo que consideramos oportuno cuando nos piden agilidad.

Cada vez más surgen voces que dicen “Yo no hago agilidad, yo hago [_____]”, lo cual me parece totalmente lícito. Sin embargo, creo que es deshonesto que te compren agilidad y venderle [_____], que es en definitiva lo que vamos viendo en muchos clientes que vienen rebotados y con malas experiencias.

En Scrum, no hay Sprint 0

Si vamos a la guía de Scrum, no encontraremos mención a ninguna de estas dos técnicas. La gestión de proyectos en Scrum se produce en un sólo Sprint y abarca todo el ciclo de vida del software: planificación, diseño, desarrollo, testeo y entrega en un sólo Sprint.

Tener un Sprint 0 es solo una manera de intentar hacer Scrum en fases o lo que es lo mismo, waterfall en Sprints. En Scrum siempre se comienza por el primer Sprint y al final del mismo se entrega una funcionalidad de negocio terminada. Eso permite enfocarse en lo que es realmente fundamental para entregar esa pieza de Software.

Existe una manera de tener el tiempo necesario para montar todo el despliegue usando Scrum, y esto es simplemente ajustando la longitud del Sprint. Esta depende de dos factores:

El tiempo mínimo que el equipo de desarrollo necesita para producir valor: Si el equipo no es capaz de producir software terminado en dos semanas, ¿Para que poner Sprints de dos semanas? Si el equipo no es capaz de entregar software en 30 días o menos, hay que ver los impedimentos y eliminarlos.
Un horizonte aceptable de riesgo para el Product Owner: El Product Owner, como responsable de gestionar la inversión del desarrollo, tiene que sentirse cómodo con el horizonte de planeamiento planteado por el equipo de desarrollo.

Si el equipo no puede entregar software en dos semanas, pueden tener Sprints de 3 o de 4 semanas. Scrum no dice: “Sprints de dos semanas”, sino “Software en 30 días o menos”.

¿Que sentido tiene hacer un Sprint 0 si las necesidades del proyecto pueden cambiar en dos, tres o cuatro Sprints? Scrum es desarrollo de Software iterativo e incremental, donde cada Sprint tiene varias oportunidades de inspeccionar y adaptar. Un Sprint es un proyecto completo.

Si tomamos todas las decisiones en el Sprint 0, no estamos haciendo mucho más que una fase de “preparación al desarrollo”, donde estaremos tomando muchas decisiones que luego pueden ser erróneas conforme vayamos descubriendo nuevas necesidades que antes no estaban claras. No es muy distinto de PMP o Prince2 y nos llevará al mismo problema.

Si soy completamente incapaz de entregar Software funcionando en 30 días o menos, igual Scrum no es para mi. Y eso está bien.

Tampoco inception

Un inception es una técnica que permite descubrir que se quiere hacer para poder llenar un Product Backlog. Es una reunión ligera, que puede durar unas pocas horas, y su lugar ideal de realización es durante el Sprint Planning del primer Sprint.

Sin embargo, muchas organizaciones intentan hacer inceptions que duran varios días y luego necesitan una o varias semanas para poder analizar con detalle cada uno de los Product Backlog Items para poder ordenar el Product Backlog.

Esto tiene otro nombre: Toma de requisitos. Da igual que ahora se haga con Post-its® y en una reunión facilitada, sigue siendo lo mismo que se lleva haciendo muchos años.

Los inceptions no forman parte de Scrum, son técnicas que no deben de interferir en el framework. Por lo que nos cuentas, querido lector, los coaches de tu organización, están adaptando el marco de trabajo Scrum a las técnicas que ellos conocen.

Todas estas técnicas funcionan muy bien con Scrum siempre y cuando asumamos que hay que entregar Software terminado en 30 días o menos. No Story Points. Software terminado.

Esto en realidad esto está inventado, y se llama Waterfall (o desarrollo por fases)

El problema es que en organizaciones en las que se dan estas situaciones, la inversión en agilidad está directamente desperdiciada. Es solamente ponerle distintos nombres a lo que se ha hecho siempre. Un proyecto se convierte en las siguiente fases:

Inception: Conocido como la fase de toma de requisitos
Sprint 0: Conocido como la fase de preparación de arquitectura/inraestructura. Algunos meten el Inception aquí
Desarrollo
Testeo
Hardening o estabilización
Despliegue: Conocida como fase de igual nos hemos equivocado en cosas y tenemos que volver a empezar

Asumiendo que cada una de esas fases dura 1 o 2 sprints, estamos poniendo Software enfrente del cliente cada 3 o 6 meses. Eso en el mejor de los casos. En el peor de los casos desarrollaremos durante un año sin que el cliente haya visto nada ¿En qué es distinto esto de los métodos tradicionales como PMP o Prince2? En nada.

La premisa de Scrum es: “Software terminado en 30 días o menos”, de forma iterativa e incremental. Todo lo que sea salirse de eso, llámese Sprint 0 o Inception no es Scrum y es una señal de organizaciones y equipos inmaduros.

Si no son capaces de hacer esto, es mejor empezar con otra técnica, como el Método Kanban, que permite una mejora evolutiva partiendo de un proceso ya existente. Seguir con Scrum es abocarse al fracaso en esta situación.

Por último y para cerrar las newsletters hasta Septiembre, recomiendo la lectura del libro de Ken Schwaber y Jeff Sutherland, creadores de Scrum: Software en 30 días o menos. En el mismo se explican las mecánicas básicas de como funciona Scrum y de cual es el ciclo de vida de desarrollo de software cuando se utilizan métodos ágiles.

Scrum y Kanban, lo peor de los dos

No se en cuantas ocasiones es escuchado -y me han preguntado- si la solución a un equipo de soporte es hacer Kanban en lugar de Scrum, o si un equipo que recibe muchas interrupciones debería de pasarse a un sistema Kanban en lugar de Scrum, o hacer Scrumban.

Scrum bien hecho. Scrum mal hecho.

Scrum tiene una serie de premisas:

Tienes un producto con un Product Owner que se encarga de maximizar su valor.
Tienes un equipo de desarrollo que trabaja para ese producto.
Tienes un Scrum Master que gestiona Scrum y sirve al equipo de desarrollo.

Si no tienes un producto, no vas a obtener valor de Scrum. Si no tienes un Product Owner, no vas a obtener valor de Scrum. Si no tienes un equipo de desarrollo, no vas a obtener valor de Scrum. Si no tienes un Scrum Master, no vas a obtener valor de Scrum.

Sí, vale. Puedes hacer Daily Scrums, o Retrospectivas. Pero eso no es Scrum. Simplemente, no lo llames Scrum. Scrum es gratuito y libre para su useo, pero para hacer Scrum necesitas tres roles, tres artefactos y cinco eventos. Puedes hacerlo sin Definition of Done, Sprint Goal o Refinamiento y aún así seguiría siendo Scrum. Pero eso son los básicos.

Kanban bien hecho. Kanban mal hecho.

Kanban necesita una serie de premisas:

Tienes un flujo de trabajo que puedes visualizar
Puedes limitar el trabajo en curso (p.e. decir NO cuando algo que alguien considera urgente entra al flujo)
Tienes control para cambiary gestionar ese flujo de trabajo
Puedes establecer políticas explícítas (Clases de servicio, Cadencias, etc…)
El ritmo de llegada de nuevo trabajo es similar al ritmo de salida del trabajo.

Si no tienes un flujo de trabajo, Kanban no te va a aportar valor. Si tienes que decir que SI a todo el trabajo que te entra, Kanban no te va a aportar valor. Si no tienes control sobre tu sistema porque otro decide como funciona, Kanban no te va a aportar valor. Si no puedes decidir sobre las políticas del sistema, bueno… creo que ya está claro.

Si, puedes tener un tablero con Post-its y moverlos de un sitio a otro, asignando avatares y haciendo Daily Stand-ups y simulando que eres ágil. Pero si no cumples esas tres condiciones, a pesar de que hagas un Proto-kanban, nunca obtendrás ningún valor.

Scrumban: Lo peor de lo peor, junto.

Cuando la gente me pregunta por Scrumban, siempre me temo lo peor. El caso genérico, con ciertas variaciones es:

“Scrum no funciona para nosotros porque no tenemos un producto, nosotros trabajamos por proyectos. El Product Owner es un Project Manager reconvertido que se encarga de hacer una lista de las cosas que hay que hacer. Además tenemos un SLA y salen un montón de bugs durante el Sprint que tenemos que arreglar, así que hemos incorporado un carril de urgentes en el Sprint Backlog en el que además de hacer los bugs, vamos metiendo lo que se la ha olvidado al Product Owner. Los Stakeholders no vienen a nuestras “demos” y las retrospectivas son para el equipo de desarrollo y para el Scrum Master.

Vemos que es muy difícil saber cuanto estimar en el Sprint Planning y las cosas no salen nunca, por eso empezamos a usar Scrumban.”

Esto no es Scrumban, no es Kanban y tampoco es Scrum.

Lamentablemente esta no es una situación que se arregle con ningún método ágil, así como ningún consultor o Scrum Master va a ser capaz de hacer nada por esta organización.

La solución

El primer paso para arreglar un problema es aceptar que existe un problema. Generalmente en este tipo de organizaciones tienen claro en todas las capas que las cosas van mal, pero hay poca voluntad de solución.

Los problemas aquí deben ser atacados desde la parte ejecutiva de la organización. De nada sirve que un equipo lo haga mejor si la cultura es: “Lo quiero, y lo quiero para ayer”.

Todo lo demás son castillos en el aire.

Que hay detrás de los Elementos de Scrum.

Cuando se formula una pregunta sobre Scrum en una situación real, una buena manera de hallar la respuesta es pensando en las bases del Framework. ¿Cómo se ven sus valores y pilares afectados?, ¿Se refuerzan?, ¿Se debilitan?

Llevo tres meses en el Equipo de Jerónimo Palacios & Associates y he tenido la suerte de poder realizar co-training junto a Jerónimo. Gracias a la experiencia he obtenido una muy buena perspectiva de las principales dudas de los alumnos en los cursos de Scrum.org.

Una de las principales cosas que he observado es lo complicado que es, para alguien nuevo en Scrum, interiorizar los valores y principios. La tendencia natural es quedarse solo con los elementos , como y cuando se usan.

Como en la metáfora del “Cargo Cult” muchas organizaciones se dedican a repetir mecánicamente los eventos y a utilizar en ellos artefactos y roles de Scrum sin llegar a entender realmente cual es la verdadera razón de su uso, esperando obtener sus ventajas por simple imitación.

Este es mi primer artículo para el Blog y en él pretendo explicar de una manera breve cual son las bases detrás del Framework de Scrum.

Scrum es para entornos complejos.

Las tres variables principales a considerar en el desarrollo del software son Requerimientos , Tecnología y Personas. Ninguna es fácil de predecir y todas son susceptibles de cambiar al enfrentarnos al desarrollo de un producto. Estamos moviéndonos entonces en un entorno de problemas complejos donde conocemos menos de lo que desconocemos .

El enfoque tradicional en cascada está diseñado para escenarios fácilmente predecibles en los que una adecuada planificación puede mitigar gran parte de los riesgos y conducirnos al éxito. Este no es un mal enfoque “per se” pero en el desarrollo del software nuestros usuarios raramente saben exactamente lo que quieren y sus preferencias y necesidades cambiarán cuando comiencen a usar el producto.

El como aplicar una solución tecnológica es también un escenario de incertidumbre, ya no solo porque esta es cambiante sino porque cuando mejor vamos entendiendo un problema es mientras estamos desarrollando su solución y probándola con los usuarios.

En cuanto a las personas estas no se comportan como máquinas, no podemos anticipar ni predecir su productividad y hacer un simple cálculo. La composición de un equipo puede cambiar durante el desarrollo de un producto. Los equipos tampoco se comportan y rinden igual cuando se acaban de formar que cuando llevan tiempo trabajando juntos.

Cuando nos enfrentamos a un problema complejo donde un enfoque predictivo no sirve debemos de aplicar un enfoque empírico.

Empirismo y Scrum.

Los tres pilares del empirismo son la transparencia, la inspección y la adaptación. Realizando estas tres acciones de manera iterativa podremos desarrollar productos que mejoran y evolucionan de acuerdo a los cambios de su entorno.

Como veíamos en el párrafo anterior cuando más sabemos de un problema más fácilmente podremos adaptarnos y ofrecer mejores soluciones.

Scrum está formado sobre los tres pilares del empirismo ya que está diseñado para enfrentarnos a problemas y entornos complejos.

Elementos de Scrum y Empirismo.

¿Cómo se relacionan los elementos del framework con su base empírica?. Hay once elementos de Scrum y sus categorías son los Roles, Artefactos y Eventos.

Los Artefactos promueven la transparencia y permiten la adaptación. Son contenedores de la información que es adaptada. Los artefactos de Scrum son el Product Backlog , el Sprint Backlog y el Increment.

Los Eventos son las ocasiones formales para realizar inspección y adaptación. Aunque no son la única ocasión para adaptar los artefactos ya que estos están “vivos” y deben ser actualizados cuando sea necesario.

En cada evento realizamos la inspección y adaptación de uno o más artefactos, aunque no solo inspeccionamos y adaptamos estos :

El Product Backlog y el Sprint backlog en la Sprint Planning.
El Sprint Backlog en la Daily Scrum .
El Increment y el Product Backlog en la Sprint Review.
El propio Sprint (personas, relaciones, herramientas y procesos) y los acuerdos de mejora en la Sprint Retrospective.

Roles , Valores de Scrum y Empirismo

En el párrafo anterior explicamos cómo los Artefactos y los Eventos son los elementos del framework , aunque no las únicas partes de él, que dan soporte directo a los pilares del empirismo . ¿Qué ocurre entonces con la otra categoría de elementos , los Roles?

Hasta ahora no habíamos mencionado otra parte esencial del Scrum, los Valores. Scrum no puede funcionar sin ellos. Los valores representan la fundación de la confianza sin la que ni los pilares empíricos ni el framework puede prosperar.

Los elementos del framework que les dan soporte son los Roles y sus responsabilidades asociadas (refiriéndose a la palabra inglesa accountability). Permiten crear un entorno de organización en la que Scrum puede realmente aplicarse.

En resumen :

Estamos en entornos complejos , Scrum tiene sus bases en los pilares del empirismo y en sus propios valores. Los elementos del Framework están diseñados para dar soporte a dichas bases. Artefactos y Eventos sirven a la transparencia , inspección y adaptación. Sin los valores de Scrum este no funciona y los Roles son los elementos que refuerzan dichos valores en una organización.