Cómo recompensar al equipo de desarrollo que cumple o no hacerlo

Lo que me gusta de los blogs es que la gente puede departir, debatir, comentar y opinar respecto a las diferentes entradas que los bloggers escribimos.

Me gustaría que fueran más los comentarios que aparecen, más que nada porque estoy convencido y seguro de que todos tenemos algo que decir casi siempre, pero muchos no se atreven a hacerlo y es una lástima.

Sin embargo, he tenido la fortuna de leer un comentario en una entrada de Rodrigo Corral (que por otro lado recomiendo leer) en la que María Cecilia PeTri preguntaba algunos aspectos acerca de la motivación.

María preguntaba acerca de la motivación y en su caso concreto, en un proyecto con Scrum y un equipo de personas concreto.
Sus preguntas son sobre todo acercade si se debe recompensar al equipo de desarrollo que cumple sus objetivos en plazo o no.

Aunque en un principio pensaba responder en el blog de Rodrigo, posteriormente pensé que igual su comentario se merecía una entrada en mi blog, en el cuál ya he tratado en alguna ocasión el tema de la motivación.

Antes de comenzar a tratar la pregunta de María y mis respuestas, haré alusión a la entrada que escribí en Julio del 2008 acerca de el valor humano, la motivación y el sentirse valorado.

Indudablemente la motivación es fundamental, pero ojo con crear precedentes.
No es lo mismo recompensar por un proyecto que es un bloc de notas como el de Windows que por un proyecto estratégico para la compañía o por un proyecto de índole especial o incluso por un proyecto donde de antemano se sabe que requerirá un esfuerzo extra.
Esto debe ser tenido en cuenta siempre y los premios deben ser planteados como excepcionalidad siempre.

María en su intervención hacía el siguiente planteamiento:
¿Cómo recompensarían al equipo cuando terminan la iteración antes de tiempo? Este planteo surgió del equipo luego de varios sprints con los items cumplidos en tiempo total menor al estimado (Usamos SCRUM) Este planteo de solicitar recompensa surgió del equipo luego de varias iteraciones con los items terminados en un tiempo total menor al estimado.
a)¿Sería apropiado recompensar? ¿A individuos o al equipo?
b)¿Qué clase de recompensa sería apropiada? Dinero? Regalo?
c)Ante reiteradas oportunidades debería replantearse si la estimación fue hecha adecuadamente?
d)¿Debería esperarse a efectuar una revisión de calidad de los items cumplidos, para luego recompensar?
e)¿Debería realizarse una relación entre items cumplidos Vs Items defectuosos para luego recompensar? (por ejemplo, items que el product owner haya sugerido, y estos hayan sido, dependientes de otros items aun no incluidos o items definidos de forma que no fuera posible cumplir, u otro defecto que haya imposibilitado el desarrollo del item, aunque al momento de la planificación haya parecido apto.)
f) Cuando un miembro termina antes de tiempo, tiene la costumbre de ayudar a sus compañeros a terminar sus items. Y esto colabora con que el equipo completo termine antes de tiempo. En este caso ¿se debería premiar al individuo? ¿al equipo?
g) Otra posibilidad de recompensa es retirarse antes de la oficina el viernes.
Agradecería todas las sugerencias sobre este planteo. Gracias por el interés.

Voy a tratar de dar mi opinión al respecto, opinión que espero respete todo el mundo y que quizás alguno comparta en todos o en alguno de sus puntos, y que quizás otros no vean de esta manera.

