Serie: Lesa Agilidad

-Mucho gusto soy el Product Owner

-¿Y vas a estar con el equipo?

- No, ya escribí todas las hu, solo vendré a los review a recibir el producto y ver el progreso

FORO ERRORES COMETIDOS: C*GADAS EN AGILIDAD Y LECCIONES APRENDIDAS

Fail - Contratar el MVP con Alcance, Tiempo y Costo Fijo

Cada vez me encuentro más con empresas que dicen:

"Ok entendí qué es un #MVP, entonces constrúyanlo con un contrato a alcance, tiempo y costo fijo"

Predecir alcance, tiempo y costo en escenarios de #VUCA es imposible.

---

¿Que modelo recomiendo usar ?

Para todo tipo de proyecto o producto de desarrollo de software recomiendo, en primer lugar no ceder frente a las presiones del cliente (no es profesional, y realmente a el no le conviene aunque así lo crea), luego de ahí hacer cualquiera de los siguientes contratos:

1. Tiempo y materiales
2. Tiempo y materiales con tiempo fijo
3. Tiempo y materiales con costo fijo
y por último
4. Estimación por sprint o estimación por trabajo mensual (implica bajo riesgo con orden de trabajo mensual)
5. Tiempo y materiales con alcance fijo (no recomiendo pues implica levantamiento y perdemos flexibilidad... cosa que nos brinda el enfoque agile)
¿y ustedes que han hecho en estos casos? ¿que recomiendan?

Presentación: Las Cinco Disfunciones de los Equipos y el Miembro de Equipo Ideal

Las Cinco Disfunciones del Equipo y el Miembro de Equipo Ideal from Jorge Hernán Abad Londoño

[Scrum] Una queja común en algunos Scrum Masters: Mi Product Owner no es bueno

Hola a todos

En sesiones de mejora con Scrum Masters (SM) con frecuencia me encuentro con las siguientes quejas acerca del Product Owner (PO):

• no tiene tiempo para el equipo
• no escribe bien las historias de usuario 
• no está priorizando el product backlog
• no hay un plan de releases
• no se tiene un Producto Mínimo Viable (MVP).
• no se tiene una herramienta de seguimiento de releases como un Burn Up Release (por ejemplo)
• entre otras preocupaciones

Es allí donde les solicito que me compartan que saben del rol del Scrum Master y me responden palabras más palabras menos, lo que que está a continuación (-que se interpreta en la guía oficial de Scrum- ):

Luego de esto, comienzo una ronda de preguntas y respuestas de más o menos este estilo:

• ¿Quién es responsable de que se tengan buenas historias de usuario, el P.O., el Team o el SM? 
• Rpta/. Es el SM como experto del marco es el encargado de garantizar que el equipo tenga los ítems de backlog adecuados para trabajar, y es su deber como coach del PO de enseñarle y verificar las historias de usuario para que estas cumplan con un estándar mínimo de calidad (las tres CCC e INVEST). ( leer tambiém :El Product Owner "NO" Necesariamente Escribe las Historias de Usuario o Ítems de Backlog - clic aquí)
• ¿Quién es el responsable de que no se tenga un buen Product Backlog, Plan de Releases, Producto Mínimo Viable (MVP), un Burn Up Release?
• Rpta/. Pareciera que inicialmente es el PO, pero similar al punto anterior, el SM como coach del PO debe enseñarle y ayudarle a mantener los artefactos de scrum, hasta que estos sean los adecuados para construir un producto exitoso.
• ¿y que podríamos hacer con respecto a la falta de tiempo del PO?
• Rpta./. El SM debe buscar como lograr más tiempo de la organización para el PO - al menos medio tiempo-, o encontar la forma de que esto se resuelva con otro PO, o un PO Proxy, pero recordemos que el SM es un agente de cambio para la organización y es responsable de que la organización comprenda como funciona Scrum y los requisitos para que sea exitoso.

Es importante comprender que el Scrum Master es el responsable de Framework de Scrum, debe trabajar por su funcionamiento exitoso, que debe convertirse en Responsable en vez de Víctima,  haciendo que las cosas pasen, si su PO, equipo o algo no funciona pues debe moverse para que las cosas sucedan.

