Esta respuesta está escrita desde la perspectiva de alguien que tenía un sistema de gestión de rendimiento implementado alrededor de un equipo ágil; Como usted, todos en el equipo se dieron cuenta de la dificultad / inutilidad de las metas SMART de un año aplicadas a un grupo ágil, donde, cuando funciona completamente, la implementación de Agile puede considerarse inherentemente / ya SMART.
¡No realmente! Llame a lo siguiente una racionalización si es necesario (si la lógica está a medias ...), pero explicarlo a los revisores fuera de la organización inmediata ha preparado el escenario para los "objetivos" reales que ponemos en el sistema de gestión del desempeño.
- S para específico : durante cada planificación de sprint, el equipo acuerda un conjunto específico de tareas para lograr, y se compromete a realizarlas. Las tareas (y las historias de los usuarios), responden las preguntas de lo que quiero lograr, los propósitos / beneficios de lograr el objetivo, quién está involucrado, dónde se lleva a cabo y las limitaciones.
- M para medible : la lista de estas tareas, más el movimiento de los tickets a lo largo del sprint, desde el desarrollo hasta la revisión del código y el control de calidad para liberar (o lo que sea su flujo), responde a las preguntas de cuánto trabajo y cuándo se realizará .
- A para alcanzar : los grupos ágiles en funcionamiento no suelen comprometerse con algo en la etapa de planificación a menos que sea claramente alcanzable: todas las piezas están ahí para saber cómo lograrlo
- R para relevante : preguntas como si vale la pena, es el momento adecuado, coincide con nuestros otros esfuerzos: las historias y las tareas no se ven envueltas en un sprint y se comprometen, a menos que la respuesta sea afirmativa a todas estas preguntas ( típicamente ... YMMV)
- T para un límite de tiempo : un sprint es necesariamente un límite de tiempo, ya sea 2 semanas, 3 semanas, más o menos.
Si comprende / se convence a sí mismo de que su trabajo trimestral (y, por lo tanto, su trabajo de un año) es en sí mismo un gran objetivo INTELIGENTE, y que sabe que está logrando sus objetivos porque el equipo está funcionando bien, la velocidad es positiva, los lanzamientos están sucediendo , entonces llega al punto de su pregunta, que es, en última instancia, cómo traducir un proceso SMART en un conjunto de objetivos SMART para el beneficio de otra persona.
He podido hacer esto con éxito en el pasado escribiendo algo que para mí parece vago y, bueno, no muy INTELIGENTE, pero de hecho es perfectamente aceptable para otros.
Un par de ejemplos que me han pasado a otra parte:
"Quiero lanzar una nueva versión de WidgetMaker cada tres meses en el próximo año, siguiendo nuestro proceso interno de desarrollo de software, para alinearlo con el programa general de desarrollo de productos (bla, bla)".
"Quiero aumentar la velocidad de desarrollo del equipo en un n% desde la versión A hasta la versión B, concentrándome en los cambios incrementales en el proceso de preparación del trabajo atrasado, a fin de aumentar nuestra eficacia y disminuir los retrasos en el envío del producto".
Usted sabe y yo sé que estos no son los principios rectores de su grupo de desarrollo real, pero no son totalmente ajenos, y en mi experiencia son los tipos de cosas que parecen realmente INTELIGENTES y útiles para las personas fuera de su organización inmediata (sin ser completamente mentiras o totalmente cojo).