En el post anterior Scrum I: Nadar a través del cambio más que tratar de andar sobre las aguas hicimos un pequeño repaso de la guía de Scrum, rompiendo con algunos mitos y dando algunos consejos respecto a por qué utilizar un enfoque incremental e iterativo en el desarrollo software.
Este post pretende ayudar a aquellos equipos que comienzan a arrancar con Scrum y que suelen tener confusión debido a que tienen la idea equivocada de que Scrum, como pasaba con Waterfall, les ofrece una receta que se debe seguir al pié de la letra para llegar al éxito en el desarrollo de su producto software.
Adaptar Scrum vs Cherry-picking
Existen tantas formas de implementar Scrum como proyectos o productos. La idea principal es adaptar el framework a un contexto determinado. Llamamos Cherry-picking a coger del framework algunas ideas y descartar otras. Todo lo que se indica en la guía de Scrum es Scrum, y el resultado de hacer Cherry-picking es otra cosa que, aunque funcione en tu contexto, no es Scrum, y por tanto no debería ser llamado Scrum. Esto con otras palabras viene descrito en la nota final de la guía de Scrum.
Adaptar a Scrum a mi contexto
Cuando haces una adaptación de Scrum a tu contexto no debes perder de vista los artefactos, eventos, valores y principios de Scrum. Y sobre todo, es aplicado a todo el ciclo de desarrollo de producto, no a una etapa del mismo.
Bien estés tratando de adaptar a tu contexto Scrum o utilizando algunos elementos para crear un modelo híbrido, hay que tener mucho cuidado con incumplir los valores del manifiesto de desarrollo ágil, Esto es algo, que en los modelos híbridos con base en Waterfall, es bastante complicado de cumplir por su naturaleza. Os los resumo:
- Colaboración con cliente vs negociación contractual.
- Respuesta al cambio vs seguir un plan.
- Documentación exhaustiva vs software funcionando.
- Individuos e iteraciones vs procesos y herramientas.
El no cumplir con estos valores o con los propios de valores de Scrum suele ser la causa más habitual de «fracaso de Scrum» y esto suele llevar a la falsa percepción de que «Scrum es una metodología de juguete».
Decidir si Scrum se puede adaptar a mi contexto
Existen algunas recomendaciones que no están para nada grabadas en piedra que tratan de ayudar en la toma de decisión de utilizar Scrum u otro framework. En este caso, una recomendación que he escuchado bastante es que «si tienes el scope bastante claro a priori , encaja muy bien, sobre todo, si tienes hitos concretos con entregas».
Esta recomendación tomada al pie de la letra es bastante discutible. Primero porque suele confundirse de forma habitual «tener una visión y roadmap inicial acordado entre cliente y el equipo» con «tener un scope cerrado con cliente por contrato». Y segundo porque se confunde el término «cherry-picking de Scrum» con «adaptar Scrum».
Algo que si es cierto es que, en el caso de aquellos proyectos que tienen el scope cerrado por contrato, la organización del equipo de desarrollo mediante Scrum y prácticas XP mejora el desarrollo de producto comparándolo con seguir el proceso requerido en Waterfall o V-Model.
Pero mejorar no es sinónimo de éxito. Bajo mi experiencia, en proyectos de scope cerrado, los pocos proyectos que son entregados a tiempo satisfaciendo las necesidades de cliente (algo que en Waterfall es considerado éxito, y esto, es muy discutible) han utilizado algún tipo de enfoque incremental y adaptativo.
Esto no es una adaptación de Scrum a un contexto sino que es un modelo híbrido donde hemos hecho cherry-picking en una de las etapas del ciclo en cascada: el desarrollo por norma general.
Otra recomendación es que Scrum suele ser un buen punto de partida para comenzar a aplicar Agile en nuestros proyectos. Sobre todo para equipos que no tienen ninguna experiencia con Agile. Con esto, en ningún caso quiero afirmar que si un proyecto quiere adoptar agile tenga que hacer Scrum, pero el framework maneja conceptos que son relativamente fáciles de entender y seguir (aunque difíciles de dominar) y eso favorece a asimilación de cambio de paradigma.
Definir agilidad, no es algo sencillo
Uno de los conceptos más vagos es el concepto de agilidad. Echa un vistazo a este artículo de Javier Garzas, que habla justo de este tema. De ahí que mucha gente lo confunda ser ágil con «hacer las cosas más rápido» o «hacer las cosas de forma incremental y con equipos pequeños».
El concepto de que Agile «es una cultura y unos valores» también es en cierto modo polémico. Esto es debido a que, independientemente de estos principios y valores propicien un mentalidad ágil, para serlo realmente debe haber algo más, y esto es, una serie de prácticas concretas.
En el caso de Scrum, seguir la guía de Scrum no es suficiente. De hecho, las implementaciones de Scrum, suelen estar apoyadas por algunas o todas las prácticas XP y otras muchas buenas prácticas que rodean al desarrollo software (Principios SOLID, DRY , YAGNI, entre otros). No tienen por qué ser sólo prácticas técnicas. También deberíamos incluir equipos pequeños, auto-organizados, cross-funcionales, con poder de decisión local al proyecto y altamente motivados. Quizás si tienes más interés puedes echar un vistazo a algunos posts anteriores como:
- La serie «Enhorabuena vas a llevar un equipo»: 1,2,3,4,5
- Aumenta la productividad con pair programming.
- Motivación intrínseca.
- Integración continua: 1,2
Mi humilde opinión
Si te centras en seguir Scrum sin tener en cuenta el resto de buenas prácticas, valores y principios, probablemente no serás ágil, aunque estoy seguro de que este tema podría ser un nido de polémica.
Entiendo agilidad como una cultura, principios y valores resaltados en el manifiesto ágil unidos a su vez a los los principios y valores framework que utilicemos, más un conjunto de buenas prácticas en desarrollo software que mejoran la calidad de nuestro producto, eliminan barreras y fomentan la colaboración y comunicación en el equipo.
Por este motivo, si te consideras agilista y estás desarrollando software mediante Scrum, pero desconoces o no aplicas un conjunto de prácticas mínimas que damos muchas veces por obvias como es usar un sistema de control de versiones (en serio, esto pasa), integración continua y test unitarios, muy probablemente no estés siendo todo lo ágil que puedes llegar a ser.
Si además para ti el cliente es un ser mitológico y tu contrato es la ley, casi me atrevería a asegurar que ágil no eres, aunque, como no tengo contexto y siempre hay algo que aprender, no aseguraré nada y diré que hay una alta probabilidad de que ágil no seas.
Creo también que se puede ser ágil sin ser agilista. Me he encontrado equipos, sobre todo pequeñas empresas, que aun sin haber oído hablar jamás de Scrum o los principios y valores del manifiesto (en serio, esto ocurre) aceptaban el cambio de forma natural y su forma de trabajo era muy similar a la de un equipo ágil.
Mi conclusión es que hacer Scrum no es necesariamente ser ágil del mismo modo que hay equipos que son ágiles sin haber escuchado jamás sobre Scrum.
Y tú, ¿qué opinas?
Desde el bastión 