Los 3 pilares que soportan SCRUM

Inspección, adaptación y transparencia son los pilares de esta metodología sobre los que todo debe rotar, sin olvidar uno de los principios agile más importantes: Personas y sus interacciones por encima de procesos y herramientas.

Desarrollar software en equipo no es un proceso como los que una fábrica implementa para garantizar una operación, una calidad, y una producción predecible. El desarrollador no es un operario, ni un "escriba" como un antiguo CEO mio decía (creo que no queda nadie del equipo que le monte) ... No solemos repetir el mismo código 2 veces pues siempre hay lógica de negocio diferente, no somos expertos en un tipo de escritura basada en un modelo de moda, sino que hay un proceso de ingeniería para construir un conjunto de instrucciones que faciliten que una máquina desarrolle una operación, pero además esas instrucciones deben facilitar su inspección, su prueba y evaluación previa, su mantenimiento por terceras personas y por tanto su observabilidad y adaptación a futuros requerimientos. Además crearemos artefactos que nos facilitan la transparencia en el proyecto, accesibles para cualquiera que los necesite. Todo esto por un bien mayor: la satisfacción de un Cliente.  

Agil vs Rapidez.

Que levante la mano quien piense que una metodología Agil significa rápida, veloz...  La verdad es que no hay relación alguna entre ambos términos en esta ocasión.

Que un desarrollo sea veloz o rápido puede suceder o no. No depende de la metodología, sino del equipo y sus circustancias. Sin embargo,  SCRUM ayuda a conseguir ese efecto de "rapidez" mediante varias recomendaciones:

• Reuniones definidas, alcances claros, y artefactos con valor. Esto limita las perdidas de tiempo a un 15% del tiempo del desarrollador, pero eso solo ayuda a que esté disponga de las condiciones optimas de trabajo, un trabajo que requiere concentración, evitar distracciones externas o presiones ajenas a su labor técnica.
• Responsabilidades bien delimitadas. Facilita la rapidez debido a una Auto-Organizacion efectiva del equipo de desarrollo. No solo el Product Owner o el ScrumMaster tienen roles y actividades bien definidas, sino que el equipo de desarrollo debe estructurarse adecuadamente para facilitar una evolución del trabajo equilibrada y con resultados observables por el Cliente. Para esto es muy recomendable la lectura del libro "Team Topologies" de Matthew Skelton y Manuel Pais, donde refuerzan nuestro modelo "Enabling Team" añadiendo otras 3 organizaciones de equipos muy necesarios en la mayoría de proyectos.
• Predictibilidad. No existe confianza alguna en las estimaciones de tiempo de aquello que se tiene incertidumbre o se desconoce... por tanto, solo estimamos aquello de lo que tenemos seguridad. En la práctica, la recomendación son sprints o iteraciones de 2 semanas, porque es un periodo suficiente para entregar algo de valor para el cliente y donde las incertidumbres a evaluar son mínimas o pueden subsanarse rápidamente si tenemos un trabajo bien hecho por el Product Owner.
• Independencia. El equipo de desarrollo debe trabajar en sus iteraciones con el máximo de independencia y sin interferencias. Esto incrementa su capacidad de organizar el producto técnicamente con las dependencias mínimas con el resto de la organización. Esto debe traducirse en menor nivel de acoplamiento del proyecto con otros frameworks o productos. Este tiene un efecto que se define en la ley de Conway al organizarse el software inevitablemente en la forma que se organiza el equipo.
• Asumir nuestra capacidad/ carga Cognitiva. Este concepto aplica a la capacidad mental de un desarrollador de comprender en su totalidad de forma efectiva (realista) un requerimiento o historia de usuario que ha de desarrollar. Esta capacidad es diferente de un desarrollador a otro, por suerte en SCRUM no estimamos de forma particular sino en equipo, pues todos participamos en la resolución de una historia y cada uno aporta sus capacidades convirtiéndonos en un organismo, auto-organizado que es capaz de afrontar ese reto con garantías... sino, es que el Product Owner se equivocó... y el ScrumMaster no hizo su trabajo, y no es echar balones fuera, de verdad.  ;).

• Calidad. No es un impedimento para la velocidad, si entendemos como algo hecho como aquello que cumple las especificaciones y ha sido inspeccionado, revisada su adaptabilidad y con la Transparencia debida (todos sus artefactos disponibles con el fin de satisfacer un objetivo de negocio del cliente). Por tanto:

- Que la historia sea simple, bien documentada (contexto), independiente, y con sus casos de aceptación completos 
- Que el UI este suficientemente detallado para no tener que hacer de creativo ni pensar tamaños, colores, proporciones, etc.
- Hacer pruebas unitarias no es un inconveniente para terminar a tiempo.
- Realizar Code Review por un compañero acelera su aprendizaje y mejora su calidad 
- Que un QA revise o automatice pruebas End to End tampoco.
- Que despliegue en un proceso automatizado CI/CD tampoco

Por tanto, la rapidez está muy relacionada con la capacidad cognitiva del equipo, y esta se incrementa cuanto mas esfuerzo dedican a mantenerse fieles a los 3 pilares del empirismo: Transparencia, inspección y adaptación.