Una de las frases que más me ha dado vueltas desde que comencé con Scrum es:
Scrum "es" simple "pero" difícil - Alan Cyment [6]
o la misma que encontré en los libros de Kleer
(Introducción a la Agilidad y Scrum)
“Scrum is simple, doing Scrum is hard” - Jim York, CST.
Esto me ha llevado a mucho auto-estudio, a recibir, aprender y comprender el coaching que me dan en mi organización, a trabajar mucho en la mejora continua propia, del equipo y del proceso que tengo a cargo como Scrum Master. Con base en esto he recogido algunas de las frases, interpretaciones, síntesis de varios artículos y de la experiencia propia, que invitan o evitan fallar con Scrum.
Es importante anotar que una de las muchas causas por las cuales se falla en Scrum es porque el Framework no es prescriptivo, Scrum te da unos límites entre los cuales te puedes mover libremente, y en ese movernos libremente podemos caer vicios que atentan contra el mismo marco de trabajo y sus resultados.
Cada cual seleccione y use las reflexione sobre lo que más le sirva.
Y si tiene más frases, tips y desea compartirlos, bienvenidos sean, acá se publicarán y referenciarán.
Respecto a la organización
- [Falla / Fail] Falta de transparencia - 1: cuando no somos capaces de decir, lo siento no podré ejecutar este proyecto ágil a falta de:
- prácticas de ingeniería
- comunicación con un gran ancho de banda
- un cliente completamente involucrado y comprometido [1].
- [Falla / Fail] Falta de transparencia - 2: Cuando no somos capaces de decir, lo siento este proyecto por sus características es mejor que no se realice con Scrum [7].
- [Falla / Fail] Imposición del modelo: cuando es un modelo impuesto [2] y no acordado, divulgado y acompañado (correcto coaching) a la organización y al equipo que lo va a ejecutar.[7].
- [Falla / Fail] Grandes proyectos, grandes equipos: cree equipos grandes (olvídese de lo sugerido de 7 + /- 2 ) e invítelos a todos a todas las reuniones en especial al daily [2] de forma que todos hablen y estos se extiendan innecesariamente y nadie le ponga atención a nadie y el daily no les para sirva para sincronizarse. [7]
- [Falla / Fail] Cree incentivos individuales en vez de estímulos para el equipo [2]
Respecto a la proceso
- [Falla / Fail] Crea en al softwarepredicación y olvide que hacer software es complejo, lo ha sido y lo será[3]
- [Falla / Fail] Creer en Scrum como en "LA FUERZA" [3]
- [Éxito / Sucess] Comprender de que depende el éxito de ser Ágil: Ser ágil depende de:
- Darle importancia a las personas
- tener equipos multifuncionales
- comunicación
- entregar valor
- cambio de planes para aprovechar oportunidades
- equipos en el mismo espacio entre otros.[1].
- inspección y adaptación [7]
- [Falla / Fail] Microseguimiento: Ejemplo digale a su equipo que hacer durante el daily [2] y durante todo el sprint de forma que no permita el empoderamiento y el éxito o fracaso sea completamente suyo como Scrum Master [7].
- [Falla / Fail] Síndrome de la bala de plata: cuando se cree que Scrum es una bala de plata que resolverá todos los problemas. Comprenda los equipos son autogestionados, pero necesitan de un liderazgo al servicio de la mejora del equipo y de un Product Owner que tenga una visión clara que guíe e inspire al equipo[2]
- [Falla / Fail] Mala interpretación de la autogestión Cuando deje al equipo solo sin coach, sin Scrum Master[2]
- [Falla / Fail] No se cumple lo comprometido en el Sprint (sprint tras sprint)[2].: que pase una sola vez, vaya y vuelva, dos, bueno es comprensible, pero que pase sprint tras sprint y nadie tome medidas para lograr cumplir lo comprometido, esto hará fracasar scrum Unas recomendaciones en este caso son:
- comprométase con menos, o
- evalúe cual es el impedimento técnico que tiene al equipo fallando continuamente, o
- evalúe cual es el impedimento de relaciones interpersonales que los tiene fallando y trabaje en removerlo.
- busque si la falla está en las historias de usuario con criterios de aceptación ambiguos o cambiantes,
- o se están permitiendo cambiando las historias durante el sprint
- busque, busque, indague, escuche al PO, escuche al equipo y halle la causa.[7]
- [Falla / Fail] No se identifican mejoras en el proceso cada sprint: El equipo scrum ( PO, SM y Team Developer) siempre tendrán algo que intentar o mejorar al siguiente sprint, ya sea desde el punto de vista humano o técnico. No mejorar, cada sprint, o incumplir en la implementación de las mejoras ayudarán a socavar el proyecto ejecutado bajo scrum [7].[2]
- [Falla / Fail] Altere frecuente y caballerosamente el sprint backlog comprometido de forma que el P.O. no sepa nunca que le será entregado. [2]
- [Falla / Fail] No cree equipos multifuncionales: Cree varios equipos por capas o por funciones de forma que cada equipo tenga que comunicarse ardua e innecesariamente con el otro. Ej: un equipo scrum de analistas, otro equipo de testers, otro equpo scrum de desarrollo, otro para la capa de presentación, etc, etc. y etc.[2]
- [Falla / Fail] Adaptación temprana de Scrum : Ojo. no adapte scrum a la primera, siga las reglas de Scrum al menos 5 ó 6 sprints y luego de aprender y fallar siguiendo las reglas, aventúrese muy conscientemente a modificarlo.[7] [2].
- [Falla / Fail] Personalice y adopte prácticas sin tener el completo entendimiento de su porqué y para qué.[2]
- [Falla / Fail] Adopte scrum sin entender el por qué y el para qué de cada elemento del framework.[7]
- [Falla / Fail] Extienda el sprint hasta que cumpla lo pactado. Esto hace que usted no se comprometa con mejorar pues siempre esta cumpliendo y nunca falla y busca las razones que están haciendo que sus sprints se alarguen.[7]
- [Éxito / Sucess] Guiar al PO de forma que siempre se cumpla el pareto ( se implemente el 20% de funcionalidad que da 80% de valor al negocio). Un buen SM y Team Developer ayudará al PO a tener un backlog priorizado impidiendo que el equipo "invierta/gaste" tiempo en funcionalidades innecesarias o no críticas para el negocio. Es de aclarar que esta responsabilidad del Backlog priorizado es del PO, pero el SM y el Equipo ayudan a que no se pierda el foco. Esto se logra con una buena visión compartida y a medida que el Equipo se siente en confianza con el PO.[7]
- [Falla / Fail] Sprints de más de 1 mes: Es casi un estándar trabajar sprint de 2 a lo máximo 3 semanas, pensar en un mes es demasiado tiempo y va en contravía del lema "si hemos de fallar que sea rápido". Un mes es mucho tiempo, pasan muchas cosas y la capacidad de inspección y adaptación es más baja[7]
Respecto a los roles
- [Falla / Fail] Creer que la Certificación de Scrum Master (SM) resuelve todos los problemas: Scrum no se domina con dos días de curso y el examen de certificación de Scrum Master.[1]. Es necesario estudiar, fallar rápido, adaptarse, y reconocer que estamos en continuo aprendizaje y mejora. Siga las reglas al pie de la letra de las biblias de Scrum y luego adapte, antes no.[7]
- [Falla / Fail] Desconfíe del equipo[2], no le permita sentirse responsable del producto a entregar.[7]
- [Falla / Fail] El PO (Product Owner) no comunica la visión al equipo [2].
- [Falla / Fail] El PO no presta atención al progreso en cada iteración y no evalúa objetivamente el valor alcanzado [2].
- [Falla / Fail] El PO no tiene un documento donde esta planeado el producto y lo reemplaza por algo que tan solo esta en la cabeza de él [2]. Es necesario un plan de releases, saber hacia donde van las siguientes versiones del producto, para esto sirve mucho el user story mapping.[7].
- [Falla / Fail] El rol de PO y el SM son ejecutados por la misma persona[2].
- [Falla / Fail] Una persona tiene más de dos roles. Esto a lo sumo debe ocurrir que el rol de SM lo asuma un desarrollador, y esto es cuando un equipo es demasiado maduro y realmente es autogestionado [7].
- [Falla / Fail] El SM no frena al PO, y permite que desenfoque a cualquier miembro del equipo deliberadamente y constantemente.[7].
- [Falla / Fail] El PO no este disponible para resolver las dudas del equipo.[7].
- [Falla / Fail] El equipo se "jure" autogestionado sin serlo. He visto equipos que juran y perjuran que por el hecho de entender scrum, no necesitan de SM. Esto es una falla en un inicio de adopción de Scrum, el Scrum Master no es un rol que se puede desechar, ni esta inventado para dar trabajo a los que no encajan en el equipo. Un equipo será autogestionado cuando este inspirado en la mejora continua, su liderazgo técnico y calidad humana de forma que logre niveles altos de competitividad y rentabilidad. Estos altos estándares con seguridad eso no se logran en las primeras ejecuciones del framework. [7].
- [Falla / Fail] Creer que el equipo de Scrum solo es el SM y el Team Developer. Falso, el equipo de Scrum es el PO, el SM y el Team developer, todos ellos son conocidos como roles cerdo, o comprometidos con el producto y proyecto.[7]
Respecto a la ingeniería
- [Falla / Fail] Tener deuda técnica: La deuda técnica hace que las pruebas se demoren demasiado tiempo y no se cumplan los compromisos.[1].
- [Falla / Fail] Tener deuda técnica: La deuda técnica disminuirá la velocidad en el mediano plazo y afectará el soporte y mantenimiento del producto (además que hablará muy mal del equipo que implemento el producto inicial).[7].
- [Falla / Fail] No tener prácticas técnicas: Sin prácticas técnicas de ingeniería la calidad disminuye asintóticamente con el tiempo. [1]
- [Éxito / Sucess] Tener prácticas técnicas: Las prácticas técnicas se pagan a si mismas.[1]
- [Falla / Fail] Crea que lo más importante es la cantidad de funcionalidades y de trabajo realizado, dejando de lado el valor de negocio, el riesgo y la creación de conocimiento [2]
- [Éxito / Sucess] "Pero si trabajas en un proyecto medio o grande, si quieres asegurarte el terminar vivo, necesitas (entre otros muchos, la siguiente es solo un ejemplo):
- Control de versiones y gestión de la configuración.
- Gestión de riesgos.
- Asegurar la calidad del producto software.
- Pruebas: carga, unitarias, integración, etc. Que no te van a funcionar si no tienes…
- Una buena arquitectura y un buen diseño.
- Trazabilidad, control de incidencias y problemas, etc."[3]
Es posible encontrar más fallas en las ceremonias de scrum, los roles y los artefactos, pero estos son los que más he encontrado en la literatura hasta ahora leída y los que he vivido como Scrum Master y como Coach de equipos de Scrum.
Queda abierto el debate, como siempre....
Bienvenida la retroalimentación
-------------------------------------
JORGE HERNÁN ABAD LONDOÑO