Punto a): Por un lado, si varios sprints se cumplieron en un tiempo menor del estimado, es posible que lo que haya fallado es la estimación.
Por otro lado, no soy partidiario de recompensar los sprints finalizados, sino en su caso y al final del todo, el proyecto finalizado, que es diferente.
Respecto a premiar o recompensar a individuos o al equipo, creo que la pregunta contiene indirectamente su propia respuesta.
Si premias al individuo, estás sugiriendo una competición entre ellos que puede ser positiva y dañina al mismo tiempo, mientras que si incentivas al equipo estás valorando el trabajo en equipo y la consecución global de los objetivos.
Yo soy un fervoroso amante del trabajo en equipo.
En un equipo siempre habrá individuos más adaptados o más competentes que otros en diferentes ramas o tareas, pero sin el trabajo de todos, no se podrán conseguir los objetivos, y eso cuenta también.
Si no estás contenta con el equipo, haz como los equipos de futbol a final de temporada, cambia a los individuos no aptos para otros proyectos o gestiónalo de otra manera.
A veces una persona rinde más en un puesto que en otro, y esa visión es responsabilidad también del jefe de proyecto.
Si uno sabe apretar tuercas mejor que otro no le ponga a clavar clavos. A lo mejor clava clavos muy bien, pero donde se le sacará mejor provecho es en apretar tuercas. Quizás convenga que aprenda a clavar clavos, por lo que es seguro que al principio lo hará decentemente pero no suficiente y poco a poco vaya ejecutando su tarea de forma más brillante.
¿Es esa persona mejor que otra o hemos sido los responsables del equipo los que no hemos sabido sacar el máximo provecho a cada componente del equipo?. ¿Entendemos los límites de cada integrante del equipo y dónde desempeña mejor sus funciones o no debemos valorar a todos los integrantes del equipo por igual y mirar más sus conocimientos y limitaciones y en base a ellas valorar?.
Como ves, hay que hacer autocrítica también y a veces la culpa puede ser del director de orquesta que valora injustamente a cada miembro del equipo o no es consciente del rol que le está dando.

Punto b): Hablaré de mi experiencia una vez más.
En una ocasión y sin venir a cuento, a mí me regalaron un cheque para comprar lo que quisiera en unos grandes almacenes.
Eso ocurrió en Irlanda. En España no lo he visto nunca (puede haberlo pero no lo he visto nunca).
Hablando de ese mismo pais, comentaré algo que he contado en privado a mucha gente.
Tuve la oportunidad de conocer a algún manager de Oracle cuando estuve viviendo en aquel pais y me comentaron un día lo que hacían internamente.
El responsable del equipo tenía una bolsa de dinero mensual que administraba entre todos los miembros del equipo.
Cada responsable era el dueño de ese dinero y podía hacer con él lo que considerara oportuno (con lo que se considera un buen uso del mismo claro está).
Me contaron varias anécdotas todas muy dispares.
Uno de ellos prefería llevar todos los Viernes al final del trabajo a sus empleados (compañeros) a tomar pintas de cerveza. De esa manera estaban conversando en un ambiente más fluido y posiblemente desinibidos por el alcohol salían temas que de otra forma nunca se tratarían y ayudaban a mejorar el ambiente y resolver enganchones entre la gente, mejorar temas relativos al día a día, etc.
Otros managers preferían utilizar ese dinero en una comida o cena al final del mes con todos los integrantes del equipo.
Otros llevaban a la gente de fin de semana a algún sitio.
Algunos managers por su lado, hacían estas prácticas con independencia de los resultados. Otros sin embargo, no utilizaban ese dinero si el equipo no había logrado los objetivos.
Como podemos ver, cada responsable debe saber como gestionar este tema, pero siempre habrá daños colaterales.
Por ejemplo, un equipo sin premio habiendo integrantes que han cumplido es injusto para esos integrantes del equipo que han conseguido los objetivos marcados.
Del mismo modo, un equipo con premio habiendo integrantes que no han cumplido en absoluto, es injusto para esos integrantes que chupan rueda.
¿Qué recompensa es la más justa?
Siempre el tema económico es el más práctico porque para uno beber pintas será lo adecuado, mientras que para otros lo será tener una gratificación que le ayude a comprar ese gadget que había visto en la tienda.
Una vez más, lo más obvio es sondear al equipo, pero siempre y cuando se logren los objetivos, porque si lo haces antes pueden creer que se les va a gratificar sea cual sea la meta lograda.
En mi caso particular, yo siempre trato de hablar con la gente para ver que le gusta a cada uno, y así me hago una composición de lugar, pero es complicado y delicado tratar este tipo de temas.

No obstante, este punto tiene tras de sí un punto extra adicional que no se trata en muchas empresas, y es la de motivar al equipo.
No todas las empresas están dispuestas a llevar a cabo la práctica de las recompensas y mucho menos reservan una partida presupuestaria para este tipo de acciones.
Además, recuerdo una empresa española famosa en la que trabajé y con la que llegué al acuerdo de que si terminábamos en fecha un proyecto x recompensarían al equipo (10 personas) con una comida.
El proyecto se acabó y la comida nunca se produjo.
El resultado fue la desbandada de muchos de aquellos empleados a otras empresas.
Las promesas son para cumplirlas, sino, el empleado deja de creer y confiar en su propia empresa, así que ojo también con lo que se promete.

Punto c): Esta pregunta no la respondo porque no la entiendo.

