Las evaluaciones (de equipos, procesos, etc.), bajo diferentes nombres (evaluaciones, radares, checklist, etc.), siempre han estado por ahí dando vueltas y el mundo Ágil no ha sido ajeno. Y en el caso del post de hoy no me estoy centrando en evaluaciones a nivel personal (como podrían ser las n-mil certificaciones Ágiles) sino a evaluaciones a nivel de equipo o incluso empresa.
Como te he contado tantas veces, toda práctica (Ágil) puede usarse de manera Oscura, las evaluaciones también.
Las evaluaciones han sido un tema que ha levantado resquemor y rechazo a una parte del «sector Ágil», que lo ve como una intromisión a su manera de hacer las cosas, imposición, restricción de la auto-organización, etc.
Ciertamente, un exceso de evaluación, pormenorizada, altamente intrusiva, que entra en el detalle, etc., podría limitar la auto organización e incluso llegar a los problemas de tener muchas reglas y metodologías al detalle. Podría ser una puerta al lado oscuro.
Pero, entre la libertad máxima con cero evaluaciones y las evaluaciones oscuras… ¿hay un punto intermedio beneficioso?
En mi opinión, una evaluación sutil de cómo vamos, frente a los valores Ágiles, principios Ágiles, más cerca de un «qué molaría», y no de un «como hacerlo», es útil.
Y ese grado de utilidad, sobre todo, lo vamos a ver mejor si lo cruzamos con el grado de madurez del equipo en cuestión. Es razonable pensar que equipos «bebé» necesiten más evaluación sutil, siempre pensando en que aprendan poco a poco a valerse por ellos mismos, que equipos «adultos».
Y, aparte de lo que yo piense, ¿qué piensan los que saben? ¿qué piensan los líderes del movimiento Ágil?
Pues, como seguro has adivinado, puedes encontrar numerosos autores de referencia en el mundo Ágil hablando sobre evaluaciones, en línea con lo que te contaba antes, evaluaciones contextuales, más cercanas al qué que al como y siempre sin caer en el lado oscuro que rompa la auto-organización.
Por ejemplo Rothman, ahí va referencia, propone una idea similar a las anteriores. Añade, que los «radares» deben adaptarse a las circunstancias concretas del equipo y que deben evolucionar según avancen las circunstancias.
Y luego, recordaréis, está la antigua y popular check list de Scrum de Kniberh.
Incluso alguien tan directo y claro en ideas, firmante de manifiesto Ágil, como Jeffries, trató el tema, proponiendo un radar y escribiendo, entre otros que… «Cuando un equipo está interesado en mejorar su proceso, algunos gráficos pueden resultar útiles. Puede resultarle útil realizar un seguimiento de las horas dedicadas a la programación de pares o el número de integraciones por día».
De hecho, Jeffries citaba un post del contexto eXtreme Programming, en el que también se propone un rada Ágil puntuable, por parámetros, del 0 al 2.
Y así podría poner muchos más.
De todas maneras, si quieres complementar esto, Juanjo Vallina, Lisseth Mejía y Domingo Gaitero, nos hablarán sobre evaluaciones en la PAM20.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
¿Cuál es un ejemplo de un radar ágil?
Gracias-.
en mi equipo al final del sprint hay un cuestionario a responder de manera anónima para comprobar el nivel de «agile madurity» …. con unas 30 preguntas