Contexto: llevo bastantes años refinando este modelo en dos asignaturas de Ingeniería Informática en mi universidad, donde los estudiantes trabajan en equipos usando un enfoque ágil para desarrollar un producto software. Cada semestre lo aplico en alrededor de 15-20 equipos de 4-6 integrantes, con lo cual está bastante rodado aunque siempre es mejorable. La idea es comenzar a aplicarlo también en un ámbito de empresa donde se trabaje con el enfoque ágil. Vamos al tema ...
Al decir "evaluación de equipos que usan una metodología ágil" inmediatamente podrían surgir expresiones como "No es necesario hacer evaluaciones porque los equipos son autogestionados" o "Es el PO (Product Owner) el que evalúa al equipo en cuanto a su satisfacción con los resultados y el valor aportado". De forma similar, respecto de evaluaciones de integrantes del equipo podría decirse "Eso ya lo estamos comentando cuando surgen problemas". En parte estas expresiones son correctas pero en la práctica hay bastante margen de mejora respecto de cómo hacer dichas evaluaciones y cómo sacarles provecho.
El principal propósito de una evaluación de desempeño debería ser el orientar al personal hacia una mejora de su desempeño. Sin embargo, una evaluación de desempeño puede tener otros usos adicionales asociados a recompensas o penalizaciones para el equipo o sus integrantes. Con lo cual, en cuanto a la "justicia" de la evaluación, es conveniente que se formalice y sea transparente para todos los involucrados.
Es importante destacar, que a lo largo del tiempo un equipo y cualquiera de sus integrantes puede tener variaciones en su desempeño. Lo deseable es que el desempeño mejore, o si ya es satisfactorio se mantenga, y que los defectos en el desempeño se detecten y resuelvan oportunamente. Por esto, sería conveniente que la evaluación de rendimiento esté siempre abierta, es decir, que se pueda modificar en cualquier momento según las evidencias (positivas o negativas) que se vayan manifestando. Sin embargo, el análisis de las evaluaciones debería tener cierta frecuencia o podría estar alineada con hitos del trabajo (finalización de Sprint y/o de proyecto, entregas de trabajo, etc.), de manera que la detección de anomalías y puesta en marcha de acciones correctivas se haga oportunamente.
En la propuesta de roles de Scrum (accountabilities = responsabilidades, renombrado así en la última versión de la Scrum Guide) no existe la figura de "Jefe". El PO es la última palabra en lo que respecta a decisiones de negocio, el equipo autogestionado es quien decide respecto de lo técnico y el Scrum Master tiene autoridad en cuanto a la definición y aplicación de la metodología pero no es la última palabra ni en lo de negocio ni en lo técnico. Con lo cual cuando existen deficiencias en el desempeño del equipo y/o de sus integrantes, o cuando existen conflictos dentro del equipo y/o con el PO (o con el Scrum Master) se echaría en falta alguien que tuviese la autoridad para intervenir. Una opción razonable sería dejar esta tarea en manos del Scrum Master pues, aunque de forma indirecta, los problemas de rendimiento y conflictos son impedimentos para conseguir el máximo desempeño del equipo. De esta forma, el Scrum Master es quien debería también revisar periódicamente las evaluaciones y comentar posibles anomalías en la Reunión de Retrospectiva.
¿Pero qué es el desempeño?. La respuesta no es tan obvia como parece, pues son varios los interesados o posibles evaluadores del desempeño, y cada uno tiene una perspectiva diferente. Es decir, el contenido, forma, y frecuencia (el qué, cómo y cuándo) de la evaluación podría ser diferente.
En el marco de las responsabilidades propuestas por Scrum la siguiente imagen ilustra , se muestran las posibles evaluaciones de desempeño que podríamos establecer.
El PO evaluaría el resultado conseguido por los desarrolladores. Podría hacerlo después de cada Sprint o cada cierto período de tiempo, y adicionalmente, si se trata de un proyecto, se podría hacer cuando termine el proyecto. Por contraparte y opcionalmente, el equipo también podría evaluar el desempeño del PO.
El resto de las evaluaciones tiene ya un espacio bien definido en Scrum; son las
Reuniones de Retrospectiva, que deberían realizarse al finalizar un Sprint o si no se trabaja con Sprints, debería hacerse con una cierta regularidad.
La evaluación por parte del Scrum Master estaría orientada a detectar y resolver impedimentos, y a establecer mejoras en la metodología de trabajo del equipo. Por contraparte y opcionalmente, el equipo también podría evaluar el desempeño del Scrum Master. En cuanto a los impedimentos, el Scrum Master y el equipo tienen la oportunidad de detectarlos en las Reuniones Diarias (Daily Meeting) pero aquello que no tenga una solución sencilla o inmediata se puede trasladar a la Reunión de Retrospectiva. La evaluación hecha por el Scrum Master estaría asociada principalmente a la gestión de las prácticas ágiles aplicadas por el equipo en su trabajo, orientando respecto del refinamiento de las prácticas ya implantadas.
Además, sería responsabilidad de Scrum Master el establecimiento de un adecuado sistema de evaluación de desempeño, ya que es parte de lo que se espera de él o ella en cuanto a ofrecer un buen servicio de apoyo para mejora de los métodos de trabajo.
La Autoevaluación y Coevaluación interna de los Desarrolladores deberían estar alineadas, es decir, tanto en contenido, forma, y frecuencia podrían coincidir, la diferencia obvia es que una evaluación representa cómo se ve una persona y la otra es cómo la ven sus compañeras/os de trabajo. Estas evaluaciones podrían actualizarse regularmente en cada Sprint o cada cierto tiempo, pero es importante que además estén disponibles para su modificación en cualquier momento para poder reflejar alguna evidencia puntual durante cualquier día de trabajo.
Resumen de esta propuesta de modelo para evaluación de desempeño:
- Es un sistema de evaluación y mejora orientado a equipos y sus integrantes, trabajando con un enfoque ágil.
- Se trata de una evaluación continua, las evaluaciones y su análisis lo pueden hacer en cualquier momento los interesados.
- Se basa en baremos específicos configurables según los intereses de los evaluadores. Esto permite enfrentar dos aspectos clave: los equipos evolucionan (Modelo Tuckman para explicar el desarrollo de los equipos), y por otra parte, las personas pueden tener diversas fortalezas (y debilidades), lo importante es que en conjunto se complementen para formar un buen equipo (Roles de Belbin). No es necesario ni conveniente forzar a que una persona destaque en todas las competencias, y por contraparte, sí que es importante verificar que todos los Roles de Belbin sean cubiertos al sumar los Roles de Belbin de los miembros del equipo.
- Incluye evaluación del equipo por el PO y el Scrum Master, opcionalmente considera la evaluación del PO y Scrum Master por parte de los miembros de equipo, e incluye autoevaluación y coevaluación entre los colaboradores en un equipo.
- Considera la posibilidad "no evidencia" en algunos aspectos de los baremos de evaluación. Es decir, puede que en un cierto momento un evaluador no tenga suficientes evidencias para valorar algún ítem del baremo.
- Aunque podría utilizarse en un nivel directivo la intención original es evaluar equipos y personas en el nivel operativo.
- No es un sistema para evaluación uniforme, no lo es respecto de los baremos de evaluación, ni tampoco lo es respecto de las propias valoraciones. Esto último se debe a que es muy difícil garantizar una total objetividad, y menos que una evaluación de equipo o entre personas de distintos equipos sea comparable.
- El propósito es detectar e intentar resolver situaciones anómalas oportunamente. Sin embargo, este sistema podría utilizarse para recompensar o penalizar a las personas pero hay que tener en cuenta la posible lo anteriormente indicado; la no uniformidad de las evaluaciones, especialmente entre distintos equipos.
- La evaluación realizada por los colaboradores es anónima, cada Desarrollador no conoce las evaluaciones que le han hecho sus compañeros, solo ve el promedio ponderado. Sin embargo, el Scrum Master sí que tiene toda la visibilidad y con ello puede moderar una parte de la Reunión de Retrospectiva donde comente con el equipos las evaluaciones individuales.
Tenemos gran parte del modelo ya implementado en una herramienta que hemos utilizado ya los dos últimos años. A continuación, se muestran algunas de las principales funcionalidades ya cubiertas.
La siguiente imagen corresponde a la interfaz en la cual cada persona evalúa a sus colaboradores directos, que corresponden a sus compañeros en los equipos en los cuales participa. Cada uno de sus colaboradores aparece como una columna.
El baremo de evaluación se estructura en Competencias y Dimensiones (primera columna de la imagen). Tanto las competencias como sus dimensiones son configurables, en este ejemplo se han establecido cuatro competencias y cada una de ellas con tres dimensiones. La evaluación puede hacerse por rúbricas (guías para otorgar cada valor de la escala) o como en la imagen, simplemente planteando una afirmación y ofreciendo una escala de Likert para evaluar. Las rúbricas y valores de escala de valoración también son configurables.
En la siguiente imagen se muestra la evaluación que haría un Scrum Master al equipo. A la izquierda se muestran las evaluaciones globales de cada Sprint, y seleccionando un Sprint se ve el detalle de la evaluación según el baremo establecido para ese Sprint. Como se observa, los ítems del baremo pueden tener diferentes pesos y de esas valoraciones se obtiene un promedio ponderado para cada Sprint.
Finalmente, cada integrante del equipo puede visualizar en una interfaz como la que se muestra a continuación con las evaluaciones que ha obtenido de sus colaboradores.
En la parte izquierda puede ver las evaluaciones que tiene su equipo en cada Sprint, y la evaluación promedio de sus colaboradores. En este caso, para ajustar la evaluación de la persona en un Sprint, se aplica una recompensa o penalización según la diferencia entre su evaluación ponderada de competencias y la evaluación promedio de sus colaboradores. Es decir, la valoración final contempla una recompensa por destacar positivamente o una penalización por destacar negativamente. Dado que la evaluación se mantiene abierta durante todo el proyecto, las personas que tengan un mal desempeño tienen la oportunidad de mejorar posteriormente pues la evaluación final es la que se considera para dicho ajuste.
Me atrevo a decir que en el contexto académico el modelo aquí ya ha demostrado ser eficaz. Más allá de permitir otorgar una calificación justa a los estudiantes, el modelo está permitiendo detectar tempranamente defectos en el funcionamiento de los equipos, ofreciendo orientación respecto de lo que se debe mejorar y motivando a hacerlo en los Sprints siguientes. Además, los resultados de una reciente encuesta hecha para recabar la opinión de los estudiantes respecto del método de evaluación arrojó los siguiente resultados (sobre 94 respuestas): el 87% está de acuerdo o totalmente de acuerdo en que el método de evaluación es justo, el 66% está de acuerdo o totalmente de acuerdo en que el método promueve la mejora en el rendimiento del equipo e individual (un 20% está indeciso), y el 94% está en desacuerdo o totalmente en desacuerdo en que el método creó algún conflicto en su equipo.
Por último, estamos recolectando la información del histórico de cambios en las evaluaciones, con lo cual pronto se podrá visualizar la evolución de las evaluaciones a nivel de competencias y dimensiones para cada persona.
No hay comentarios:
Publicar un comentario