domingo, febrero 02, 2020

Antipatrón: Decirle historia de usuario a lo que no lo es

Que las historias de usuario sean de formato libre, no implica que todo requerimiento sea una historia de usuario.

Es en serio, “las historias de usuario tienen que ser pequeñas”. (ver más - aquí - )

Un buen tip: Que tome máximo 3 días de desarrollo, pruebas y despliegue.




jueves, enero 16, 2020

Diatriba: "by the book" una frase que me produce escozor




Hola a todos

Como algunos de ustedes saben, la mayoría de post los escribo tienen como objeto de dejar registro de mis experiencias y luego remitir a mis compañeros, jefes, estudiantes, y amigos,  a mi blog con miras a hacer reutilización del conocimiento,  gastar menos energía y de paso hacer un aporte a la comunidad.

Hoy quiero desahogarme, hacer un poco de catarsis, respecto a esta frase "BY THE BOOK",que me he encontrado en varias latitudes en este ejercicio de acompañar equipos y organizaciones. Por lo general, sson variaciones de las frases que han antepuesto a "by de book", veamos:

  • tus scrum masters son "by the book"
  • los equipos de transformación de ustedes son"by the book"
  • lo que ustedes me estan proponiendo es"by the book"
  • ese aseguramiento o assessment es "by the book"
  • tus agile coaches son "by the book"
  • tus consultores son "by the book"
y en el sentido estricto de la palabra voy a indagar,  el comentario no tiene nada de constructivo ni realista, la mayoría de las veces:
  • su mensaje principal respecto a nostoros "no sabemos que estamos haciendo", o "sabemos muy poco" (ese mensaje por lo general lo da la competencia)
  • su intención de plano es destructiva
  • busca garantizar de que no se hagan cambios o el "statu quo" (sí, es sin la "s" al final de statu)
  • su intención en la mayoria de los casos es :
    • mostrar desconfianza, 
    • generar descofianza, 
    • destruir y desacreditar cualquier observación que se haga
    • atacarme o atacar a "mi gente" por parte de la competencia:
      • que no entiende el proceso 
      • o que si lo entiende pero no le conviene que se hagan observaciones sobre su trabajo

Hagamos precisiones

Respecto a “saber poco”: cuando esto ocurre, somos profesionales y se lo aclaramos al cliente y conjuntamente decidimos acoger el riesgo. En tecnología siempre hay conocimiento nuevo. Sin embargo, cuando se va a indagar o a validar algo relacionado con las prácticas ágiles que lleva un equipo interno o externo, cosa a todas luces necesaria pues siempre queremos saber qué tan “correcto” lo estamos haciendo, lo primero que se pregunta es:

¿qué marco de trabajo siguen?

o ¿qué marco le han dicho al cliente que siguen?

y desde esa luz que los equipos mismos dan, se comienza a identificar si realmente eso que dicen ejecutar lo están haciendo y en qué nivel de "shu-ha-ri"(ver imagen) se encuentran.


"
Un ejemplo del "ataque" que comunmente recibimos, son de las personas, equipos u organizaciones que hacen el "scrumbut"(3):
  • hacemos scrum pero no hacemos retrospectiva
  • hacemos scrum pero no tenemos definition of done
  • hacemos scrum pero no hacemos pruebas
  • hacemos scrum pero el sprint backlog no esta definido
  • hacemos scrum pero no hacemos planning
  • hacemos scrum pero no tenemos review
todos esos scrumbut, o scrum pero, realmente implica que NO se está haciendo haciendo scrum, con razon dice la frase, que aparece en la misma guía oficial:

"scrum es liviano, fácil de entender, dificil de dominar"(2)
para terminar los dejo con dos interesantes recursos:
  • la lista de chequeo de scrum elaborada por Henrik Kniberg (3) y traducida por migran amigo Lucho Salazar (4) (que justo comienza validando con lo esencial - validando si se está en nivel "ha" o "ri", que es entregar software de valor de manera frecuente y tener u proceso de mejora continua y luego se va a la validación de marco)

  • y la leyes de Compartamiento Organizacional de Larman(5) traducidas por Hiroshi Hiromoto(6)


1. Las organizaciones están implícitamente optimizadas para evitar el cambio del statu quo de las posiciones y estructuras de poder de los mandos medios y de primera línea y de “especialistas”.
2. Como corolario de (1), cualquier iniciativa de cambio será reducida a redefinir o sobrecargar la nueva terminología para que signifique básicamente lo mismo que el statu quo.
3. Como corolario de (1), cualquier iniciativa de cambio será ridiculizada como “purista”, “teórica”, “revolucionaria”, “religión”,"BY THE BOOK"(7), y “necesitada de una customización pragmática para preocupaciones locales” — que desvía de atender las debilidades y el statu quo del manager/especialista.
4. Como corolario de (1), si luego del cambiar el cambio algunos managers o especialistas son desplazados, ellos se convierten en “coaches/entrenadores” para el cambio, frecuentemente reforzando (2) y (3).
5. La cultura sigue a la estructura (Culture follows structure)


Por lo tanto, si eres cliente, o proveedor y alguien se te acerca con el 

"BY THE BOOK"

en su discurso, te sugiero revises:
  • si es un sesgo cognitivo (o prejuicio que llamábamos hace un tiempo)
  • realmente no se tiene conocimiento y es una primera aproximación (esto se resuelve validando experiencias previas en otras organizaciones y contextos)
  • realmente estan evaluando el nivel  "SHU" o aprendiz de algo o alguien, y lo primero que se valida es si sigue las reglas minimas
  • o es una maniobra de "alguien" para destruir la confianza en la estrategia o en una persona, equipo u empresa y salvar su propio pellejo.

Hasta aca esta diatriba, y desahogo

saludos ágiles
Jorge Abad

Notas, aclaraciones, comentarios