Presentación: Las Seis Cosas que no Debe Hacer un Scrum Master

Presentation: The six (6) things a #ProductOwner should never do

Presentación: Las Seis (6) Cosas que no Debe Hacer un Product Owner

Podcast - Hormigas Agilistas - EP102 — Antipatrones de OKRs con Cristhian Arias Venturo

Video: Antipatrones (malas prácticas) en priorización de Product Owners, PMO y VMO

---- Enlace al Póster ----

___

10 Anti-patterns (bad practices) in prioritization of Product Owners, PMO and VMO

Hello everyone

One of the factors that most destroys agility is the lack of adequate prioritization patterns according to the context in which it is located, that is, both upstream (1) and downstream (2) practices are used (which even from the good intention) destroy value for the organization. In general, we can incur:

• Building unnecessary things
• Building things that are necessary but worthless
• You don't build what's important
• We let ourselves be carried away by intuition
• We let ourselves be carried away by authority
• We let ourselves be carried away by feelings of friendship or enmity
• etc.

We destroy value and generate waste by dedicating time, effort and money from business areas, execution areas and suppliers in things that should not have been developed and relegating others, which would allow better financial performance or customer satisfaction.

---

---

---

(and one of mine)

"Building something that was not correctly prioritized is destroying value for the organization"

---

Below, I share some of the anti-patterns that I have observed when prioritizing both PMO - Project Management Office -, VMO -Value Management Office- and Product owners, and that I promote to be removed in processes of agile transformation or team agile coaching.  

I hope they will help you advance in the knowledge of better ways to prioritize the work to be done.

Expect more articles on this topic.

Agile greetings,

Jorge Abad.

 

References, notes, or comments

1. Upstream: where the project, product or initiative is prioritized by the PMO, VMO or those who are responsible for prioritizing the portfolio.
2. Downstream: where the product is being developed, and the solution team builds the different functionalities.

De Colección: 10 Antipatrones (malas prácticas) en priorización de Product Owners, PMO y VMO

Hola a todos,

Uno de los factores que más destruye la agilidad es la carencia de patrones adecuados de priorización de acuerdo con el contexto en el que se encuentre, es decir, tanto aguas arriba (upstream) (1) como aguas abajo (downstream) (2) se emplean prácticas (que aun desde la buena intención) destruyen valor para la organización. En general podemos incurrir en:

• construir cosas innecesarias
• construir cosas necesarias pero carentes de valor
• no se construye lo realmente importante
• nos dejamos llevar por la intuición
• nos dejamos llevar por la autoridad
• nos dejamos llevar por los sentimientos de amistad o enemistad
• etc.

En últimas, destruimos valor y hacemos que se genere desperdicio por dedicar tiempo, esfuerzo y dinero de áreas de negocio, áreas de ejecución y proveedores en cosas que no debían haber sido elaboradas y relegando otras, que permitirían un mejor desempeño financiero o de satisfacción del cliente.

---

---

(y una mía)

"Construir algo que no fue correctamente priorizado es destruir valor para la organización"

---

A continuación, te comparto algunos de los antipatrones que he observado al momento de priorizar tanto por PMO - Project Management Office -, VMO -Value Management Office- y Product owners, y que promuevo sean removidos en procesos de transformación ágil organizacional o de acompañamiento de equipos.

Espero te sirvan para avanzar en el conocimiento de mejores formas de priorizar el trabajo a realizar.

Espera más artículos sobre este tema.

Saludos ágiles,

Jorge Abad.

--- Ver video explicativo aquí ---

Referencias, notas o comentarios

1. Upstream: donde se prioriza el proyecto, producto o iniciativa por parte de la PMO, VMO o quienes se encargan de priorizar el portafolio.
2. Downstream: donde se está desarrollando el producto, y los equipos de solucionadores a construyen las diferentes funcionalidades.

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

La estamos c*g*ndo con Scrum

La estamos c_g_ndo con scrum from Jorge Hernán Abad Londoño

Referencias

1. tamaño ideal de equipo entre 5 y 6 personas:

• http://www.intuitor.com/statistics/SmallGroups.html }
• https://medium.com/simply-agile/agile-leader-pattern-3-for-building-awesome-teams-small-is-big-7ce51ce4ac4b

Agile Apesta | Ágil Apesta | Agile Sucks

¡Que bueno, atrapé tu atención! Al parecer varios estudios han demostrado nuestra preferencia por las noticias malas y todo aquello escrito en tono negativo es fuente de observación inmediata de nuestra mente, ya sea por instinto de supervivencia o por morbo, es una de las razones por las cuales las redes sociales y los periódicos tienden a volverse más tóxicos -les recomiendo ver las referencias (1)-.

Quiero aprovechar este comportamiento que todos poseemos para compartirte que Agile Apesta o Ágil Apesta o Agile Sucks bajo muchas circunstancias endógenas y exógenas, pues se volvió un objeto de deseo, mas eso no implica que se esté haciendo bien, se asemeja más a un jabón resbaloso que solo se deja atrapar junto a la esquina de la ducha, que a un concepto claramente entendido y dominado por todos.