Hasta acá este corto compartir

Saludos ágiles

Jorge Abad

Un tweet de un grande - R.I.P. Mike Beedle - Ágil no Cura la Incompetencia

✅ Agile doesn’t cure INCOMPETENCE.

You can coach teams to be more engaged and collaborative, but NO Agile framework, method, or mindset can save you from BLATANT FAILURE if your development team is INCOMPETENT in basic engineering practices.

Technical excellence is a MUST!

— Mike Beedle (@mikebeedle) March 21, 2018

Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones

Hola a todos

En el medio, cuando hablamos con otros agilistas sobre la forma que las organizaciones están abordando la contratación de proyectos ágiles nos encontramos con RFP (Request For Proposal - Solicitudes de Propuesta) donde existen cláusulas, penalidades y ANS (acuerdos de niveles de servicio) como:

• El equipo deberá mejorar un 1% cada sprint su velocidad 
• Ganará el RFP el proveedor que proponga el menor tamaño de sprint 
• Ganará el RFP  el proveedor que proponga menos sprints
• Ganará el RFP el que haga historias de usuario en menos tiempo

Lo cierto es que venimos acostumbrados a penalizaciones y a la desconfianza de cascada, (-obvio nadie salía ganando, el producto no era el esperado, al igual que la fecha y el costo no se cumplían, es un caos por donde se mire -), en donde se generaban clausulas como:

• deberá reducir el porcentaje de defectos proporcionalmente en sus requerimientos
• por día de demora en la fecha de entrega deberá pagar $/día (y he visto proyectos donde la suma de la penalidad es tal que el proyecto termina valiendo cero pesos)
• Por cada error en producción se descontará $xx.xxx.xxx
• entre muchas otras cosas igual o peor de dolorosas donde el proveedor se acomodaba (cobrando más costoso - en el mejor de los casos-, o más barato) pues le interesaba conservar el cliente.(ver este post ¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu - clic aquí)

Por lo tanto, es probable que quien este al frente de contrataciones de proyectos ágiles

• Esté mal asesorado
• No tiene conocimiento o entendimiento de ágil -no tiene que tenerlo, en algún momento yo no lo tuve- y en su buena voluntad cree que poniendo restricciones similares a la de cascada podrá "controlar" el proyecto (cosa que tampoco ocurría en cascada - pero que será artículo de otro post- ).

Lo que se observa en este caso es que se esta tratando de resolver un problema nuevo bajo un paradigma mental anterior y que no aplica para este nuevo contexto, y es allí donde se requiere de buen acompañamiento.

Dado lo anterior, cuales serían mis observaciones al clausulado del principio del artículo.

Clausula o ANS propuesto Observaciones el equipo deberá mejorar un 1% cada sprint su velocidad  Implica que la mejora un año deberá mejorar 48% (y eso que no apliqué la formula del interés compuesto) más de alcance al final del año si consideramos sprints de dos semanas(y en dos años del 96%). esto es insostenible, Lo que va a lograr es que las historias de usuario cada vez le pongan más tamaño. (obtienes lo que mides) O si se le hace auditoría las estimaciones de las historias de usuario (que es lo que menos valor genera, auditar estimaciones) terminará agotando al proveedor y dejará de ser negocio para el proveedor continuar con ese cliente pues no es rentable, ni demostrable ese ritmo sostenido de mejora. Ganará el RFP el proveedor que proponga el menor tamaño de Sprint El tamaño del sprint no implica absolutamente nada, se recomienda 2 semanas, equipos con mucha experiencia tienen sprints de 1 semana, y otros trabajan con kanban, pero es el contexto el que da el tamaño del sprint. Es mu probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas partes que ágil no sirve. Ganará el RFP  el proveedor que proponga menos sprints Es una orientación puramente hacia cascada y creer que se puede definir el alcance a priori en agile (aun en cascada) es falso.  Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve Ganará el RFP el que haga historias de usuario en menos tiempo Las historias de usuario son irregulares, aunque se puede hacer partición de ellas no es posible garantizar un tamaño, y aunque se desarrolle más rápido algunas no es garantía de que todas van a ser así. Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve

