Presentación: Los puntos ciegos del Scrum Master - Actualización 2023

Un buen Equipo Ágil gestiona también la excelencia técnica de su producto

 “Un buen Equipo Ágil en su búsqueda de la excelencia, gestionará la calidad del producto mejorando frecuentemente las características técnicas en cual fue concebido o recibido.

En la medida que al producto se le adicionan funcionalidades, también se le debe mejorar el desempeño y sus atributos arquitectónicos."

Tweet: "Debugging is like being the detective in a crime movie where you are also the murderer." - Filipe Fortes

"Debugging is like being the detective in a crime movie where you are also the murderer." - Filipe Fortes

— Programming Wisdom (@CodeWisdom) January 4, 2021

Frase: Excelencia a todo nivel

 

Hablemos de Deuda Técnica - Otra Vez

De Colección: ¿Y tus retrospectivas cuándo van a ser de tipo Élite?

Tomado de (1)

Hola a todos

Uno de los informes que más ha tomado fuerza dentro del mundo Ágil y de DevOps es el elaborado por DORA (DevOps Research and Assessment): "Accelerate: State of DevOps", en la versión de 2018 "Accelerate: State of DevOpsStrategies for a New Economy 2018"(1)(clic aquí), en su capítulo "Influencing culture through learning" se encuentra este interesante texto

"We found that learning reviews help contribute to a climate for learning and also impact organizational culture. It is important to note that this is true when teams conduct them to learn from their mistakes and failures and then turn these into opportunities to improve how they work. In particular, teams that leverage findings from retrospectives to implement changes to tooling, processes, or procedures see the strongest impacts.

Our analysis found that elite performers are 1.5 times more likely to consistently hold retrospectives and use them to improve their work. When we asked respondents about their most recent retrospective, we see common themes around outages, failures, performance, and deployment."

Traducido

"Descubrimos que las revisiones de aprendizaje ayudan a contribuir a un clima para el aprendizaje y también impactan la cultura organizacional. Es importante tener en cuenta que esto es cierto cuando los equipos los conducen para aprender de sus errores y fracasos y luego los convierten en oportunidades para mejorar su funcionamiento. En particular, los equipos que aprovechan los hallazgos de las retrospectivas para implementar cambios en las herramientas, procesos o procedimientos ven los impactos más
 fuertes.

Nuestro análisis encontró que los Jugadores de Élite tienen 1.5 veces más probabilidades de tener retrospectivas consistentemente y usarlas para mejorar su trabajo. Cuando preguntamos a los encuestados acerca de su retrospectiva más reciente, vemos temas comunes sobre interrupciones, fallas, rendimiento y despliegue."

Luego comparten esta nube de temas que se discuten en los equipos élite en el mundo

Tomado de (1)

El listado de palabras en orden alfabético las encuentras al final del post(3).

Invitación

Una de las recomendaciones e invitaciones que hago a los Scrum Masters, Facilitadores, Líderes Ágiles y Equipos de Desarrollo que tienen cierta madurez haciendo Scrum o cualquier otro marco es:

"tarde o temprano tus retrospectivas tienen que hablar del tema técnico, o ¿vas a seguir perfeccionando la comunicación y el proceso en el sprint 20 y siguientes?, es urgente que veas el elefante en el cuarto si quieres llevar a tu equipo al alto desempeño"

No estoy afirmando que: "no sea necesario mejorar el proceso y el trabajo en equipo", si hay que mejorarlos se hace, pero el tema técnico es un tema obligatorio a tocar en las retrospectivas, y más si deseas alcanzar alto desempeño.

Scrum Master y Equipo evitando hablar del tema técnico

Basado en la sugerencia anterior he escrito y compartido post similares en el pasado:

• Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo (clic aquí)
• Presentación: Los puntos ciegos del Scrum Master (clic aquí)

Quedan entonces dos preguntas

• ¿de qué tema hablaron en la última retrospectiva de tu equipo?

• ¿y tus retrospectivas cuándo van a ser de tipo Élite?

Hasta acá este compartir.

Bienvenido el feedback

Saludos ágiles
Jorge Abad

Notas, Referencias, Aclaraciones y Comentarios

1. Accelerate: State of DevOps. Strategies for a New Economy 2018 - https://inthecloud.withgoogle.com/state-of-devops-18/dl-cd.html 
2. Accelerate: State of DevOps 2019- https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
3. El listado de palabras de la nube en orden alfabético es el siguiente:
   

able access analysis api app application architecture automated automation availability aws bad behavior breach broken bug bugs build business capacity cases cause caused certificate change changes client cloud cluster code collaboration communication communications config configuration container cpu crash critical customer customers data database deadlines defect defects degradation delivery dependencies deployed deployment

deployments design development devops disaster disruption dns documentation done dont downtime due efficiency email environment environments error errors external failed failing failure failures feature features feedback firewall functional functionality gaps hardware high human implementation improve improvement improvements incident incidents incomplete incorrect infrastructure integration issue issues kafka know knowledge

lack last learning lessons load loss major management manual many migration mismatch missed missing mistakes monitoring mortems needed network networking new none nothing one operational outage outages party patching performance planning poor post postmortems power problem problems procedures process processes prod product production project projects push quality recovery regression

regular related release releases requirements resource retrospective retrospectives review reviews rework root scope security server servers service services slow software sprint sql stability steps storage support system systems tasks team teams technical test testing tests time tool tools unexpected unplanned updates upgrade upgrades use user value vendor version went work working wrong

Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded

Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded from Jorge Hernán Abad Londoño

Hablemos de Deuda Técnica “Cómo la Deuda Técnica puede acabar tu proyecto ágil”

Hablemos de Deuda Técnica “Como la Deuda Técnica puede acabar tu proyecto ágil” from Jorge Hernán Abad Londoño

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

Sin excelencia técnica el costo de los cambios en Agile serán los mismos o peores que en Tradicional

#LesComparto

Sin excelencia técnica no es viable la agilidad ni en el mediano ni en el largo plazo#Agile #Scrum #TechnicalDebt pic.twitter.com/3AaBTZyNmn

— Jorge Hernán Abad L. (@jorge_abad) October 26, 2017

Noticia Falsa: En cascada no existía deuda técnica

Hola a todos, hace poco compartía con un compañero el cual trabajó durante mucho tiempo en cascada y ahora esta comenzando a trabajar con scrum y esta viéndose en unos retos bien importante, el cual me argumentaba que:

- en cascada los problemas no teníamos los problemas de deuda técnica que existen en ágil. En cascada siempre entregabamos...

no les niego que mi cara fue similar a esta.

Vamos primero a aclarar términos:

Ver más sobre deuda técnica en (1)

La verdad parece que se nos olvida que en proyectos construidos en cascada de más de 6 meses (2) pasan las siguientes disfuncionalidades respecto a la parte técnica:

1. Nos comprometemos a una fecha y no la cumplimos
2. Las pruebas las empezamos 2 o 3 meses después de la fecha de finalización del proyecto (si es que tenemos suerte)
3. Nos quedamos en ciclos interminables de pruebas (4, 5 o  hasta más) para poder entregar el sistema.
4. El cliente nos acepta el producto después de dós o más ciclos de pruebas
5. Salimos a producción muertos de miedo y estabilizando el sistema por más de 6 meses (muchas de las condiciones de aceptación de un producto en cascada dice cuando por 2 meses no aparezcan problemas en producción).

Estas disfuncionalidades son mayormente creadas por la pobre calidad técnica y lo que estamos tratando de hacer es entregar el proyecto con fuerza bruta.

¿Y en Agile como es?

La verdad es que, si tenemos excelencia técnica (buenas prácticas ágiles, buena ingeniería, buena arquitectura),  esto no se presentará (o al menos se reducirá enormemente su impacto) y la imagen de arriba hará honor a lo que profesamos:

• Entregamos software de valor frecuentemente
• Y la medida de progreso es software funcionando

Pero la realidad no es así, los equipos en general caen en "Agilidad Cosmética" que tiene como síntomas:

• Solo se centra en el proceso scrum (o como sea que lo llamen) y no en las personas.
• Los equipos no mejoran sus prácticas técnicas.
• Los scrum masters solo se enfocan en mejorar la comunicación del equipo cuando hay muchos aspectos a mejorar.
• Las retrospectivas son las mismas hace 5 sprints.
• Los equipos no son retados técnicamente por el scrum master (ver más acá Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo).
• No se gestiona la deuda técnica.
• No hay una preocupación seria por parte del equipo de la excelencia técnica.

Y debido a la entrega frecuente hace que la pésima calidad del software evidencie más rápido nuestras falencias técnicas como equipo de desarrollo.

Algunos tweets

Para terminar quisiera compartirles algunos tweets relacionados con la deuda técnica y la excelencia técnica tanto en cascada como en ágil.

Sin excepción

Sin excelencia técnica no hay agilidad #agile #scrum pic.twitter.com/T7AtdaT5xK

— Jorge Hernán Abad L. (@jorge_abad) April 28, 2016

---

No monitorear, ni pagar la #DeudaTecnica cada sprint, es una característica del #BadAgile https://t.co/t8Ub2tCrKO#TechnicalDebt #Scrum

— Jorge Hernán Abad L. (@jorge_abad) May 17, 2017

---

Otra Definición de #DeudaTecnica

Cuando terminas trabajando para el sistema y no el sistema para tí#technicalDebthttps://t.co/zO40WzAp3O

— Jorge Hernán Abad L. (@jorge_abad) February 2, 2017

---

La deuda técnica creciente termina por agotar la velocidad del equipo #Scrum y ocasionando la generación de cero valor #Agile #TechnicalDebt

— Jorge Hernán Abad L. (@jorge_abad) May 5, 2016

---

Cualquier intento de escalar #Scrum sin contar con Excelencia Técnica ni Gestión de la Deuda Técnica muy seguramente será un fracaso

— Jorge Hernán Abad L. (@jorge_abad) July 24, 2017

---

#lesaAgilidad
Si como equipo no estas mirando, midiendo, controlando la deuda tecnica #techinicalDebt #agile #scrum #fail

— Jorge Hernán Abad L. (@jorge_abad) April 25, 2017

La deuda técnica es curable si se diagnóstica a tiempo #techinicalDebt

— Jorge Hernán Abad L. (@jorge_abad) May 20, 2016

---

3 ideas:
El sw con el tiempo se degrada
la deuda técnica debe ser identificada y gestionada
Sin excelencia técnica no hay agilidad

— Jorge Hernán Abad L. (@jorge_abad) April 20, 2016

---

Haz buen software o alguien (talvez tu mismo) terminará pagando la deuda técnica de tu proyecto #agile #scrum pic.twitter.com/N7nykg2rH2

— Jorge Hernán Abad L. (@jorge_abad) March 16, 2016

---

Hacer #Scrum sin gestionar la #DeudaTecnica es hacer problemas de forma iterativa, incremental y en ciclos cortoshttps://t.co/t8Ub2tkQme

— Jorge Hernán Abad L. (@jorge_abad) June 21, 2017

---

Ya sea en cascada o en #Agile sino hay excelencia técnica se va directo al fracaso, eso es indistinto del método.

— Jorge Hernán Abad L. (@jorge_abad) May 30, 2017

---

Comentarios, Aclaraciones, Notas y Referencias

1. Presentación sobre deuda técnica (clic aquí)
2. En proyectos más pequeños de tamaño (5 meses o menos) las disfunciones técnicas que tiene cascada para desarrollo de software no se evidencian tan fácilmente como en proyectos grandes, pues en últimas el mal código siempre generará impacto tipo de impacto en el tiempo, costo y satisfacción del cliente independiente del tamaño del proyecto (Gracias Luis Mulato @LuisMulato por el feeback y correciones respecto a este último punto y al post)

Sin excelencia técnica no hay agilidad

Hola a todos

Hace unos días me encontré con este excelente post de Michael Sahota @MichaelSahota - Agile vs Waterfall en donde compara rápidamente Agile y Waterfall

Y donde se presenta que al final de cascada lo que se genera es un lío para por fin entregar el producto.

Pero he visto este mismo lío en la entrega en muchos equipos Scrum cuando no se pone atención a la excelencia técnica, con prácticas como:

• estándares de codificación
• buenas prácticas de programación
• revisión por pares
• TDD
• ATDD
• refactoring
• propiedad colectiva de código
• integración continua
• pruebas unitarias
• revisiones estáticas de código
• pair programming
• mob programming (4)
• pruebas funcionales automatizadas
• principios de diseño OO (SOLID)
• clean code
• etc

Termina sucediendo que los bugs en producción van en aumento (incrementando la deuda técnica (1)) y lo que inicialmente se usaba como el patrón de desenfoque o interrupción (5)

Que por buena práctica debería tomar aproximadamente el 10% al 20% del sprint backlog, termina por acaparar ciclo tras ciclo toda la capacidad del equipo durante un sprint.

Y en definitiva el tiempo del sprint que inicialmente se iba a emplear para crear incrementos de valor para el negocio termina usándose para corregir bugs y deuda técnica.

Así las cosas, por más que tengamos:

• retrospectiva (2)
• mejora continua
• sprints
• dailys 
• reviews 
• cultura ágil/agile
• scrum
• etc, 

No servirá de nada sino entregamos software de valor y bien construido cada sprint, pues esta sencilla omisión se vendrá en nuestra contrá

la deuda técnica siempre se paga

Cerrando

Hasta aquí este deber social de poner foco sobre este tema que como principio ágil, reza:

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

Y por experiencia me atrevo a corregir una parte de ese enunciado de la siguiente manera:

Sin excelencia técnica no hay agilidad

La parte del diseño si la dejo igual.

Sin excepción

Sin excelencia técnica no hay agilidad #agile #scrum pic.twitter.com/T7AtdaT5xK

— Jorge Hernán Abad L. (@jorge_abad) 28 de abril de 2016

Saludos ágiles

Jorge Abad

Notas, aclaraciones y referencias

1. Deuda técnica un enfoque holistico por Ángel Nuñez - @snahider - http://es.slideshare.net/snahider/software-debt-que-es-y-como-gestionarlo
2. Que debería entre otras cosas, invitar/retar al equipo hacia la mejora técnica, y sería un error del Scrum Master no hacerlo.
3. Ver los principios ágiles aquí - http://agilemanifesto.org/iso/es/principles.html
4.  Mob programming como forma de auto organización de un equipo Agile por Oscar Amelunge - @oscaramelunge (clic aquí)
5. El patrón de desenfoque o de interrupción (expuesto por Jeff Sutherland - @jeffsuhterland en Scrum The Future Of Works (clic aquí) ) tiene por objeto dejar un porcentaje pequeño del sprint (10 al 20%) para atender interrupciones que tienen como fuente temas del ahora como bugs en producción críticos, funcionalidades urgentes para el PO, etc.
6. Unas diapositivas de Israel Antezana Rojas - @israelantezana que invitan también a esta reflexión : SCRUM no es suficiente... (clic aquí)