Ágil según la propuesta de Alistair Cockburn (uno de los firmantes del Manifiesto Ágil) podría resumirse en 4 pilares (que él denomina el Corazon de Ágil - https://heartofagile.com ), todos trabajando a la vez, ninguno más importante que otro, complementándose y ayudándose:

• Entrega de Valor (entiéndase como lo que el cliente quiere y con calidad)
• Reflexión (Inspección y Adaptación)
• Mejora Continua
• Colaboración

Corazón de Ágil por Alistair Cockburn (2)

Cuando alguno de estos elementos falta o está mal concebido, lo que llamamos ágil, apesta y generará más problemas que soluciones.

A continuación te comparto un breve listado que he identificado cuándo Ágil Apesta y mucho.

Ágil apesta cuando:

• Exógenas a los equipos ágiles
• cuando es contratado con alcance tiempo y costo fijo (clic aquí)
• la PMO hace seguimiento tradicional a un enfoque ágil 
• a la empresa no le gusta la transparencia y "mata" al mensajero que trae las malas noticias, de que las cosas no funcionan
• la empresa dice que no necesita acompañamiento y cree que con dos días de entrenamiento de sus gerentes de proyecto es suficiente
• la empresa cree que es solo ponerle a los Gerentes de proyecto el rol de Scrum Masters, y a los Business Analyst el rol de Product Owners.
• la empresa cree que será ágil en 3 meses y exige un plan para hacerlo 
• cuando la alta dirección no está involucrada y delega el cambio 
• a las personas les siguen diciendo recursos 
• no se exige excelencia técnica, ni internamente ni a proveedores
• no se remueve la deuda técnica.
• tenemos a los equipos bajo presión y les imponemos lo que deben entregar y cuándo deben hacerlo 
• cuando creemos que sabemos más que el Agile Coach o el Scrum Master con experiencia y no se siguen sus recomendaciones
• cuando no dejamos madurar los pilotos ágiles (al parecer 6 meses es una buena métrica para empezar)
• Cuando mi jefe dice que es ágil pero no le puedo dar feedback, ni le puedo sugerir cosas.
• Endógenas a equipos ágiles
• no se entrega valor al cliente de forma temprana y continua
• no existe excelencia técnica 
• el alcance está fijo 
• no se reflexiona, es decir, no se hace inspección y adaptación.
• cuando tienes soluciones ahogadas en deuda técnica
• cuando no usas DevOps
• cuando la mejora continua se enfoca únicamente en los procesos y las personas y no se enfoca en resolver los problemas técnicos (clic aquí)
• Endógenas a Scrum 
• el 50% de los equipos Scrum apestan (se lo vi decir a Jeff Sutherland, pues no son capaces de generar valor y de lograr un desempeño del 400% - promesa cumplida por Scrum una y otra vez) 
• las historias de usuario demoran dos o más sprints en ser construidas y nos olvidamos que a lo sumo deben tomarnos entre 2 a 4 días en construirse totalmente, es decir, con pruebas y despliegue incluido.
• se tienen Scrum Masters (SM) con 3 equipos (lo mejor, es un SM por equipo, lo menos peor es un SM con 2 equipos, la pésima práctica un SM con 3 o más equipos, pues no alcanza a mejorar nada, solo corre de un lado para otro haciendo reuniones) 
• se tienen Product Owners con 2 equipos (la verdad, debería ser a lo sumo uno solo, 2 es demasiado riesgoso, y le resta foco en el producto que construye) 
• el SM solo se dedica a agendar reuniones 
• cuando el PO no va a los eventos
•  el PO no hace refinamiento y se convierte en un PO reactivo que solo trabaja para el siguiente sprint, debiendo estar avanzando en 2 a 3 sprints adelante
• el SM no enseña Scrum al PO o al Equipo y como hacerlo cada vez mejor
• el PO no se deja enseñar por el SM
• cuando creemos que 5 sprints mejorarán técnicamente a un equipo de inexpertos (nunca pasará)
• no hay retrospectivas, porque no agregan valor
• las retrospectivas no abordan temas técnicos (clic aquí)
• no hay dailys 
• no hay planning, solo trabajo impuesto a realizar por el equipo de forma cíclica
• tienes un equipo con varios proyectos (multitasking) y lo llamas equipo 
• existen equipos que los llaman células y son unicelulares (equipos de una persona - OMG, lo he visto varias veces)
• las pruebas son hechas por otro equipo diferente al que construye el producto, y en el sprint subsiguiente (casca-agile)
• el equipo no es multidisciplinario 
• el Product Backlog no está priorizado por valor 
• existe un product Backlog con un solo release y un MVP, o sea, sino se sale a producción con todo el sistema o producto, este no sirve 
• el PO no tiene autoridad sobre el producto 
• el PO es el jefe del equipo y no se le puede dar feedback 
• el SM es el jefe del equipo y no se le puede dar feedback 
• dentro del equipo hay subequipos 
• no existe incremento de valor potencialmente entregable al final de cada sprint
• dentro del equipo hay rangos y jerarquías (cosa que va en contra de la guía de Scrum)
• ni el SM, ni el PO, y el Team son orientados a resultados
• el SM no reta al equipo, ni le ayuda en su proceso de mejora continua
• no hay verdaderos profesionales haciendo parte del equipo Scrum
• En la comunidad ágil
• cuando los líderes de la propia comunidad lo atacan, en vez de avanzar de forma propositiva 
• cuando las conferencias se quedan sin feedback, y la falta de validación de expertos hace que se acepte todo, que todo valga, pero la verdad no todo vale, y algunas conferencias terminan perdiendo valor. 
• cuando dejamos que otros se hagan cargo, y solo caemos en el terreno de la crítica y no construimos responsablemente 
• cuando no vemos en la crítica de los otros una oportunidad de mejora 
• cuando dejamos que los líderes tóxicos prosperen y no compartimos los éxitos y las buenas prácticas
• cuando criticamos los eventos y los speakers, pero no vamos, ni nos proponemos como speakers
• cuando alguien que recibe un entrenamiento de 2 a 4 días es nombrado Master, Consultant, Coach y no hay validación de la práctica. 
• cuando quienes toman los entrenamientos creen que pueden dictarlo al día después 
• cuando como miembro un equipo ágil dejas de estudiar y aprender y buscar tu propia excelencia y reinvención.
• cuando no te conectas con la comunidad
• cuando es más importante la foto y llenar las redes sociales del entrenamiento, que la generacion de valor en el cliente y en el equipo
• cuando nos atacamos en vez de construir 
• cuando los que no entienden los marcos ágiles
• los critican sin conocerlos o haberlos usado
• cuando critican la forma (ej: los posit o dinámicas), pero no validan el fondo
• juzgan por las fotos, pero realmente no saben toda la movilización y cambios que están ocurriendo al interior del equipo o de la organización
• cuando los que creen entender los marcos ágiles
• empapelan de posit a la organización pero no generan valor 
• leen un libro o un post salen a vender entrenamientos sin entender, comprender y validar lo leído 
• instalan Jira pero no generan valor
• tienen un pipeline de DevOps pero el negocio no prioriza por valor, ni valida las hipótesis de los incrementos o releases que va lanzando al mercado, haciendo desperdicio ágil.
• confunden felicidad con esoterismo o chamanismo 
• confunden compromiso con explotación 
• comparten información que no está respaldada por datos o experiencias (al menos propias)
• ponen primero la felicidad que la generación de valor, el mensaje es diferente, los equipos felices o que tienen bienestar son más productivos.(https://hbr.org/2011/06/the-happiness-dividend) (aporte de Fabian Schwartz)
• comparten jubilosamente fracasos ágiles, pero no comparten el contexto y se les olvida que en cascada el factor de falla es mucho más alto. Pero para ser claros, es muy probable que dentro de las causa raíz de esos fracasos se encuentren algunos de los elementos enunciados en este post.  
• cuando cualquiera del ecosistema ágil, personas como usted o como yo, no elevamos o exigimos el estándar, no compartimos el riesgo o consecuencias de las malas implementaciones y somos complacientes con esas personas que desde su paradigma no lo entienden, o desde su esquema de poder no quieren que sea exitoso, y permitimos el FrAgile, Anti-frágil, FrÁgil, o Ágil Flácido.

Bien dice Sutherland, el peor enemigo de Scrum es un mal Scrum

Referencia (3)

parafraseánndolo un poco,

El peor enemigo de Ágil es un mal Ágil o si lo desean El peor enemigo de Agile es un mal Agile o también Agile's worst enemy is a bad Agile

Hagámonos cargo 

• No llamemos Ágil a lo que no lo es.
• No llamemos Scrum a lo que no lo es.
• Exijamos excelencia técnica de los equipos de desarrollo (tanto internos como de proveedores)
• Midamos y ataquemos la deuda técnica
• Si vamos a criticar un marco o framework ágil, hagámoslo desde la experiencia o desde el minucioso estudio.
• Valida lo que dice el autor, o entrenador que te acompaña, pídele datos y referencias.
• En las redes sociales no promuevas gente tóxica, por la razón que: "de vez en cuando dice algo bueno", pues terminarás aprobando su discurso tóxico, poco constructivo y poco empoderado.
• No confundas posición crítica, con una posición tóxica, la primera llama a la acción, la segunda destila veneno, señala lo malo y no propone acciones. 
• Hazte acompañar de expertos.
• Si vas a hacer Scrum al menos sigue la guía oficial de Scrum (el SBOK no es Scrum) 
• No caigas en el "borregismo", es decir, seguir a alguien sin objetar lo que dice (como borregos, o un cardúmen), todos erramos y todos tenemos oportunidades de mejora 
• Criticas porque otros critican, pero no compruebas nada de lo que afirman
• No te quedes con lo que te dicen, investiga, valida, busca datos
• Ten una actitud de continuo aprendizaje
• No seas complaciente con el FrAgile, Anti-frágil, FrÁgil, o Ágil Flácido, identifica disfunciones, corrígelas y exígelas.

Hasta acá este desahogo o diatriba.

Vamos juntos, vamos por más.

Bienvenidos sus comentarios y observaciones.

Saludos ágiles

Jorge Abad

Aclaraciones, Comentarios, Referencias y Notas 

1. links que apoyan esta afirmación
• Las noticias positivas están pidiendo primera plana
• Efecto de las malas noticias en el cerebro humano
• Consumer Demand for Cynical and Negative News Frames - Marc Trussler, Stuart Soroka, 2014
• ¿Por qué las malas noticias abundan más en los medios de comunicación?
• Psychology: Why bad news dominates the headlines
2. https://heartofagile.com/
3. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/

Dos Errores Comunes en las Historias de Usuario

Hola a todos

Aunque a través de varios escritos y post (1) he compartido que el formato de las historias de usuario es un formato libre,  pues

"cualquier modo de escribir o representar las Historias de Usuario sirve, siempre y cuando el Product Owner y el Equipo de Trabajo tengan la misma imagen mental de lo que se está requiriendo construir."

Pero, si un equipo se siente cómodo empleando la plantilla popularizada(2) por Mike Cohn,

Yo como _____ROL____ Deseo____UNA FUNCIONALIDAD___ Para_______BENEFICIO DE NEGOCIO__

La cual es ampliamente usada, ¡pues está bien!, ¡no hay lío con eso!.

Ahora, respecto a esta plantilla (la de Mike Cohn) quisiera compartirles dos errores frecuentes que he observado acompañando equipos de diferentes organizaciones:

El Primero, cuando se pone la historia de usuario en voz del Product Owner

Yo como _____PRODUCT OWNER____ Deseo____REGISTRAR LOS EGRESOS MENSUALES_   Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____

Y El Segundo, cuando ponemos la historia de usuario en voz del área funcional que la solicita

Yo como __VICEPRESIDENCIA FINANCIERA__ Deseo____REGISTRAR LOS EGRESOS MENSUALES____  Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____

La Forma Correcta es escribirla en voz de la persona que hace clic en el sistema, es decir, de quien usa la funcionalidad, que en este caso sería el SOLICITANTE DEL PRÉSTAMO, quedando la historia de usuario "bien escrita" de la siguiente forma:

Yo como _____SOLICITANTE DE PRÉSTAMO__  Deseo____REGISTRAR LOS EGRESOS MENSUALES____  Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____

Hasta acá este compartir

Saludos Ágiles
Jorge Abad

Referencias, Notas, Aclaraciones y Comentarios

1. Algunas referencias son:
• Libro de Historias de Usuario (clic aqui)
•  Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática - clic aquí
• [De Colección] Lo más importante de las historias de usuario no es el formato sino la esencia - Tweet de Colección
• Algunos Tweets Importantes sobre Historias de Usuario
2. La plantilla fue desarrollada por Rachel Davies en la compañía Connextra de Inglaterra, en 2001, pero luego la popularizó Mike Cohn junto a otros entusiastas del modelo.

Antipatrón: Solo liderar la primera línea y no gestionar la red

Hola a todos

Quisiera compartir uno de las disfunciones que he observado en la gestión de equipos y de las redes vinculadas a los mismos, convirtiéndose en uno de los obstáculos en los esfuerzos  de cambio cultural y de liderazgo hacia ambientes de más colaboración, adaptación al cambio, innovación, mejora continua, y generación de valor.

Utilizaré el esquema de antipatrón para compartirlo.

Antipatrón: El líder solo exige y promueve un alto estándar a su equipo y no gestiona la red  de personas y el ecosistema a cargo.

Problema: El líder solo gestiona su equipo adyacente exhibiendo y demandando valores de alto estándar pero no valida si su equipo y su entorno lo está haciendo, infiriendo o suponiendo que su equipo hará lo mismo con las personas a cargo.

Consecuencias:
existen varias consecuencias

• positivas: que todo su equipo exhiba y demande estos valores de alto estándar generando una cultura altamente positiva.
• negativas: 
• que parte de su equipo exhiba y comparta hacia la red un alto estándar de valores y otra parte del equipo no lo haga generando una cultura desigual y heterogénea
• que su equipo no exhiba los valores con los que son tratados y se generen resultados maltratando a las personas, con una cultura de presión, irrespeto y miedo.

Causas:

• Inocencia del líder
• Tolerancia del líder de cualquier estilo de liderazgo sin importar el trato que se le da a su red

Solución

En caso de que el líder este interesado en que su cultura de alto estándar se propague por el resto de su red se sugiere:

• no confiarse de evaluaciones 360
• realizar reuniones o conversatorios con cierta cadencia (mensual, bimestral o trimestral) con los equipos de la red para validar estilos de liderazgo

Se me vienen a la mente dos citas relacionadas con este tema:

"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar."- Gruenter and Whitaker, School Culture Rewired

"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar"- Jurgen Appelo

Con base en lo expuesto en este post se le podría precisar algo a ambas citas:

"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar en su equipo de trabajo y toda la red de personas a cargo"

----

"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar en su equipo de trabajo y toda la red de personas a cargo"

y como dice Deming:“Todos ya están haciendo lo mejor que pueden; los problemas están con el sistema ... solo el management puede cambiar el sistema", pero el sistema somos nosotros (1) y como nos relacionamos, ahí se encuentra la clave para generar el cambio o promover un alto estándar de cultura y valores.

Hasta acá este compartir, bienvenidos sus comentarios.

Saludos Ágiles

Jorge Abad

Referencia

1. De Colección: Culpamos el sistema, pero el sistema somos nosotros  http://www.lecciones-aprendidas.info/2019/07/culpamos-el-sistema-pero-el-sistema.html

Una versión de Casca-Agile(TM) o Casca-Scrum: tener "Sprint de desarrollo y luego Sprint de pruebas"

Hola a todos

Hace unos años en Ciudad de México dictando un entrenamiento de Scrum y Principios Ágiles, en el momento de hablar de malas prácticas, uno de los asistentes (y amigo mío Ulises Soriano), bautizaba como:

Casca-Agile (TM)

cuando se tomaban cosas del mundo ágil y del de cascada, pero con el pésimo resultado de que no se obtenía ni la "predictibilidad" añorada de cascada, ni la adaptabilidad de Scrum.

Esté termino lo he seguido usando desde ese entonces, y luego de tener la oportunidad de compartir con tantas organizaciones a nivel Latinoamérica he observado que hay una versión de Casca-Agile común a muchas empresas que no quieren adoptar la agilidad por completo: y es que contratan a un proveedor para que haga Scrum en el desarrollo del software y otro proveedor para que haga Scrum en las pruebas, olvidando lo que tanto se enuncia el marco Scrum en dos apartes:

"El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” que potencialmente se pueda poner en producción al final de cada Sprint. Un Incremento “Terminado” es obligatorio en la Revisión del Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento."(1)

"Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuentan con todas las habilidades necesarias para crear un Incremento de producto;"(1)

Esa versión de Casca-Agile o Casca-Scrum, termina viéndose así:

Añadiendo al menos 3 sprints (pueden ser más) entre el desarrollo de la historia de usuario y el lograr la "certificación"por parte de pruebas

Las desventajas que esto genera

• Largos tiempo de entrega del incremento (al menos tres sprints más)
• La imposibilidad de revisar el incremento completo cuando se termina cada sprint de desarrollo por parte del PO.
• Bajo involucramiento del PO
• La Definición de Terminado o "Definition of Done" toma mucho tiempo para que sea completamente alcanzada por ambos equipos
• la responsabilidad sobre el producto construido no existe.
• Gestion de ANS (acuerdos de niveles de servicio) que no agregan valor y desfiguran el marco de Scrum.
• El equipo de testing no esta sintiendo la construcción incremental del producto y por lo tanto no se sienten responsables del la buena construcción del mismo
• Esto no es Scrum y se aleja de la agilidad pues no cumple ni con la definción de Scrum, ni con los valores y principios del manifiesto ágil (2)
• A esto muchos se atreven a llamarlo Scrum, sabiendo que no lo es, o lo llaman "Scrum pero" (o ScrumBut (3)), y si no les funciona le echan la culpa a Scrum.

Las ventajas

• Le pienso y le pienso y no lo encuentro, puede que saboreen un poco las mieles del desarrollo iterativo e incremental, pero deja mucho que desear.

Solución a este antipatrón

La "falsa sensación de seguridad" de tener dos contratos, uno para el proveedor de desarrollo y otro para el proveedor de pruebas, se resuelve sentándolos juntos en una sola mesa y siendo ambos responsables de la calidad del producto entregado, cada sprint.

Cerrando

Bien parafrasean muchos a Jeff Sutherland,

"el peor enemigo de Scrum, es un mal Scrum" 

o mejor como él lo dice:

Referemcia(4)

Hasta acá este compartir, bienvenidos los comentarios y experiencias.

Saludos ágiles
Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. La Guía Oficial de Scrum - https://scrumguides.org/
2. Manifiesto por el Desarrollo Ágil de Software -https://agilemanifesto.org/iso/es/manifesto.html
3. Una excelente definición de ScrumBut - https://www.scrum.org/resources/what-scrumbut
4. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/
5. Si deseas ver más disfunciones de Scrum y de Ágil, haz clic aquí. http://www.lecciones-aprendidas.info/2019/04/malos-olores-en-transformaciones-agiles.html

Antipatrón de Scrum : El Scrum Master Dirige la Retrospectiva en Lugar de Facilitarla

Hola a todos

Una de las disfuncionalidades  y punto de mejora que he encontrado en los equipos Scrum, radica en que el Scrum Master  (SM) (ya sea que venga del mundo de la gerencia de proyectos, o acostumbrado a un liderazgo impositivo) al momento de realizar la retrospectiva reúne al equipo (1), y aunque realiza las actividades propias de una retrospectiva (2)(3), cada actividad cierra con sus conclusiones, es decir:

• decide cuales fueron las causas principales de por qué les fue bien o mal durante el sprint
• decide cuales son las acciones de mejora, acuerdos y experimentos a realizar
• el equipo esta allí solo para estar de acuerdo con sus decisiones.

Es decir, dirige la sesión en lugar de facilitara.

Problemas de este enfoque

• no permite la auto-organización
• queda el SM como el único responsable de decidir que se hace, y por ende a quien culpar [les sugiero leer este post de Martín Alaimo sobre la responsabilidad del equipo y el único responsable (4)] de una buena o mala estrategia.
• el equipo solo sirve para hacer lluvia de ideas pero no decide, pues el SM decide por el equi
• el equipo no esta empoderado tiene voz pero no voto
• el equiipo no madurará, pues siempre le dirán que hacer y no asumirá consecuencias.
• El SM no es un facilitador, es más alguien que dirige al equipo y este depende de él para todo (se sigue un esquema de Comando y Control - típico de la gerencia de proyectos - )
• Se esta trabajando con un grupo y no con un equipo (4)

Soluciones

• El SM es realmente un facilitador de la reunión(5), es decir el SM esta ahí, para ayudar al equipo a encontrarse,  ser su espejo, no dirige sino que facilita, es alguien que cuenta con instrumentos y experiencias para facilitar correctamente la sesión de retrospectiva de su equipo (6).
• Al finalizar cada paso de la retrospectiva (3) el SM invita al equipo a que priorice, reflexione y tome decisiones sobre:
• problemas
• oportunidades de mejora
• experimentos
• planes
• acuerdos
• cambios a realizar entre otros.

Beneficios de la Solución Propuesta

• El equipo se empodera de sus problemas y soluciones
• Todos adquieren un compromiso entre pares, nadie les dice que hacer, ellos acuerdan que ahcer.
• El equipo tiene voz y voto
• Si el equipo falla, el equipo aprende y mejora (en el esquema anterior el SM es el culpable de elegir una mala estrategia)
• El equipo comienza a sentirse responsable y emerge la autoorganización
• Si el equipo durante el sprint no esta tomando las acciones que se comprometieron,
• entre ellos pueden llamarse la atención (es más fuerte la presión social que el compromiso ante una orden) o 
• el SM puede interpelarlos con una pregunta poderosa puede hacerlos conscientes de la desviación de lo comprometido por ellos
• El equipo se escucha entre sí (recordemos que las mejores ideas vienen de cualquier parte)

Bueno hasta acá este corto compartir, bienvenido el feedback, los comentarios y las experiencias.

Saludos ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Recordemos que el equipo Scrum esta constituido por Product Owner, Equipo Desarrollador (el cual es multidisciplinario), y Scrum Master
2. En esta página podrás encontrar cientos de actividades https://plans-for-retrospectives.com/es/
3. Recordemos que un buen guión de retrospectiva (según el libro Agile Retrospectives de Diana Larsen y Ester Derby) cuenta con:
• Armar el escenario
• Recolectar datos
• Indagar
• Decidir que hacer
• Cerrar
4. Compartiendo la responsabilidad. Hacia Un Equipo Real.por Martín Alaimo (clic aquí)
5. Según comparte Martín Alaimo en su libro "Facilitador de Equipos Ágiles: El Camino de un Coach hacia la Agilidad Empresarial" 

• La facilitación  de grupos: es un proceso por el cual una persona cuya elección es aceptada por todos los miembros del grupo, que es neutral y no tiene autoridad sustancial en la toma de decisiones, diagnostica e interviene para ayudar al grupo a identificar y resolver sus problemas y tomar decisiones y para así, aumentar su efectividad. (Schawarz, 2002)

6. La posible agenda de una retrospectiva puede ser algo como [Agenda Scrum] Pasos para Realizar la Retrospectiva

[Scrum] Ritmo Sostenible sobre Ritmo Insostenible

Metrónomo: utilizado para indicar tiempo o compás de las composiciones musicales. Produce regularmente una señal, visual y/o acústica, que permite a un músico mantener un pulso constante al ejecutar una obra musical.(1).

Hola a todos:

He escuchado algunas veces decir esta expresión a los Scrum Masters o Product Owners:

"Equipo TENEMOS QUE DARLE A MORIR para que entreguemos todo lo comprometido en este sprint"

[BadSmell-1: Se impone al equipo el sobre-esfuerzo](2)

Desde el punto de vista de Scrum y Agile se ven varios problemas en esta frase.

1. En Scrum los equipos trabajan en hacer la MAYOR y MEJOR cantidad de alcance (o ítems de backlog) que solicite el PO durante la jornada laboral, ni más ni menos.
2. Es posible que durante el sprint se complete o no todo lo propuesto durante el planning, en caso de que se termine antes se solicitará más ítemes, en caso de que no se complete lo planeado se emplea el timebox para identificar en la retrospectiva por qué no se logro lo planteado y las acciones a realizar en el siguiente ciclo.
3. (se que el comentario que sigue le dolerá a los amigos del control) En Scrum los equipos son los que deciden si sobre-esfuerzan o no - ojo, es importante no caer en el otro extremo y creer Scrum significa ser anárquicos, y no cumplir jornada laboral etc, recomiendo estos dos post acerca del tema (7)(8)-,es normal que planteemos el sobre-esfuerzo pero debe ser una decisión de equipo no una imposición, y como principio clave se debe compartir el propósito de este sobre-esfuerzo para comprender la causa y la necesidad del mismo.

Pero no todo termina allí

El problema radica en que la frase del "DARLE A MORIR" no es solo de un sprint, sino que es frecuentemente usada todos los sprints, y allí con seguridad emerge [BadSmell-2] que ni la organización, ni el Product Owner, ni el Scrum Master entienden mucho de Scrum, ni de Ágil, y estan llevando las prácticas de la gestión tradicional al contexto ágil, y pronto veremos al equipo decir:

• "no ganamos nada con Scrum"
• "pensábamos que íbamos a mejorar nuestra forma de trabajo y nuestra vida, y no es cierto"
• "esto no fue lo que nos dijeron en el entrenamiento"
• "antes -en cascada- solo nos esforzábamos al final, ahora cada dos semanas tenemos una semana de martirio"

Lo anterior denota que se olvida el principio ágil de:

"Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida." (3)

Y no estoy afirmando que esporádicamente o muy ocasionalmente no existirá algún sobre-esfuerzo(4) -realmente a veces se requiere- pero es importante comprender que los equipos necesitan cierta cadencia o ritmo para navegar con cierta comodidad - o cuasipredictibilidad - en el mar de la incertidumbre(5).

Por lo tanto este sobre-esforzar al equipo constantemente es indicador de:

1. [BadSmell-3] El Scrum Master no esta empleando la retrospectiva como instrumento para entender por qué el desgaste constante del equipo y como salir de este círculo vicioso.
2. [BadSmell-4] El Product Owner cree que puede pedir y exigir todo lo que quiere sin considerar la capacidad del equipo.
3. [BadSmell-5] El equipo no es protegido por el Scrum Master de las malas prácticas
4. [BadSmell-6] El equipo aun no es consciente de su autoorganización y de su capacidad de decir "NO" ante esta mala práctica continuada

Adicionalmente este sobre-esfuerzo frecuente llevará al desgaste del equipo y con seguridad a la desintegración del mismo o renuncia de alguno o varios de sus miembros (6).

Espero con esto haber aclarado un poco sobre este BadSmell en las organizaciones que comienzan con Scrum o aun no saben como trabajar con el.

Hasta la próxima.

Saludos ágiles
Jorge Abad.

Referencias, Aclaraciones, Comentarios y Notas

1. Ver definición de Metrónomo en Wikipedia - clic aquí.
2. Usaré la etiqueta BadSmell para resaltar lo que son malas prácticas
3. Ver los principios -aquí-.
4. Un post sobre el sobre-esfuerzo que escribí hace un muy buen tiempo - clic aquí -.
5. Principios de Incertidumbre de Requisitos, Procesos y Productos de Software - clic aquí-.
6. Dice Sun Tzu en el arte de la guerra: "Las armas son instrumentos de mala suerte; emplearlas por mucho tiempo producirá calamidades. Como se ha dicho:"Los que a hierro matan, a hierro mueren." Cuando tus tropas están desanimadas, tu espada embotada, agotadas tus fuerzas y tus suministros son escasos, hasta los tuyos se aprovecharán de tu debilidad para sublevarse. Entonces,aunque tengas consejeros sabios,al final no podrás hacer que las cosas salgan bien."
7. ¿Que significa autoorganización en Scrum? (Clic aquí)
8. Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado (Clic aquí)

El compromiso del Sprint mal entendido

Hola a todos

En scrum durante el planning del sprint se establecen varias premisas para poder avanzar bajo el escenario de la incertidumbre:

• La primordial: Cual es objetivo del sprint, ¿qué capacidad de negocio queremos proporcionar al final del ciclo?
• Las secundarias:
• Entender qué se va a construir (parte estratégica)
• Decidir dada la capacidad del equipo cuantos ítemes de backlog cree el equipo que es capaz de llevar al DONE / COMPLETADO / TERMINADO (recomiendo este post Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad )
• Decidir cómo se va a construir (parte táctica)

Y durante todo el sprint, el equipo trabajará en:

• cumplir el objetivo del sprint
• Construir la mayor cantidad de producto posible(1) (software) que tenga calidad y valor durante el tiempo laboral del sprint y según las prioridades establecidas en el planning. (ver poster de responsabilidades de los diferentes roles durante el sprint - clic aquí)

Pero no todos lo entienden así

Existen implementaciones de scrum donde:

• el compromiso TIENE que ser cumplido
• el compromiso es IMPUESTO
• se considera al sprint como una mini-cascada
• existe un microcontrol durante todo el sprint
• y la gerencia se "montó" en scrum sin entender como funcionaba y solo por moda

Es allí donde se observan escenas como la siguiente

Aunque es cómica la exageración, se que varios de los que leemos este blog (incluido yo) hemos estado en situaciones así, les confirmo, este no es el espíritu de Scrum, esto no es lo que se busca, además esto no es Scrum.

Respecto a la escena, si al final del ciclo si la cantidad de ítemes identificada no es cumplida, pues se realizará una retrospectiva y se mirará como mejorar tanto en lo técnico, táctico como en en las relaciones para ser exitosos el próximo ciclo.

Ojo, no se trata de que si no logramos el objetivo, no nos importe (2), pero tampoco se trata de imposiciones al equipo, se trata de poder trabajar de forma autogestionada, táctica,  profesional y con foco durante el periodo del sprint para hacer lo más que se pueda, con calidad y valor.

Espero haber ayudado un poco al entendimiento de este aspecto.

Saludos ágiles y bienvenido el feedback

Jorge Abad

Notas, aclaraciones, comentarios y referencias

1. "Posible" se refiere a que dados los impedimentos, la incertidumbre, las habilidades técnicas, el equipo, se construirá lo más que se pueda bajo el escenario que se presente.
2. Recomiendo ver este post para entender mejor esta afirmación -Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado- .
    

[Scrum] Antipatrones del Daily Meeting / Reunión diaria / Scrum Diario y Posibles Soluciones

Faltaba yo...

Me he encontrado esta semana muchos post de antipatrones en los dailys (*)  (unos de Javier Garzas a quien sigo frecuentemente en su blog y otros de otras fuentes), y bueno la verdad falto yo, pues a mi he identificado otros mas a añadir a la lista - según mi experiencia - :


Los antipatrones encontrados y los propios son los siguentes:

Fuentes	Antipatrón	Posible(s) Solución(es)
(1)(2)(3)	Reuniones de informar al líder o al jefe	Intervención del scrum master explicando que el daily es para el equipo y sincronizar al equipo, no para el scrum master, líder, product owner o cualquier otro rol dominante. Poner al líder detrás del equipo (Por lo general el daily se hace al frente del tablero kanban y todos mirando el tablero )
(1)(2)(3)	Se llega tarde	Acordar con el equipo una multa en dinero para quien llega tarde (ojo, solo si el equipo todo esta de acuerdo), y enfatizar que el objetivo no es conseguir plata para desayunos o invitaciones en la tarde sino para promover la asistencia puntual con este "leve castigo" Retroalimentar en la retrospectiva y a lo largo del sprint a quien sea reincidente, haciendo énfasis en lo necesario y útil que es este momento para el equipo
(1)(2)	No lo puedo recordar	El Scrum Master invita a los participantes a preparar la conversación del daily minutos antes.
(1)(3)	Ponerse a contar la historia de tu vida	El Scrum master, prepara al equipo antes del daily diciendo que hará una señal para que cualquiera que se esté extendiendo comprenda que debe cortar rápido.
(1)(2)(3)	Resolver problemas	El Scrum Master interrumpe respetuosamente al equipo y les dice que luego del daily se resuelven estos aspectos
(1)(2)	Se van de tiempo	El Scrum Master interrumpe respetuosamente la sesión, corta a los 15 minútos . Luego en un espacio y tiempo aparte revisa con el equipo que sucedió para que este tiempo no se cumpliera (igual se puede revisar en la retrospectiva) Una posible opción es que tienes en tu equipo más de 9 team members, que es lo máximo que tiene un equipo scrum.
(1)	Reunión caótica	El Scrum Master entrega un token y solo tiene la palabra quien lo posee
(1)	La gente se corta y no habla o habla poco	Coach del Scrum Master con esta persona
(2)	Hacerla unos días y otros no	Responsabilidad del Scrum Master
(2)	Estar distraído	Una opción: Un simple llamado de atención del Scrum Master corrige esto.  Luego indagar por que se esta distraid@ en el daily, pueden haber razones para mejorarlo o corregirlo
Propia	Contestar las tres preguntas abstractamente, ejemplo, señalando el tablero: ayer hice esto hoy esto y no tengo impedimientos o  Ayer hice la parte 1 de la historia 2 y hoy continúo con la parte 3 y no tengo impedimientos	Inivitar a que se digan los nombres de las funcionalidades, para lograr la atención de todos los del equipo.
Propia	Los dailys cada día a diferente hora para el mismo equipo, de manera que puedan asistir todos o alguien en especial	Esto se vuelve una locura, y uno termina no sabiendo que día de la semana es el daily. Recomentación: EL DAILY SIEMPRE A LA MISMA HORA
Propia	No empezar por que falta...	El daily es del equipo debe comenzar con los que estén del equipo, es un ritual a cumplir y es de los aspectos sicorígidos de scrum - recordemos que es un marco donde nos movemos con liberdad -. Se comienzan  con los que estén y aclaro "no es necesario que este el Scrum Master", si por alguna razón este falta en otro momento se enterará de los impedimentos y del avance del equipo - seguro en el tablero Kanban queda esto reflejado -
(3)	Baja Energía	El Scrum Master debe indagar esta situación y tomar acciónes. (ojalá no estén trasnochando)
Propia	Daily avanzado el día. Por lo general esto desconcentra a los equipos, parar para hacer un daily tipo 11am o 3pm.	Tratar de hacer el daily comenzando el día de trabajo
(3)	Impedimentos no son identificados. Por lo general los team members no identifican que tienen un impedimento y no no cuentan	El Scrum Master debe hacer énfasis en los elementos que son bloqueantes al equipo o que pueden bloquearlos de manera que se comience la gestión para removerlos
(3)	Los impedimentos no son removidos	El equipo debe en este caso llamarle la atención al Scrum Master. Identificar causas en la retrospectiva.
(3)	Los obstáculos solos son removidos en el daily	El Scrum Master debe informar tan pronto se remueva un impedimento al equipo para mejorar la agilidad y no esperara al daily
Propia	Permitir que el product owner indague al equipo.	Recordar el daily es del equipo, ni el product owner, ni el scrum master tienen voz y voto en el. Después del daily estos pueden hablar con el equipo
(2)	Se toman tareas sin respetar prioridades del backlog Explico: como los team members comparten la respuesta a la pregunta ¿que voy a hacer hoy? es probable que elijan algo que no esta en la prioridad.	El Scrum Master o cualquier team member llamar la atención sobre esta situación e invitar a que se respete la priorización.

--

Nota: Si tienen más antipatrones no duden en compartirlos





Saludos ágiles

Jorge Abad





_______

Definiciones

(*) Daily (Reunión Diaria / Daily Meeting / Scrum Diario ): La reunión diaria propiedad del equipo de desarrollo - facilitada por el Scrum Master - que dura máximo 15 minutos y se hace de pie, donde cada miembro cuenta:

• que hizo ayer
• que se va a hacer hoy
• y que impedimentos se tienen

____

Referencias

(1) Reuniones Diarias (Daily meetings): anti-patrones - Blog Javier Garzas -  Clic Aquí
(2) Tales from the Scrum: Anti-patterns de la reunión diaria - Blog Ángel "Java" Lopez -  Clic Aquí
(3) It's Not Just Standing Up: Patterns for Daily Standup Meetings -  Blog Martin Fowler - Clic Aquí (este post es de estudio)
(4) Stand-up Meeting Antipatterns - Clic Aquí

_

Leído y Recomendado: Antipatrones Scrum: primer acercamiento

http://www.gazafatonarioit.com/2014/11/antipatrones-scrum-primer-acercamiento.html






Saludos Ágiles
Jorge Abad

Antipatrones en la gerencia de proyectos

Les comparto la exposición de los estudiantes

• Camilo ramírez
• Jose luis flórez
• Edison estrada
• Alejandro gutierrez

Del curso Gerencia de Proyectos Informáticos de la Especialización en Ingeniería de Software Cohorte 09 de la Universidad de Medellin - www.udem.edu.co

Esta exposición se centra en las malas prácticas en la gerencia de proyectos y como resolverlos.


https://docs.google.com/file/d/0B5JZ11Z2PoWWT0FFZTJROVdSMFU/edit?usp=sharing



Saludos
Jorge Abad.