¿Cómo resolver esto?

• Opción 1: Prueba de Concepto

Una posible forma de saber con que proveedor quedarse es darle la oportunidad de ejecutarun proyecto en ágil , que ejecute varios sprints (2, 3, o 4 sprints)y si:

• tiene buen manejo de la metodología
• si equipo esta preparado y experimentado
• tiene gestión de la deuda técnica
• tiene prácticas técnicas
• su scrum master es preparado y con experiencia
• entregan software funcionando cada dos semanas

Continuar con el, sino detenerse y entregarle el proyecto otro proveedor.

¿Pero perdiste como cliente? No, ganaste conocimiento y al menos quedaste con software funcionando (cosa que no quedaba en cascada).

• Opción 2: Referencias

Otra opción es visitar referencias de clientes de ese proveedor y validar con un experto en ágil las experiencias y aplique las mismas condiciones de la opción 1, sino funciona terminar el contrato.

Lecturas Recomendadas

Recomiendo para la mejor comprensión y ayuda estos dos post

• Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.(parte 2) -clic aquí- 
• Hablemos sobre Contratos Ágiles - clic aquí -

Bienvenido el feedback

Saludos ágiles
Jorge Abad

Las métricas en contra del sistema

Cualquier parecido con la coincidencia es pura realidad
(un poco de catarsis)#Agile #Scrum #Fail pic.twitter.com/sccV5GEpSA

— Jorge Hernán Abad L. (@jorge_abad) January 24, 2018

Errores de "Lesa Agilidad"

Hola a todos

Les comparto unos tweets y pensamientos sobre como fallamos al agilismo #LesaAgilidad

un abrazo

--

Error de Lesa Agilidad: "Voy a quedarme trabajando hasta las diez de la noche y también en el fin de semana para poder terminar todo"

— Ricardo Colusso (@rcolusso) septiembre 5, 2015

@jorge_abad @rcolusso @IngridAstiz yo siempre recomiendo a "quienes no tienen tiempo" de hacer una retrospectiva, ¡que hagan dos!

— Lucho Salazar (@luchosalazarc) septiembre 5, 2015

También"hacemos reuniones de sincronización de equipo (daily o stand-up meetings) sólo cuando podemos estar todos presentes" #LesaAgilidad

— Ricardo Colusso (@rcolusso) septiembre 5, 2015

@rcolusso @IngridAstiz @luchosalazarc #LesaAgilidad cuando inflo mis estimaciones en el planning para trabajar con "muy buena holgura"

— Jorge Hernán Abad L. (@jorge_abad) septiembre 5, 2015

@jorge_abad @rcolusso @luchosalazarc ejem... estoy trabajando fin de semana con la ilusión de poder terminar "todo"... ejem...

— Ingrid Astiz (@IngridAstiz) septiembre 5, 2015

#LesaAgilidad Cuando salgo antes del horario de oficina sin importarme el compromiso del sprint por que soy "autogestionado" @rcolusso

— Jorge Hernán Abad L. (@jorge_abad) septiembre 5, 2015

Una de las claves de Scrum : Fail Fast - Fallar Rápido

Hola a todos...

Cada vez que tengo una retrospectiva con los equipos en los que soy Scrum Master, vivo, comprendo y profundizo más en el concepto del:

Fail Fast

Fallar Rápido

Pues noto que los ciclos cortos de inspección y adaptación, de retroalimentación (Sprints de 2 a 4 semanas), habilitan y potencializan el PHVA - Planear Hacer Verificar y Actuar - (PDCA - Plan Do Check Act - en inglés) y la mejora continua del ciclo de Deming de una manera sorprendente.

Miremos a Scrum [1] desde esta óptica del PHVA:

• P - Planear = Sprint Planning
• H - Hacer = Ejecución del Sprint (tiempo que transcurre entre el fin del planning y la review)
• V - Verificar = Reunión de Review (se identifica si se cumplió o no con lo comprometido, con su respectivo criterio de DONE / HECHO/ REALIZADO)
• A - Actuar = Retrospectiva, encontrar en cualquiera de los pilares de scrum (Producto, Procesos, Equipo):
• qué se está haciendo bien, para continuar haciéndolo
• qué se esta haciendo mal, no tan bien, o se puede mejorar para desecharlo, mejorarlo (kaizen) y/o corregirlo.

Adicionalmente, el hecho de tener que cerrar el ciclo, obliga a parar y presentar el producto en el estado en que se encuentre para el Review, logrando que el Equipo Scrum (Product Owner, Scrum Master y Equipo de desarrollo) aprenda sobre:

• el cumplimiento de los compromisos adquiridos
• la transparencia y
• la efectividad de los cambios y mejoras realizadas (ya sea al Producto, Proceso y/o Equipo) y propuestas en el sprint pasado.

Por lo tanto, tener ciclos de construcción de producto cortos hace que el ejercicio de Scrum lleve al Equipo Scrum a fallar rápido y de forma frecuente permitiendo que se encuentre prontamente con las mejoras que impulsarán a todos a tener victorias tempranas y lograr el éxito en el producto que se está construyendo,

El fallar rápido permite al Equipo Scrum a:

• encontrar los errores pronto
• aprender de estos errores pronto y no permitir que te acostumbres a ellos
• realizar un proceso de mejora exploratorio, basado en:
• encontrar las mejoras a realizar, 
• proponer las mejoras como hipótesis, 
• priorizar las mejoras a realizar 
• construirlas como historias de usuario técnicas, con criterios de aceptación
• intentar pocas mejoras, en vez de muchas (recomiendo a lo sumo 3, pero obvio existiran particularidades y escenarios en que sean más o menos) 
• poner estas mejoras como lo primero del sprint backlog [5]
• ejecutarlas en el próximo sprint,
• validarlas y adoptarlas o desecharlas
• comenzar un nuevo ciclo identificando elementos a mantener, nuevas fallas y nuevas mejoras

Nota: Es responsabilidad del Scrum Master ser habilitador de esta mejora continua, aunque es importante aclarar que en un equipo Scrum, la mejora viene de cualquier miembro del equipo (o de los stakeholders), y esta mejora aparecerá tanto en la retrospectiva como en el día a día del sprint.

Este ciclo exitoso de continuo PHVA retroalimentado, es lo que ayuda a que en cada Sprint se identifiquen mejoras simples y sorprendentes de los componentes de Scrum de una manera natural, estimulante e intuitiva, permitiendo la evolución (mejora continua) rápida de Producto, Proceso y/o Equipo.

Recuerdo bien el espíritu de una frase (no recuerdo ni la frase exacta, ni el autor):

Te perdono que falles, lo que no te perdono es que no aprendas

Hasta acá mi reflexión, no quiero ahondar más en el tema, pues pienso que otros lo han hecho mejor que yo. por lo tanto, a continuación copio varios artículos[6], e imágenes que explican mejor este punto de vista.

Saludos ágiles

Jorge Abad.

Referencias

[1] Guía de Scrum - https://www.scrum.org/Scrum-Guides
[2] Mi evolución sobre las retrospectivas en Scrum - http://lecciones-aprendidas.blogspot.com/2013/04/mi-evolucion-sobre-las-retrospectivas.html
[3] Fail often, fail well -http://www.economist.com/node/18557776?story_id=18557776&utm_source=buffer&utm_campaign=Buffer&utm_content=bufferb5099&utm_medium=twitter
[4] Cómo es un día en pixar, según su director dearte -  http://www.enter.co/#!/eventos/campusparty/2013/jay-shuster-narro-en-cpco6-como-es-un-dia-en-pixar-animation-studios/
[5] Seis (6) estrategias de lograr mayor velocidad de los equipos en Scrum - http://lecciones-aprendidas.blogspot.com/2013/08/seis-6-formas-de-lograr-mayor-velocidad.html
[6] En el link ▼ a continuación  se encuentran las referencias citadas.

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.