Punto d): No soy partidiario de recompensar un conjunto de items y sí el proyecto.
De nada me sirve que un proyecto de 20 items (por poner un ejemplo mínimo pero esclarecedor) tenga 19 items de una calidad impresionante si al final el item pendiente hace que el proyecto fracase.
Un proyecto es un proyecto, y los items son partes indivisibles del proyecto que todas ellas juntas conforman el proyecto en sí.
Todos los items deben ser correctos y poseer la calidad y consecución concreta. Si fracasa un sólo item, el proyecto ha fracasado.

Punto e): Comparar items satisfactorios vs items defectuosos no es en mi opinión una medida adecuada.
Puede servir para detectar problemas o personas que no cumplen sus objetivos adecuadamente, pero nunca se deberían tomar para motivar o desmotivar.
Quizás, una persona que no cumpla sus objetivos adecuadamente requiera de una atención especial.
Quizás haya que motivarla de una forma diferente, o simplemente explicarla porqué lo hace mal y enseñarla a hacerlo bien.
Hay una frase del filósofo Lao-Tsé que decía: «Si das pescado a un hombre hambriento, le nutres una jornada. Si le enseñas a pescar, le nutrirás toda la vida.»
Con esto quiero argumentar que una persona necesita a veces ser enseñado para que sea autónomo.
Si el programador resuelve items que no estaban bien argumentados de inicio y sale adelante con ellos consiguiendo unos objetivos satisfactorios, es de agradecer, pero es en realidad el trabajo del programador.
Si es un fallo del Product Owner, igual al que hay que llamar la atención es al Product Owner, aunque espero que en ese caso, el Product Owner haya recibido de ese programador el feedback de que ese item estaba mal planteado.
Para la consecución satisfactoria del proyecto, los requerimientos deben estar bien cumplimentados y los items bien identificados, además de ser abordables y coherentes.

Punto f): Si un miembro termina antes de tiempo puede deberse a dos causas:
La primera que sus items están mal dimensionados.
La segunda que es una persona muy válida y extraordinaria.
En este punto, esa persona siempre podrá realizar diferentes tareas que sean del provecho personal o del equipo.
Puede utilizar ese tiempo para mejorar lo que ha realizado, auto-formarse, buscar mejoras, ayudar a otros compañeros, llevar a cabo tareas que se están dejando de lado en este momento pero que podría ir echando un vistazo, etc.
Lo más importante para mí en este caso, es que esa persona esté a gusto desempeñando esas tareas extra y que focalice en primer lugar sus esfuerzos en ayudar al equipo a conseguir las metas marcadas, y si las metas van por buen puerto, que realice tareas que le satisfagan y motiven.

Punto g): Retirarse antes de la oficina el viernes no me parece una recompensa adecuada.
Considero que cada integrante debe hacer sus horas semanales acordadas y si las ha hecho con exceso y ha terminado sus tareas, entonces es cierto que se puede ausentar, pero si ha terminado sus tareas a tiempo pero no ha cumplido sus horas semanales no tiene porqué ausentarse.
En Alemania por ejemplo está mal visto que la gente se quede más tiempo del que debe. Las tareas a acometer y los trabajos a desempeñar deben ser factibles, en caso contrario estarán mal dimensionados.
Una vez más, pondré como ejemplo mi experiencia en Irlanda, y es que cuando quería quedarme un rato más en el trabajo mis compañeros (irlandeses) tiraban de mí y me decían que no, que ya había cumplido.
Me chocó ver que en algunos paises no está bien visto hacer más horas (a excepción de casos muy especiales como es lógico).
El responsable del equipo debe saber qué hace con su gente y como la gestiona.
Yo he dado días libres a integrantes de mi equipo si veo que la persona cumple y que a lo mejor tiene que hacer asuntos personales, no se encuentra bien, o cualquier otro motivo.
En caso contrario, prefiero que esté trabajando echando un cable y si llega el caso que se vaya a casa antes que los demás, pero intentando evitar crear malos hábitos y comparaciones que no generen buen clima en el equipo.
Es muy difícil gestionar a las personas de un equipo y muy importante crear sinergias, ser claros y cumplir las promesas.

Espero que esta entrada genere un interesante debate acerca de cómo creéis que se debe motivar al equipo de desarrollo, así como en responder las preguntas que María hacía, ya que creo que son preguntas que nos podemos hacer con cierta frecuencia aunque no lo parezca.