Algunas frases y reflexiones de cómo fallar en Scrum y Agile

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

MSc. Ingeniería Informática - Universidad Eafit

ScrumAlliance Certified Scrum Master member 000260715

Fuentes:

• [1] Shore, James. The Decline and Fall of Agile. http://www.jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
• [2] Conh, Mike. How To Fail With Agile: Twenty Tips to Help You Avoid Success. http://www.mountaingoatsoftware.com/articles/how-to-fail-with-agile 
• [3] Garzas, Javer. Lo siento mucho, pero sólo con Scrum… no vas a terminar un desarrollo software con éxito. http://www.javiergarzas.com/2012/07/scrum-solo.html 
• [4]Brad, Dave and Swanson,Sharrock. Agile Transformation Failure Modes and Success Modes. http://www.agile42.com/en/blog/2013/06/06/agile-transformation-failure-success/ 
• [5] Gärtner, Markus. Scrum Norris. http://www.shino.de/2010/02/20/scrum-norris/ | http://www.genbetadev.com/metodologias-de-programacion/scrum-norris-es-scrummaster-sin-haber-sido-certificado
• [6] Cyment, Alan. El espíritu de Scrum,  El arte de amar los lunes. V0.2 - http://es.scribd.com/doc/84799747/El-espiritu-de-Scrum
• [7] Mi opinión y experiencia personal.

Características de una buena historia de usuario

Nivel del post: Básico

Este es mi lista de verificación al momento de revisar una historia de usuario.

Luego de hacer la CCC (Card, Confirmation, Conversation), definitivamente el criterio más importante que uso es cumplir INVEST:

• Independiente: No requiere de otra
• Negociable: Se puede reemplazar por otra de diferentes prioridad
• Valor: Que sea necesaria y de valor para el proyecto
• Estimable: Que el equipo se sienta tranquilo y seguro estimandola.
• Small (pequeñas): que no sean grande, funcionalidades pequeñas
• Testeable (verificable): que se le puedan realizar pruebas.

Yo añadiría, aclararía y uso los siguientes:

• que su tamaño no supere los 3 a 4 días de una persona enfocada desarrollándola. (Asociado al criterio de Small). Obvio hay excepciones pero al máximo trato que durante un planning no se supere este criterio.
• Razón: He observado que historias mas grandes quedan mal estimadas por mas buena intención que tenga el equipo de desarrollo, el equipo se siente seguro con este tamaño de historia. Determine cual es el rango para su equipo.
• que su implementación toque todas las capas o que el resultado de su implementación tenga sentido para el Product Owner o al Cliente. Me explico, en caso de hacer desarrollos asociados exclusivamente a la Base de Datos o a temas complejos por ejemplo que no logran verse reflejados facilmente por el product owner, sugiero crear historias técnicas en las cuales se le explique al Product Owner el valor asociado a las mismas en el proyecto. (Asociado al criterio de Valor).
• Razón: Evito al máximo historias técnicas pues son de difícil justificación - aunque no imposible, pues si son necesarias se hacen -, pero la razón principal es que este tipo de historias habilita el crecimiento orgánico.
• que tenga a lo sumo entre 3 y 7 criterios de aceptación.(Asociado a los criterios de Small, Testeable y Estimable).
• Razón: Más de 7 criterios, se puede  dividir la historia, menos de 3 se puede agrupar con otra.
• que se pueda dividir cuando sea muy grande (Asociado a los criterios de Small, Testeable y Estimable).
• Razón: La gran mayoría de las historias grandes se pueden dividir, esto permite más maniobrabilidad al equipo al momento de implementación.
• preguntar lo más que se pueda sobre la necesidad de la historia de usuario  (Asociado al criterio de Valor). 
• Razón: Después de varios sprints y coach que me han hecho, he aprendido a preguntar para ciertas historias que percibo innecesarias (validaciones de negocio excesivas, autocompletar recargados, etc):
•  ¿ok es de valor, pero es necesaria?
• ¿cuántas personas la usarán?
• ¿cuántas veces la usarán en el año?
• ¿es realmente útil? 
• ¿prefieres al equipo trabajando en esa "validación xxxx "-por poner un ejemplo-  que en esta otra historia de usuario que agrega más valor al negocio?
• ¿podemos postergar esto para el final y hacer otra cosa más urgente sobre la que tenemos clara la necesidad de implementación? (principio de LEAN - aplazar las decisiones, ver más aquí)

Respecto al Sprint

• Busco siempre trabajar con  al menos hayan 6 historias de usuario por sprint. 
• Razón: De esta forma el equipo tiene en que trabajar, con pocas historias de usuario se estarán obstaculizando entre sí.
• Trabajo junto con el Product Owner para que existan al menos otras 6 historias adicionales 
• Razón: Tener backlog para posibles reemplazos y/o negociaciones.
• Trabajo junto con el Product Owner para que se tengan definidos al menos historias de usuario al detalle para los próximos 2 Sprints (completamente elaboradas, cumpliendo INVEST) y un 3er sprint con Historias de Usuario  sin mucho detalle.
• Razón: Tener claro hacia donde va el producto.
• La evolución del producto esta guiada por el User Story Mapping (ver más aquí)el cual tiene los objetivos de cada Release y las historias épicas que contendrá.
• Razón: Tener claro hacia donde va el producto y saber cuan cerca estamos de hacer una liberación o release.

Si estás interesado en ver  recomendaciones para el Product Backlog ver - http://www.pmoinformatica.com/2013/07/11-reglas-product-backlog-scrum.html



-------------------------------------
JORGE HERNÁN ABAD LONDOÑO

MSc. Ingeniería Informática - Universidad Eafit

ScrumAlliance Certified Scrum Master member 000260715

Jorge Valderrama -Ingeniero Senior de DDB Tribal Londres - Hablando de Metodologías Ágiles

Les recomiendo esta excelente entrevista realizada por César Torres Gerente Comercial de Ceiba Software - www.ceiba.co a Jorge Valderrama ( @jvalde ) , Ingeniero Senior de DDB Tribal Londres desde hace 5 años. Entrevista en la que cuenta su experiencia en Prácticas Ágiles, las prácticas que no pueden faltar en un equipo, las prácticas más complejas de adoptar y la Madurez de la industria inglesa en términos de contratar con alcance abierto.