Introducción
Scrum no es un marco de trabajo novedoso ni que se haya inventado siquiera en la década presente, por el contrario ya fue teorizado por Schwaber y Beedle el 2001 [Schwaber01]. Sin embargo pese a su antigüedad su popularización se ha dado recién en los últimos años.
La tardía entrada de Scrum en varios países y contextos no es necesariamente un síntoma de atraso tecnológico o cognitivo, por el contrario trae la ventaja de que Scrum llega ahora más pulido y cargado de experiencias de cosas que se intentaron pero no acabaron funcionando bien y que por eso mutaron hacia otros conceptos.
También es oportuno mencionar que Scrum no se creo de la nada sino que más bien viene fuertemente influenciado por Toyota, Lean y Extreme Programming. Considero necesario hacer esta puntualización para no pensar que Scrum es solamente unas pocas páginas de teoría ligera.
Scrum: Una definición corta
Scrum es un marco de trabajo ligero con el cual un equipo de funcionalidad cruzada desarrolla productos de manera iterativa e incremental.
Scrum: Una definición más larga
Scrum esta basado en el poder sinérgico y creativo de un equipo, no es un marco de trabajo de aplicación individual ni tampoco se adapta bien para grupos de personas aleatoriamente reunidas que no son un equipo.
Debido al fuerte componente humanista que implica el trabajo en equipo, las interacciones y resultados que se logran dentro de un equipo Scrum difícilmente son directamente extrapolables hacia otros equipos de incluso la misma empresa y peor aún de otras empresas.
En este sentido podríamos decir que Scrum es altamente situacional y dependiente del contexto temporal. Lo anterior podría hacer parecer que Scrum es sui generis pero en realidad es como cualquier deporte de equipo en el cual cada partido es diferente.
Al igual que con los deportes en equipo ocurre con Scrum que las reglas de juego son simples y conceptualmente sencillas de entender pero luego requieren práctica, pasión, constancia, adaptabilidad y disciplina para poder jugar bien en el contexto del desarrollo de un producto.
Elementos clave de Scrum
Scrum tiene tres elementos clave, a saber:
- Entregar software funcionando al final de cada Sprint
- Inspeccionar y hacer adaptaciones diariamente
- Confiar en el equipo
Imaginemos ahora que ocurriría si estos tres elementos claves no estarían presentes:
- Al no tener software funcionando al final de cade Sprint no se estaría respetando la Definición de Terminado y se estaría creando la falsa impresión de que estamos avanzando cuando en realidad existe gran acumulación de deuda técnica.
- Cada día se trataría de trabajar de acuerdo al plan inicialmente creado sin tomar en cuenta variaciones producidas por el cliente, el mercado, la tecnología o la misma gente del equipo; consecuentemente el equipo no sería adaptativo y por el contrario caería en la mentalidad rígida de ejecutar un plan sin importar lo demás.
- Al no haber confianza la gerencia cae en el síndrome de pedir reportes detallados para tratar de entender con métricas y palabras escritas el código. La desconfianza también puede existir dentro del equipo donde sus integrantes no se apoyan ni piden ayuda debido a disfuncionalidades subyacentes.
Valores de Scrum
Un equip Scrum es de por si diverso en términos de género, conocimiento, experiencias de vida, edad cronológica, etc. Tanta diversidad es beneficiosa pues ofrece oportunidades de aprendizaje, variedad de opiniones y puntos de vista.
Sin embargo, la diversidad pueden hacer que un grupo de personas nunca llegue a cuajar como equipo si las personas no tienen un sistema de creencias común; es precisamente a este sistema de creencias que los creadores de Scrum llaman Valores de Scrum [Schwaber04].
Los Valores de Scrum son:
- Enfoque
- Coraje
- Compromiso
- Apertura
- Respecto
Aunque estos valores son creencias y no algo tangible, son imprescindibles para un equipo que quiere realmente adoptar Scrum. Más aún, estos valores deben también estar presentes dentro de la empresa en la cual opera el equipo Scrum.
Las personas dentro de cada rol deben realmente vivir en su día a día estos valores para que estos estén presentes en cada evento y artefacto de Scrum.
Así por ejemplo durante el Sprint el equipo necesita mantenerse enfocado, tener el coraje de innovar, comprometerse con el objetivo del Sprint, estar abierto a aprender nuevas cosas y mantener una relación de respecto con las demás personas.
Proceso de Control Empirico
Scrum implementa un proceso de control empírico basado en observaciones de la realidad en lugar de basarse en planes ficticios quedados en el tiempo.
Es de esta manera que llegamos a que empirismo en Scrum significa trabajar basados en experiencias, hechos y observaciones y no confiar ciegamente en una planificación detallada realiza antes de empezar a trabajar.
El empirismo se basa en tres pilares fundamentales:
- Inspección
- Adaptación
- Transparencia
Aplicando inspección posibilitada a la vez por transparencia el equipo Scrum hace adaptaciones (diariamente o al menos en ciclos cortos) en su forma de trabajo, sus interacciones, sus prioridades y en el alcance realizable dentro del Sprint.
Aunque tenemos empirismo ciertas cosas como: la duración del Sprint, los miembros del equipo, o el stack tecnológico; son definidas al principio de un Sprint y deberían mantenerse constantes (salvo excepciones) para no introducir demasiada disrupción.
De manera general en Scrum buscamos mantener un delicado balance entre lo empírico y lo definido. Constantemente tratamos de mejorar el lado definido de las cosas a través de ideas que salen del aprendizaje y experimentación constante.
Scrum es un Marco de Trabajo
Como fue definido por sus creadores [Schawaber07] y [Schawaber12] Scrum es un marco de trabajo con el cual la gente puede trabajar de manera adaptativa para tratar de resolver problemas complejos, la resolución de estos problemas de forma productiva y creativa esta orientada a la creación de productos que aporten el mayor valor posible a sus consumidores finales.
Yendo un paso más atrás un marco de trabajo es una estructura básica que sirve de soporte a un sistema, un concepto, una idea o un texto. Por tanto un marco de trabajo se utiliza porque encima de él se quiere construir algo más.
Scrum al ser definido como un marco de trabajo puede ser extendido y complementado con otros conceptos y herramientas. En este sentido Scrum es en realidad un meta-marco de trabajo que incorpora elementos empíricos de control.
Los elementos empíricos de control son los que precisamente nos indicarán si las extensiones que hacemos con el marco de trabajo son beneficiosas o por el contrario distorsiona el marco de trabajo y lo alejan de su esencia.
Scrum no es una metodología y menos una metodología ágil como comúnmente se cree. Es más, los creadores de Scrum nunca pretendieron crear una metodología pues una metodología es un conjunto de pasos científicamente estudiados que al ser aplicados siguiendo un orden metódico garantizan un resultado.
Un marco de trabajo, en oposición a una metodología, esta minimalistamente definido e invita a la creatividad y complementación con herramientas, ideas, y prácticas importadas de otras disciplinas.
En términos simples:
- un marco de trabajo invita a la creatividad y require trabajo efectivo en equipo
- una metodología invita al cumplimiento y requiere supervision y control efectivo.
Otra distinción fundamental es que en una metodología métricas duras y precisas son piezas fundamentales mientras que en un marco de trabajo toman relevancia la colaboración, el trabajo en equipo y la comunicación.
Scrum requiere práctica dedicada
Debido a que Scrum es un marco de trabajo ligero conceptualmente fácil de entender mucha gente y organizaciones tienden a subestimarlo y realizar solamente adaptaciones cosméticas.
Desde luego los cambios cosméticos son los más simples y en teoría baratos de hacer, el gran problema con ellos es que no acaban cambiando sistemicamente el diseño organizacional que es imprescindible para que Scrum florezca. Un problema secundario pero no menos importante es que los cambios cosméticos acaban creando desilusión después de un tiempo y la consecuentemente la falsa impresión de que Scrum no funciona.
La simplicidad conceptual de Scrum también provoca la falsa impresión de que es solamente un tema de leerse quince páginas, asistir a un curso de dos días y pasar un examen a libro abierto. Muy por el contrario Scrum tiene muchas pero muchas disciplinas aliadas y conocimiento complementario que solamente puede ser adquirido a través de la lectura, investigación y práctica constante.
Haciendo una analogía con la practica del yoga, una persona no puede esperar todos los beneficios que provee esta disciplina ancestral sin practicarla diariamente y un practicante devoto de yoga es además un lector e investigador que entiende a cabalidad los principios y fundamentos de su disciplina.
Conclusiones
Scrum todavía tiene un camino muy largo por recorrer en su evolución teórica que se enriquece con la practica constante traducida en producción intelectual de contenido, basta ver nada más la cantidad de libros y otros materiales que llevan como tema central Scrum y han sido producidos en la última década.
Sin embargo uno de los riesgos latentes es que Scrum sea mal entendido y consecuentemente mal aplicado, por eso el énfasis de este texto en los principios, valores, esencia e influencias que recoge Scrum.
Mucha gente afirma que para adoptar Scrum se requiere un cambio de paradigma mental, yo pienso que hay en realidad habría que empezar por un cambio de paradigma organizacional sistemático para de ahi recién derivar el cambio de comportamiento que consecuentemente acabará cambiando el paradigma mental.
Finalmente, adoptar Scrum es similar a adoptar cualquier otra disciplina, deportes o arte que apasiona a sus seguidores y que requiere tiempo, esfuerzo, dedicación y práctica constante para obtener sus verdaderos beneficios.
Bibliografia
Schwaber01 Schaber K., 2001. Agile Software Development with Scrum
Schwaber04 Schaber K., 2004. Agile Project Management with Scrum
Schwaber07 Schaber K., 2007. The Enterprise and Scrum
Schwaber12 Schaber K., 2012. Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust
