viernes, febrero 17, 2017

Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo



Hola a todos:

Hace poco en una sesión de acompañamiento a Scrum Master, alguien me preguntó

¿Hacia dónde seguir mejorando el equipo, pues creo que no podemos mejorar más?

Ante esta pregunta, comencé a explicar el Modelo Operativo de Generación de Valor (1) el cual se basa en:

  • Personas
  • Procesos y
  • Herramientas


Por lo tanto, si el Scrum Master se centra solo en personas y procesos "rápidamente" (tal vez en 10 sprints, tal vez muchos más, tal vez menos ) el equipo logrará sinergia y alcanzará la maestría en el manejo de Scrum, sus ceremonias, priorización del backlog, etc.,  y caerán en una "zona cómoda" en la cual la pregunta realizada tiene todo el sentido.

Bajo este contexto la frase de Ken Schwaber - cocreador de Scrum -  toma todo el sentido:

“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”( no dudo que la hubiera querido terminar con otra palabra)


Es necesario entonces, que como Scrum Masters y Coaches adicionemos a los procesos de mejora del equipo las herramientas (2) -o prácticas técnicas- y lograr que los equipos adquieran la maestría en ellas, aun más que sean sanamente insatisfechos y estén siempre buscando una mejor manera de hacer las cosas. De esta forma se genera valor hacia el interior y exterior del equipo estando en constante crecimiento.

Cerrando

A continuación quiero compartirles una pequeño listado de prácticas técnicas con las que pueden y deben retar a sus equipos como Coaches Agiles que son de ellos, la lista en esta en continuo crecimiento, este es el pequeño listado que encontré a la fecha:



Herramientas (Prácticas ágiles) 

Zona 1: Personas y Herramientas
  • Inspección o revision por pares
Zona 2: Procesos y Herramientas
  • Pruebas unitarias
  • Test Driven Development (TDD)
  • Aceptance Driven Development (ATDD)
  • Refactoring
Zona 3: Personas, Procesos y Herramientas
  • Pair Programming
  • Mob Programming
Zona 4: Solo Herramientas
  • Integración Continua
  • Despliegue Continuo
  • Revisión de código estática
  • Pruebas funcionales Automatizadas
  • Principios SOLID de POO (Programación orientada a objetos)
  • Clean Code
  • Automatizar lo automatizable
  • etc, etc, etc.




Para terminar les comparto esta frase que constantemente me inquieta "los pacientes se enferman de lo que el médico sabe (3)", por lo tanto si como Scrum master o Coach no estas en constante aprendizaje de estas tres áreas no podrás ayudar apropiadamente a tu equipo


Bienvenido el feedback


Saludos ágiles
Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias


  1. Operating model - https://en.wikipedia.org/wiki/Operating_model
  2. El tablero Kanban, la Gestión Visual, etc también son herramientas, el objetivo del post es hacer visible el punto de las prácticas técnicas ágiles.
  3. "los pacientes se enferman de lo que el médico sabe" - clic aquí para ver post relacionado




domingo, febrero 05, 2017

[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í)