Hace un tiempo tuve una charla con la responsable de la unidad Agile de una consultora. Durante la conversación me preguntó lo siguiente “¿Podemos hacer Scrum con un equipo en Asturias?”. Antes de que pudiera contestar rápidamente contestó ella “¡Claro que sí, porque tenemos un equipo más barato, de otra manera no nos saldrían los números!”.
Scrum es un marco, son un conjunto de reglas como las del monopoly, si caes en la cárcel estarás tres turnos y si toca Daily Scrum no durará más de 15 minutos. ¿Dónde dice Scrum que no se puede hacer con equipos distribuidos?
El problema de Scrum es la escala de grises, que algunos actores pretenden introducir a base de su visión de que es “opinable”. Según Ken Schwaber solo el 15% de los equipos que dicen que hacen Scrum realmente lo hacen, el resto hacen algún tipo de “sucedáneo o derivado”. Algunos ejemplos que hemos podido ver:
“Yo hago Scrum pero… la daily solo la hacemos los días pares”.
“Yo hago Scrum pero… en la retrospectiva no participa el Product Owner porque está ocupado”
“Yo hago Scrum pero… el Scrum Master estima las tareas y se las asignan a los miembros del Development Team“
Scrum es un marco de trabajo, compuesto por varios métodos y técnicas que, unidas, nos dan una manera de lidiar contra la incertidumbre en entornos complejos (que no complicados).
¿Qué significa ser complejo?
Un ejemplo que he leído recientemente nos lo aporta Frederic Laloux:
“Un Boeing 747 es muy complicado, tiene miles de piezas, sin embargo, cuando quitas una de ellas puedes saber cómo se va a comportar el resto del sistema. Por contra, un plato de espagueti es complejo, si coges uno de ellos y tiras de él no sabrás cómo se va a comportar tu sistema”.
Hay dos tipos de complejidad que son muy importantes en el mundo de las organizaciones digitales. Por un lado la tecnología y por otro lado el mercado. Que la tecnología es compleja es algo que cualquiera que haya desarrollado entiende, aún así, hay aún desarrolladores que llegan a puestos de responsabilidad y aseguran que con una buena toma de requisitos la fecha no debería ser un problema.
En cuanto al mercado es difícil que alguien se aventure a saber cómo se va a comportar cuando introducimos en él un nuevo producto o evolucionemos uno actual. Un producto puede ser una web que va a internet a acaparar usuarios, pero también puede ser una herramienta interna para pedir los cheques de comida o las vacaciones. De una manera o de otra, no sabemos el comportamiento del usuario y por tanto, es complejo.
La complejidad nos impide planificar
Esto lo que nos enseña es que planificar un proyecto con fechas y alcance no tiene mucho sentido si vas a luchar contra algo que no sabes como va a reaccionar y que es cambiante. Para eso podemos optar por un comportamiento basado en producto. Si quieres ver la diferencia aquí dejo un artículo.
Por si hay alguna duda, Scrum es para
- 1. Investigar e identificar mercados viables, tecnologías, y capacidades;
- 2. Desarrollo de productos y mejoras;
- 3. Lanzamientos de productos y mejoras, diariamente tantas veces como sea posible;
- 4. Desarrollo y mantenimiento en la Nube (online, seguridad, por-demanda) y otros entornos operacionales de desarrollo para el uso de producto; y,
- 5. Mantenimiento y renovación de productos.
¿Puedo usar Scrum para hacer proyectos?
La respuesta es la que es “no está pensando para eso”. Cómo bien decía una compañera “Será mejor usar Scrum para hacer proyectos que usar otra cosa”. Estoy muy de acuerdo con esta afirmación, pero Scrum no está pensando para esto. Por lo tanto, es probable que si usas Scrum y quieras saber cuándo estará tu proyecto terminado seguramente sufras los problemas y frustraciones que suelen aparecer en los proyectos.
Eso sí, podemos usar partes de Scrum para hacer proyectos y tratar de mejorar el desarrollo. Esto no es Scrum, pero podría funcionar. Recordemos que Scrum se basó en muchos métodos y prácticas de otros equipos y por tanto se puede obtener de ello ayuda para nuestros equipos.
¿Se puede utilizar Scrum en otros entornos?
Según sus creadores Scrum se ha utilizado para el desarrollo de software, hardware, software embebido, redes de funciones interactiva, vehículos autónomos, escuelas, gobiernos, márketing, gestión operacional de las organizaciones y en casi todo lo que utilizamos en nuestra vida diaria, como individuos y sociedades.
¿Qué condiciones deben darse para usar Scrum?
Scrum adquiere todo su potencial cuando estamos trabajando con mucha incertidumbre, en equipos unidos, con un Product Owner identificado y con capacidad de decisión. En estas condiciones Scrum adquiere su máxima expresión, y funciona.
Y Tú ¿Para que usas Scrum?
Por supuesto. Entornos complejos implica incertidumbre. El mercado no es predecible. Las personas no son predecibles en entornos inciertos. Pero queremos asegurarnos de cumplimientos, fechas, tener el control por eso esta larga discusión dicotomica o scrum o proyecto. Cada uno con su espacio. No está mal emplear uno u otro, cada uno con su marco o reglas. Lo malo es subirse a la ola de la moda y asegurar que se hace scrum cuando se hacen proyectos con planes y alcances definidos con una fecha de cierre total. Gracias y será una larga discusión siempre.