Motivación Agile y Recompensas.

¿Recompensarían al equipo cuando terminan la iteración antes del tiempo estimado para el Sprint?

¿Cómo recompensarían al equipo cuando terminan la iteración antes de tiempo?

Este planteo, de solicitar recompensa, surgió del equipo luego de varias iteraciones con los items terminados en un tiempo total menor al estimado.

Para resolver esta cuestión, pedí opiniones en las comunidades ágiles más prestigiosas de la actualidad, e hice estas preguntas en sus foros.

Cuando se finaliza anticipadamente,

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.

Recibimos opiniones y sugerencias sobre este planteo, en distintos Foros Agiles en donde consultamos.

Este material vamos a desarrollarlo en una reunión en el equipo donde vamos a debatir el tema motivaciones y recompensas en entornos ágiles. Es el principio de nuestra investigación sobre Motivación y recompensas en SCRUM.

¿Recompensaría la finalización anticipada del Sprint? ¿Qué opina de las recompensas?

En el caso de decidir dar una recompensa, ¿Cuál sería?

Este es un extracto de la totalidad de respuestas.

• Definitivamente no recompensaría finalizar antes. No en Scrum.

• Sólo se debe recompensar al final del proyecto si el contrato así lo estipula, debería haber un diseño de contrato ágil donde si hay un ahorro de tiempo se compartan los beneficios entre el Product Owner y el equipo 50%/50%

• Sugerencia para una iteración tener historias de tres categorías, las que “tienen que terminarse”, “opcionales” y “de lujo” para que no se llegue al caso que se quedan sin trabajo en una iteración.

• No, ya que simplemente están cumpliendocon el compromiso y no, añadiendo ningún valor. El mismo ejemplo sirve en el caso que si repararan algún fallo, no debería haber premio ya que, lo finalmente hicieron es "volver a la normalidad".

• Un "No" rotundo!

• No, porque un equipo que termina antes de tiempo, o sobreestimó las tareas a realizar en el Sprint o habría que reajustar la velocidad del equipo en los siguientes Sprints.

• Por otra parte, si sobre los items ya terminados en aquellas iteraciones surgen cambios por errores, o porque no se habían detallado correctamente en la reunión de planificación de Sprint, posiblemente el equipo no supo indagar correctamente qué quería el Cliente. ¿deberán ser devueltas las recompensas recibidas?

• Y si el equipo en un Sprint no logra terminar a tiempo... ¿deberan pagar una penalización?

• Corresponde recompensar en otros casos. Son muchos los aspectos que creo que deberían tenerse en cuenta para poder establecer un sistema de recompensa.

• Quizás hay que ajustar la velocidad del equipo. Una recompensa no creo que deba depender de la velocidad estimada del equipo; se trata de un criterio muy frágil y, bajo mi punto de vista "cortoplazista". Hay que tener una visión más amplia y a largo plazo.

• Ya que es el propio equipo el que está solicitando la recompensa ¿Puede encubrir esta solicitud del equipo, otra clase de reivindicación? Seguro que el equipo conoce bien cómo funciona Scrum, así que seguro que saben que no es una reivindicación adecuada solicitar una recompensa por acabar antes los sprints, así que quizás sea conveniente rascar un poco y ver si hay algún asunto de fondo no resuelto previamente.

• Lo mejor es hablar claro con el equipo, manteniendo una postura firme en este sentido: no se puede recompensar lo que pretenden y muy probablemente el equipo lo sabe. Tal vez sería productivo, abrir un debate para ver si hay algo más que no ha salido a la superficie. Seguro se conseguirán pistas de cómo recompensarlos y se puede establecer cuándo hacerlo.

• Un consejo sería no pensar en cómo motivarlos, sino en cómo tener un ecosistema de trabajo que no desmotive.

• Es importante definir si el equipo hizo bien la estimación de tiempos durante la iteración, si esto sucede en pocas ocasiones, creo que puede estar dentro de los parámetros normales y optaría por la opción (g) es decir, permitir que se retiren antes el viernes, pero si se presenta en un par de ocasiones, podrá significar que el ritmo del equipo aumentó por algún motivo, quizás porque las tareas eran más sencillas de lo que se esperaba o hubo algún factor externo que generó esta eventualidad, por lo cual deberá de estar documentado, algo parecido a como se hace en PSP (Personal Software Process).

• Si sucede frecuentemente, tendrán que dar un valor agregado durante la iteración, ya que esto puede motivar a hacer estimaciones con alevosía y ventaja para obtener un mejor beneficio. Y en relación a la calidad del valor agregado que se diera cuando pasa este tipo de situaciones, entonces sí, podría evaluarse la posibilidad de un incentivo diferente a la opción (g), “volver a casa antes de tiempo, el viernes”.

• Por otro lado a veces los incentivos económicos pueden ser contraproducentes ya que las personas se acostumbran a los mismos y el día que no los reciban, dejan de hacer bien las actividades que tenían asignadas.

• Qué pasaría si también en equipo se definen las reglas del juego para los incentivos en caso de que fueran viables, pero también las amonestaciones en caso de que los integrantes se quieran pasar de vivos para obtener uno de ellos. Los incentivos tendrían que ser propuestos por el Scrum Master y negociados en el equipo. En alguna ocasión se planteaba en nuestro equipo de trabajo el hacer las reuniones en lugares diferentes a la oficina con el fin de cuando se terminara la reunión, se tuviera un momento de convivencia.

• Yo creo que lo primero en estos casos es actualizar el factor de foco del equipo. La alternativa (g) “irse a casa más temprano el viernes” yo creo que es la más adecuada principalmente porque el dejar al equipo en la oficina sin trabajo es casi como castigo por hacer bien su trabajo.

• Aunque en algunos comentarios digan que no se debe recompensar por el trabajo bien hecho, por hacer lo que se esperaba, o por arreglar un bug, yo discrepo con amplitud. en general y fuera de casos particulares, como filosofía general y esto no es Scrum, es pura gestión de equipos de trabajo, se debe intentar recompensar siempre y de forma lo más constante posible. Ah! pero esto no significa dinero ni regalos. Puede ser un comentario en público, quizás en la próxima reunión donde esté el PO. Reconocimiento, felicitaciones, señalar el buen trabajo individual o del equipo, comentarlo delante de todos. “No hay nada más venenoso que trabajar y que sólo se acuerden de ti cuando hay problemas o te equivocas”.

• Si se terminó antes porque se sobre-estimó no es para felicitar y el hecho de que lo exija el propio equipo no suena muy bien porque quien pide la recompensa el mismo que controla las condiciones para obtenerla (en Scrum el equipo es quien decide que entra al Sprint) lo cual es absurdo.

• Otra cosa es que el Product Owner dijera, "bien, admito que en este Sprint sólo pueden entrar las funcionalidades A,B y C pero si lográis que estuviera también la D intentaremos algún tipo de recompensa porque es una funcionalidad muy importante" (el ScrumMaster podría decir: "entonces ponle más prioridad" pero esto es otra batalla).

• Recompensar económicamente parece ser una solución que produce resultados a corto plazo, pero el impacto a medio-largo plazo puede ser perjudicial.

• Creo que si el equipo termina antes de lo previsto, de forma general, es que tal vez haya que revisar la forma de establecer los sprints. O el equipo estima con demasiada prudencia o subestima su velocidad.

• Acabar antes es un buen indicio de productividad, pero no el único. Habría que valorar también el grado de satisfacción del cliente ante lo entregado, el número de incidencias a posteriori y la facilidad de mantener lo creado. Es decir, hacer las cosas más rápidamente, para simplemente acabar antes, no tiene por qué ser sinónimo de calidad.

• Soy de la opinión de que, si un equipo termina antes con su trabajo, lo que necesita es más trabajo. A mayor producción, mayor rentabilidad de la empresa, y mejores resultados obtenidos. Lo que ocurre es que, si ante mayor rentabilidad, los beneficios no llegan a quienes están haciendo ese esfuerzo, mal vamos, porque dejamos de alimentar el motor de nuestra fábrica. Dicho de otra manera, no premiaría económicamente por acabar antes... en su lugar, plantearía implicar al personal en la cuenta de resultados global. Por supuesto, es un planteamiento un tanto idealista... pero parece el más justo a largo plazo.

• Siendo un poquito más pragmáticos, una solución relativamente cómoda y sobre la que seguramente tendrás margen de acción, es establecer otros proyectos, con un carácter más interno (tal vez I+D). Si el equipo termina antes de lo establecido, en lugar de irse antes los viernes, que dediquen ese tiempo ganado a reuniones productivas de su ámbito, o a avanzar en proyectos que les apasionen personalmente. Trata de alimentar la pasión de aquellos programadores que sí tienen talento, diferenciándolos de aquellos que tienden más hacia la comisión económica, porque son los primeros los que te aportarán mejores resultados a la larga. Además, si consigues que esos proyectos internos tengan un mínimo de aplicabilidad comercial de tu empresa... enhorabuena, estás comenzando a replicar el modelo google.

• Ojo con las recompensas... a menudo son dañinas. Cuestionada la idoneidad de compensar, el resto de preguntas carecen de respuesta. Si se quiere recompensar a la gente lo mejor es darle más autonomía, más retos, más libertad... más que cosas materiales.

• Personalmente opino que las recompensas, prefiero denominarlas gratificaciones, hay que usarlas con muchísimo cuidado, crean precedentes y derivan en envidias con otros equipos. En los proyectos que he dirigido (infinidad) he usado tan solo en uno gratificaciones económicas pero obligado a acortar los Sprints de forma drástica, dado que el equipo se involucraba a trabajar a "destajo" para finalizar los Sprints recortados y de alguna manera había que MOTIVARLOS. El resto de proyectos NO, dado que se supone que en la metodología ágil un equipo debe tener las características de ser Auto-implicado y Auto-responsable y por lo tanto no necesita de gratificaciones "extras" puesto que su mayor recompensa es cumplir los Sprints con tiempo y calidad y la finalización del proyecto con éxito, como comandos de élite que son su recompensa es: "La satisfacción del deber bien cumplido". Si que es cierto, que en otros casos, a la finalización del proyecto con éxito, les invitaba a comer o cenar (paga la empresa) para fortalecer el equipo y aprovechar a crear mas unión y fuerza. SI, se pueden usar las gratificaciones económicas o días de vacaciones pero en ocasiones extremas, en el resto, pero solo de vez en cuando, si el equipo es bueno agradecérselo con invitaciones de comidas o cenas.

• Una alternativa es celebrarlo, un pequeño homenaje después de la mañana de trabajo. Y a la hora H realizar una salida o actividad que sirva para reforzar los lazos del equipo y reírnos de los momentos difíciles que nacen a lo largo de los sprints. En ocasiones, dependiendo del valor estratégico del proyecto, de la facturación y de otros factores, invitar a gente de otras áreas de la empresa.

• Cuando fallan el sprint en reiteradas ocasiones quisieron ser castigados? Me imagino que no. En mi opinión, si continuamente se consigue acabar el sprint con anterioridad, se debería de analizar el porqué, seguramente por sobre-estimar en el sprint planning. Yo creo que un sprint es solo una parte de un todo y estaría más a favor de recompensar si el proyecto ejecutado se finaliza con satisfacción sin mirar a los sprints de manera individual.

• En mi empresa, siempre añadimos un par de historias al sprint backlog que solo se deberán abordar en le caso de que todo lo anterior se haya acabado correctamente.

• Si un sprint acaba antes de tiempo puede ser debido a que no se ha valorado correctamente. Se puede premiar al equipo con tareas no planificadas, refactoring sobre calidad del desarrollo, u otras mejoras del proceso, Eso sí la retrospectiva que sea amena y si podéis conjugar con un buen almuerzo mejor, ya habrá hitos para celebrar.

• Aqui está el ejemplo de una experiencia en una empresa.La oportunidad coincidio con una semifinal del mundial baloncesto. Como recompensa a un sprint bien hecho y en tiempo, la empresa decidió darnos un par de horas libres para ver el partido. Lógicamente, a las personas a las cuales no se les dio esa oportunidad mostraron su malestar. Se decidió dar permiso a todo el mundo para ir a ver el partido Hubo mucha gente, que no tenia ningún interés en el partido de baloncesto y mostró su desconcierto ya que ellos por ejemplo no tenían tiempo libre como para disfrutar de otras cosas. Una persona dijo que hubiera preferido esas dos horas para irse de compras! En definitiva: no fuimos a ver el partido. Conclusión: Hay que tener mucho cuidado con las recompensas que se dan, ya que puede que no sean del agrado de todos.

• No pensar en cómo motivarlos, sino en cómo tener un ecosistema de trabajo que no desmotive.

• La mejor opción es recompensar el trabajo bien hecho. Motivar lo bueno, recompensar y distinguir el bien hacer. Hay pocas formas de motivación más poderosas que el refuerzo positivo.

• Tener mucho cuidado con las recompensas económicas. Porque, como decian en Shogun "Es muy facil entregar un feudo, e imposible quitarlo". Yo creo que es mejor sacar de la ecuación el dinero, pagando lo suficiente para que el trabajador deje de pensar en el. Y utilizar las infinitas modalidades de motivación que existen.

• Una iteración no puede terminar antes de tiempo. La iteración es una unidad de tiempo (como 2 semanas, por ejemplo) ¿cómo pueden 2 semanas terminar antes de 2 semanas? Si lo que quiere preguntarse es “¿cómo premiar al equipo que termina antes de lo estimado?” sugiero cambiar la redacción de la pregunta.

• Las prácticas ágiles prefieren “terminar tareas” vs. “planificar tareas” entonces por qué debería alguien quedar sin trabajo en una iteración? simplemente elegir una de las tareas del backlog.

• Más que “recompensa” y “ahorro” la idea es que exista motivación constante para que el equipo de desarrollo siempre trabaje bien (calidad vs. terminar antes de tiempo) Ejemplo clásico, jefe dice “si terminamos antes de tiempo habrá un bono”… entonces, los desarrolladores terminan rápido su tarea pero sin probar bien ni asegurar su calidad… recibieron su bono, pero el software no quedo de calidad…

• Hay que tener cuidado con cosas de este estilo, porque genera incentivos perversos para sobreestimar.

• Una situación recomendable es siempre celebrar al término de los proyectos (por eso hay que evitar los proyectos indefinidos… se deben terminar en algún momento y después pueden pasan a fase de soporte/mantenimiento).

• Planes de desarrollo profesional, sueldos justos asociado a un esquema de promoción claro y jornadas de trabajo apropiadas, son las primeras cosas que hay que conseguir… una vez resuelto esto de forma excelente, se puede hablar de incentivos especiales.

• No. Me parece una falta de respeto ofrecerle a un profesional recompensa por el trabajo bien hecho. Es como tratar de traer la cultura de bonos de Wall Street a los equipos de desarrollo de software.

• Ahora a lo práctico. En agilidad existe la noción de Holgura (Slack). Es decir todas las iteraciones deben terminar antes de la fecha, con un poco de tiempo para programadores para refactorizar, leer, escuchar podcast es decir trabajar en mejorar sus habilidades etc.

• en realidad aca hay 2 preguntas, una es (a) “como premiar al equipo que termina antes de lo estimado?” y la otra es (b) “como replantearse lo estimado si el equipo termina antes en reiteradas oportunidades?”.

• Buscando una forma de premiar al equipo que termina antes de lo estimado, hay un muy buen articulo acerca de “nerd herding” en el siguiente de donde sacar ideas para “recompensas”… que en realidad debería ser algo periódico y no sólo después de cumplir algún hito.

• Sobre replantearse lo estimado si el equipo termina antes en reiteradas oportunidades, tener en cuenta que la idea de las practicas ágiles no es “planificar las tareas” sino “terminar las tareas”. por lo tanto, si alguien termina una tarea a mitad de semana, que le impide empezar (y terminar) otra?

• revisaría la estimación, en primer lugar, pero aún así,, si se ha estimado por debajo de la capacidad del equipo, y se termina el trabajo, en principio, asignado al *sprint*, debe haber siempre algo más de trabajo estimado en la recámara para continuar hasta el siguiente *sprint*.

• Tema de la recompensa, hay muchos debates al respecto, creo que es un tema muy peligroso, lo que se puede conseguir con esa recompensa es crear competitividad en el equipo y obtener resultados totalmente opuestos a los buscados, sobre todo si se premia a un sólo individuo, ¿premias al que más tickets completa? ¿al que más líneas de código escribe? ¿al que más pruebas de test realiza y supera sin error? .... es complicado elegir un criterio justo de premiar, y aunque lo hubiera, no creo que se consiguieran buenos resultados así.

• Si bien el compromiso del contrato ágil es para ambas partes por igual, aprovecharía el tiempo en mejorar la calidad general de la aplicación hacer ese refactor que quedó olvidado en un sprint anterior que acabamos justos y si hemos infravalorado MUCHO la productividad del equipo tratar de incluir alguna historia más en el sprint.

• No premiaría nunca por acabar antes un sprint, en todo caso lo haría por haber mejorado sustancialmente la calidad del producto con el tiempo restante. Y por supuesto en la próxima retrospectiva habría que ver con el equipo porqué de la sobre-estimación. De todas formas si el trabajo es bueno continuadamente porque no salir algún dia antes? eso anima al equipo, pero que no se convierta nunca en el objetivo.

• Ninguna, Existe el famoso peligro de que al intentar optimizar un parametro (tiempo por dinero), fastidies todos los otros. (Never sub-optimize) Expandiendolo un poco mas, a sabiendas que terminando pronto se consigue dinero, pues "se termina pronto" y punto: falsas estimaciones, "QTDPC yo hoy estoy a terminar esto", etc etc.

• Para premiar al equipo se deberían buscar medidas que ellos mismos no puedan afectar directamente. No hay una medida mágica para todo el equipo. Cada miembro del equipo tiene puntos fuertes y puntos débiles. Para eso esta el team leader, para "VER" en cada uno lo que falla, intentar fomentar una mejora, y valorar "a ojo de buen cubero" el esfuerzo realizado en esa mejora.

• No parece buena idea ir por la línea de la recompensa. Se debe estar atentos al seguimiento de productividad durante y al final de cada iteración. Al final, después de cada reunión post-iteración, a la vista de resultados se intenta mejorar en las estimaciones, a veces se reorganizan los equipos, etc.

• Estoy de acuerdo en que premiar individualmente conlleva bastante riesgo. Al final parecería que cada desarrollador, en plan mercenario, echa líneas a destajo, o cualquier otro acto que esté a su alcance. Otra cosa sería recompensar por éxito en un proyecto o una entrega de suficiente duración como para que la recompensa sea considerada por el esfuerzo constante.

• Lo primero, seria intentar corregir esa desviación aumentando la velocidad del equipo y si son solo Sprint puntuales, meter alguna tarea de la pila de producto. El fin y al cabo, la finalidad es dar valor al producto y con esto no desperdiciaríamos tiempo del equipo sin hacer nada. Nosotros tenemos un rincón en el tablero kanban donde ponemos las dos posibles tareas a hacer si algún miembro del equipo termina.

• Una idea: que cada equipo de Scrum, elija un proyecto personal a hacer, por el que todos se sintieran motivados. Es decir, decidir entre todo el equipo, algo que les apetezca hacer a todos, como por ejemplo una impresora de lego, un helicóptero controlado por programa, un robot programable que baile al ritmo de la música, y a ser posible algo relacionado con la investigación dentro del ámbito de la empresa. Algo que a todos les hiciera gracia y que estuvieran dispuestos a terminar. Entonces tomas este proyecto y lo dejan como proyecto para ratos libres, cafes, horas de comida, horas extras (hay quien las hace con gusto), ratos libres. Dejando claro, lógicamente, que este proyecto, no debe interferir en absoluto con las tareas de los sprints. Esto seria muy motivador para el equipo, haciéndose un equipo mucho más unido. También haciendo ver al resto de la empresa, que no solo se lleva bien el proyecto, sino que a parte, la gente se mueve y hace cosas entretenidas y novedosas.

• En una empresa en la que trabajé en Madrid, nos quedábamos casi todos, cada vez que algún miembro del equipo estaba liado con algo, y mientras él terminaba, nosotros programábamos un lanza-misiles de lego con webcam, aparte de hacerle compañía y ayudarle cuando lo necesitara. Pero bueno, esto también puede ser peligroso y hacer que el equipo quiera terminar las tareas cuanto antes, para ponerse con el proyecto recreativo :P

• si en un sprint, el equipo termina (es decir, no quedan bugs por resolver) con todos los requerimientos comprometidos para ese sprint, seguramente puede avanzar con los siguientes requerimientos del backlog.

• Significa que la velocidad del equipo es más alta de lo que se había estimado, entonces para el siguiente sprint se pueden comprometer a hacer más requerimientos (o más complejos).

• No medir el éxito por un sprint particular, sino por todo el proyecto y mirando todos los aspectos (alcance, calidad, tiempos, costo, y fundamentalmente la satisfacción de todos los involucrados.

• No alentaría que el equipo quiera "terminar antes" si eso implica "terminar a medias".

• No premiaría individualidades, sino logros colectivos. Si hay una diferencia notoria entre el compromiso de unos y de otros, entonces es un síntoma de que algo anda mal en el equipo... y ese problema me parece que no se resuelve premiando a los más comprometidos, sino trabajando en la motivación/rendimiento de los que menos acompañan.

• Si el proyecto finalmente es súper exitoso, el cliente quedó súper satisfecho, el costo fue menor al presupuestado, se terminó antes y todos los involucrados quedaron contentos con lo que aprendieron durante el proyecto... bueno eso ya es un lindo premio, no? Aún así, si el equipo necesita un premio material para que esta experiencia grandiosa (y poco frecuente) se vuelva a repetir... me parece que está bueno premiar, de la forma que mejor sea recibido por el equipo (no todas las personas quieren lo mismo).

• Es un error asociar el cumplimiento anticipado de lo comprometido con el buen funcionamiento del equipo. Demostrando por el absurdo: si son recompensados cuanto tenrminan antes, deberian ser castigados si no terminan tarde? Yo veo la conclusion antes de tiempo, si se produce repetidamente, como un error en el calculo de "velocity" del equipo y deberia ser ajustado (incluyendo mas story points en el proximo sprint). Por otro lado, el equipo deberia ser SIEMPRE reconocido y manejar los problemas o discordancias en la IR (iteration review).

• Si esta situación se repite, como dice Carlos, se debe replantear la velocidad: Ante reiteradas oportunidades debería replantearse si la estimación fue hecha adecuadamente. Puede que la estimación haya sido demasiado pesimista, o que la velocidad del equipo es superior. En cualquiera de los casos hay algo por mejorar, ya sea, aprendemos a estimar mas ajustadamente, o bien recalculamos la velocidad del equipo y nos comprometemos a más story points para la próxima.

• Antes de pensar en recompensar yo revisaría lo siguiente porque me hace bastante ruido: ¿Debería esperarse a efectuar una revisión de calidad de los items cumplidos, para luego recompensar? Primero, si no hay revisión de calidad de los items, ¿Como sabemos que están cumplidos? ¿Como sabemos que terminamos si no estamos seguros que no hay defectos? Si hay un defecto, hay retrabajo, es algo que no se terminó adecuadamente. Si este retrabajo no lo hago durante la iteración, ¿Cuando lo hago? En cualquier caso hay un costo asociado.

• Y por último, me suena que también hay algunas cosas para mejorar en la planificacion: ante la pregunta “¿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.)” Teoricamente se debería evitar las dependencias, pero en la realidad existen. Lo que se debe hacer es analizar las dependencia y no incluir en un sprint un item que es dependiente de otro que no se incluyó. Si hay historias que no están adecuadamente definidas, debo trabajar antes de la iteración (o bien durante la misma) para definirlas adecuadamente de forma que se puedan cumplir. Si incluyo en el sprint un item que está mal definido y no lo puedo completar durante la iteración, esa iteración falló, no puedo decir que terminé todo antes "exepto por la historia X que no estaba bien definida".

• No corresponden recompensas, y menos por objetivos parciales a corto plazo, el foco del equipo puede pasar de ser alcanzar los fines globales del proyecto a alcanzar pequeñas metas parciales que no tienen porque estar alineadas con el objetivo final, muy peligroso.

• Son absurdas las recompensas extras a alguien por hacer bien su trabajo, ¿no es suficiente compensación el sueldo que recibe y la satisfacción por el trabajo bien hecho?, si el equipo considera que necesita "extras" quizás es porque su salario es insuficiente.

• ¿cual es el objetivo de estas recompensas?, ¿mejorar la motivación del equipo?, las recompensas externas no mejoran la motivación ni el desempeño de los equipos, lo hacen las motivaciones intrínsecas, al menos en trabajos como el software no recompensan las políticas de motivación con el palo y la zanahoria.

• Una iteración es un “invento” de tu proceso, ya que no se venden Sprints, sino proyectos terminados que maximizan valor para el cliente y retorno, yo premiaría eso.

• Si sigues estimando así, posiblemente termines dejando de ser competitivo contra otro equipo que corrija las estimaciones en vez de gastar en premios. Así es la ley de la selva.

• En base a las recompensas; a) Cuando el objetivo es cumplido por el equipo (dependerá el equipo), algunas veces es necesario recompensar a través de motivación. Evidentemente debe recompensar al equipo, ya que el logro es de todos (a diferencia de un grupo). b) La mayoría de las motivaciones con caras de recompensa, pueden ser de muchas maneras. Una opción es algo agradable al común del equipo. Por ejemplo, una silla de masajes, algún elemento de entretención, con el objetivo de que vaya enfocado al equipo de trabajo y que todos puedan disfrutar del premio.

• El scrum master podría medir la efectividad de la estimación.

• Sobre el tema estimación, tendría que ajustarse el factor de foco del equipo, si usan Scrum, con lo cual en pocas iteraciones debería tender a estabilizarse la velocidad hasta encontrar su ritmo sustentable.

• Es más apropiado recompensar por "exceder las expectativas", por hacer un aporte extra que beneficie al equipo (y no tanto por cumplir con el compromiso, que en última instancia es lo que entiendo estás planteando). Es decir, no estaría seguro de recompensar por "terminar antes" a menos que haya existido un esfuerzo extraordinario para lograr ese objetivo; preferiría generar una cultura donde el equipo siempre realice el mejor trabajo posible, terminando lo antes posible (¿no sería acaso lo que siempre debería ocurrir? esto surge de una cultura que valora la integridad y compromiso).

• Si el equipo realizó un esfuerzo extraordinario o generó algo novedoso que excedió expectativas, sería el logro del equipo (y no de un individuo), por lo que la "recompensa" tendría que ser al equipo completo. Quizás incluso se pueda utilizar esta misma recompensa como un medio más de unión y conformación del equipo. Por ejemplo (y lo que sigue depende también mucho de la cultura del equipo): ¿por qué no regalarles un almuerzo a todos en algún lugar interesante? ¿O qué pasaría si se le regala 1 único cupón de compra en algún local (con un monto razonable) con la condición que tienen que comprar 1 cosa para cada miembro? Ideas, ideas...

• La motivación se debe dividir en dos escenarios: "el profesional" y "el laboral" En el aspecto "profesional" se hacen cosas como pagar un mayor sueldo al que presenta un mayor nivel profesional y lo demuestra, mientras que en el aspecto "laboral" se debe recompensar al equipo en su totalidad, pues en SCRUM el equipo es un solo ser (no se le regala un anillo a un dedo porque él sobresale de los demás......se le regala a la persona en sí). El trabajo que hace una persona en SCRUM puede depender del buen trabajo que hacen los demás y que tal vez no se nota tanto.

• Sobre el tema de los incentivos hay que manejarlos con mucho cuidado. Es posible que a corto plazo funcionen, pero si no se tiene cuidado, el efecto a medio/largo plazo podría ser el opuesto. No son positivo los premios individuales y en dinero. Creo que eso es lo más perjudicial, porque fomenta la competitividad individual, y el desarrollo de software, y más en la agilidad, es un juego de equipo.

• A lo mejor el enfoque no es premiar por acabar antes de lo estimado, si no por otro tipo de objetivos.

• La estimación no es una ciencia exacta. Si lo fuera, algo estimado en 4 horas sería muy difícil hacerlo en 3 y muy improbable hacerlo en 5. Y todos sabemos que una tarea de software estimada en 4 puede resolverse tanto en 1 como en 10 horas: hay muchos factores que influyen. Así que sabiendo que la estimación no es un valor absoluto, sino una aproximación, no debemos premiar ni castigar las desviaciones, porque lo natural es desviarse, así que estaríamos premiando/castigando un comportamiento natural. Es más: no hay que premiar la exactitud de la estimación, porque nuestro objetivo no es tener estimaciones muy exactas, sino el valor que está aportando el equipo a la empresa.

• Si en un negocio/empresa/mercado se considera que la exactitud de la estimación es lo más importante, entonces las metodologías ágiles le van a traer más problemas que beneficios, porque precisamente lo que dan es más valor al producto a costa de dar más incertidumbre)

• Por eso te proponía que quizá la opción sea premiar objetivos de otro tipo: alcanzar cierta cuota de calidad, llegar a ciertos objetivos de empresa, proponer ideas de mejora (del producto, del proceso, de la empresa), proponer soluciones efectivas a problemas, etc. Esos objetivos no son tan fáciles de falsear (es muy fácil inflar las estimaciones, o sacrificar otros factores, como la calidad) y tienen también efectos beneficiosos tanto para los "premiados" como para la empresa.

• Es peligroso. Hay un artículo acerca de pagar el salario respecto a los puntos de historia que complete cada desarrollador y es igual de peligroso. El equipo es tanto responsable de asignar puntos de historia como de completarlos por lo que si tienen algun premio si acaban antes, pueden tender a estimar las historias con más puntos de los que realmente tienen.

• La recompensa económica es un efecto motivador a corto plazo y el establecer recompensas particulares hay que manejarlo con mucho cuidado dentro de un equipo multidisciplinar para que no tenga un efecto desestabilizador/ desmotivador.

• En cuanto al tipo de recompensa depende mucho del equipo y hay que conocerlos bien para determinar qué puede ser estimulante o motivador para ellos, porque recompensas hay de muchas clases. Lo ideal sería recompensar a un equipo con algo que fomente aún más su compenetración como equipo.

• Acabar antes las tareas no debe ser el único criterio ni el principal ya que, puede ser un tema de sobreestimación. Lo que es acabar antes con una velocidad determinada es acabar más tarde con otra velocidad. Es un criterio muy frágil para establecer una recompensa.

• Del mismo modo que Ud. no castiga a alguien por llegar tarde, por lo general tampoco les recompensa por terminar temprano. Se deberá tratar en la retrospectiva, el tema de la pronta finalización, como lo haría con cualquier otra situación imprevista del sprint. Examine de forma coherente, lo que ocurrió para haber llevado al equipo a una sobre-estimación de su trabajo. El objetivo del ejercicio de estimación no es para superar continuamente sus conjeturas, sino para ser más precisos y consistentes.

• Excellent point. Both, positive and negative slips should be analyzed for lessons learned. That said, the team members may feel like they accomplished something exceptional. To not acknowledge the achievement risks team morale in some cases. Personally, I'd reward them if they executed in a manner above expectations. If it wasn't an anomaly and they generally improved, then I'd give a monetary reward/time off reward with a re-leveling of story points after. That said, if they worked extra hours to meet that goal (with or without management enforcement), then they are skewing the process and a reward is not necessary nor productive.

• Recompensaría con dinero al equipo. Rewarding team is best idea with bonus money .

• I think due recognition should be given if an iteration is completed before time. However, I believe specific tangible rewards are more appropriate if this out performance is seen across multiple iterations, thereby helping the project finishing ahead of schedule and without additional effort. This would mean that the client would be able to generate business value from the solution earlier than planned. Hence, my suggestion would be to explore if the client can sponsor the reward.

• Although more money is always a nice thing, in practice it proves to be a rather ineffective motivator. If you are going to reward the team, and you should only do so if their actual behavior was worthy of being rewarded, then find something that they actually value (which may in fact be money) that will motivate desired behavior in the future.

• one could always introduce enterprisey practices into the SCRUM by encouraging people who finish early to spend time on personal development and "charging" the project

• The trouble is you don't want to create an incentive for "padding" or purposefully reducing the story point velocity of the team. Personal development activities should be a part of the professional development plan for each employee and worked into their own time management activities. The same goes for "interrupts" like production support, team meetings, or other non-project related activities. If you're working on a long-term project, early completion can be as damaging to building customer trust as being tardy. The point is consistency and accuracy, so early completion is just another time the team missed the goal for some reason. Of course if you are working as an independent or third-party contractor on a delivery based fee structure with bonuses or fines built in for early or late completion, then definitely give your team something nice if they complete early and rake in that bonus from the customer.

• Finishing stories early is something to celebrate! Assuming the sprint is actually done, defect-free, and accepted by the customer early, recognize it with verbal appreciation. We don't want to be 'punished by rewards', that is, to give incentives for over-estimation--but we do want to encourage and value good work. We also want to keep energy high by giving specific, positive feedback when we have the opportunity. Who cares if we over-estimate some times? If the team is up to it, they can cut a release candidate, then add another story to the sprint. If they get done, extra credit! Estimates are a planning tool--not a contract.

• To make the situation more obvious, let's look at it from the other side. Imagine the scenario in which the team invests its best efforts to complete all the committed stories in time - but, alas, they're out of luck. Let's say, they struggled to stabilize the integration environment - and couldn't complete that before the sprint has finished. Would you punish them? I think they rather deserve all the possible rewards and incentives, and to a much greater degree than if they've finished before time. I truly believe that a good manager should reward the effort, not the results. Because the end results, while they are THE most important for the business in the long run, may not necessarily reflect the effort and the commitment of the team. And this works in both directions: if a team consistently underperforms, despite all the invested efforts - there IS something wrong, and that should be flashed out at the retrospective. But if a team outperforms the plan, consistently, for a number of sprints in a row - there's something seriously wrong too!

- The stories may be overestimated ("story point inflation"); they may have to be re-estimated then.

- The team may be bad at planning the sprints and tasking out the stories. By the way, could it be that your team commits to stories based on the story points number, and not the amount of actual work planned?

- The team may be afraid of not delivering on their commitments, and hence undercommits.

- The team members may (unnecessarily!) work extra hours to complete all the stories in or ahead of the time. In such case they may run into attrition problems soon.

Anyway, sprint planning is not a precise science. Just as story estimation isn't. This will, inevitably, lead to some statistical distribution of sprint results - sometimes the team will finish early, sometime - they will not complete all the work in time, but in most of the sprints they should be able to reach the end of sprint with all the stories completed just in time for the demo, plus-minus a few hours.

That is the norm, that should be asked for. Whether or not the organization should reward the team that meets the expectations - now, that's a totally different discussion ;-)

• I'm wondering a bit. How can a team finish earlier? The time is fixed, scope can change, right? In consequence if the team finished the iteration plan, than they should pick up the next highest priority story from the Release Plan. This was the strategy almost a decade ago, practiced in XP. Newly Kanban has the same strategy, but gave up the time boxing. I'm wondering a bit. How do you measure the velocity, and how do you take it into account in the next iteration planning? Again XP took a very simple but effective way. Velocity is the sum of story points done in the last iteration. (Therefore it is inevitable to utilize the iteration time fully.) Into the next iteration only such amount of stories can be allocated which equals with the velocity i.e. the previous performance of the team. Therefore I agree with those that rewarding shouldn't based on performance measured with story point, velocity. My personal habit is to focus on the team's learning and collaboration habit. If individuals or the the team itself demonstrate learning and or collaborative ambitions than I've to the tendency to reward this.

• Repeated studies have shown that unless you are drastically underpaying your resources, financial incentives are not the primary motivator for star performers. How about creating kudo awards & printing them out? Like others, I'll presume this is for some extraordinary performance, e.g. they worked a boat load of hours or came up with some game changing scheme that greatly reduced the cost/complexity of the work.

• You should not reward the team for finishing early, it can destroy the estimation process. You can reward the success of the project.

Material

Algunas reflexiones acerca de motivación y recompensas:

http://www.ted.com/talks/lang/eng/dan_pink_on_motivation.html

Leer antes de motivar:

http://geeks.ms/blogs/rcorral/archive/2010/10/11/leer-antes-de-motivar-o-lo-que-debe-saber-todo-jefe-de-proyecto-sobre-la-motivaci-243-n.aspx

Scrum Manager bits: Motivación intrínseca / motivación extrínseca.

http://www.navegapolis.net/content/view/950/98/

¿Cómo motivar a los programadores?

http://www.navegapolis.net/content/view/115/

¿Los incentivos motivan?

http://www.navegapolis.net/content/view/819/98/

Incentivos en dinero

http://spanish.joelonsoftware.com/Articles/IncentivePayConsideredHar.html

En agilidad existe la noción de Holgura (Slack)

http://agilesoftwaredevelopment.com/xp/practices/slack

articulo acerca de “nerd herding”

http://blog.calevans.com/nerd-herding/

premiar al equipo? Busca medidas que ellos mismos no puedan afectar directamente.

http://www.poppendieck.com/pdfs/Compensation.pdf

Appraisals & compensation- The elephant in the room.

http://www.poppendieck.com/pdfs/The%20Elephant%20in%20the%20Room%20Agile2008.pdf

sobre incentivos

http://spanish.joelonsoftware.com/Articles/IncentivePayConsideredHar.html

Lectura "drive" de Daniel H. pink

http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594488843

recompensas pueden llegar a tener el efecto contrario, este video que lo explica muy bien:

http://www.ted.com/talks/lang/spa/dan_pink_on_motivation.html

Libro con sugerencias y buenas ideas para trabajar con estimaciones, re-estimar, backlogs, etc .

http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415

charla sobre el tema de la motivación:

http://agilizandocmmi.wordpress.com/2010/01/12/motivacion-extrinseca-vs-intrinseca/

Agradecimientos a los siguientes participantes de los foros ágiles más reconocidos.

Les doy gracias por sus aportes, comentarios, consejos de buenas prácticas y material compartido a estos estupendos profesionales, muchos de ellos, conocidos por su trayectoria como Trainers, Scrum Masters y generadores de material de excelente calidad sobre temas ágiles, Scrum y XP.

Desde Scrum Manager: Emilio Osorio Garcia, Ing.Alex M, Miguel Sierra Sánchez, Raúl Herranz, Carlos Rivero Aurre, Juan Palacio (gracias especiales y gran admiración por tus artículos de Navegápolis), Christian Bonner , Ernesto Arroyo CISSP, CISA, CISM, ITIL, Raúl Herranz, Toni Dorta, José Manuel Navarro, Jorge Muria Sánchez

Desde Agile Spain, Rodrigo Corral (gracias especiales, el material que produces es muy valioso.), Alberto Mendez Soto, Felipe Muñoz Castillo, Miquel Saiz, Victor Raton Arjona, Andoni Gonzalo, Juan Carlos Quijano Abad

Desde Chile Agil: Alex Borquez, Emilio Osorio, Esteban Lopez, Ricardo, Byriton, Darsenovski.

Desde agile-cyl: Jose Da Rocha, Javier Gonel, Francisco, Alvaro Loaisa

Desde Yahoo Comunidad Agil: Gustavo Sadovoy, Carlos Peix, CSM Pablo Rodríguez Facal, Alfredo Casado

Desde Agile Alliance: Curtis Stuehrenberg; James Patula, lava kafle, Sunil Mundra, Sott Ambler, James McGovern, D. André Dhondt, Alex Tsirulnikov, Zsolt Zsuffa, Paul Hoeffer, Jorge DeFlon.

Humanopensante.

Fuente

• http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=34640281&gid=37631&goback=.gde_37631_member_34640281&trk=NUS_DISC_Q-ttle

• http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=34671293&gid=855957&commentID=26111724&trk=view_disc

• http://failfast.chileagil.cl/questions/recompensarian-al-equipo-cuando-terminan-la-iteracion-antes-de-tiempo?utm_source=dlvr.it&utm_medium=twitter&utm_campaign=chileagil

• http://www.linkedin.com/groupItem?view=&gid=137792&type=member&item=34580595&qid=e61038bb-9ce2-4f19-b2ea-df09cf500be9&goback=.gmp_137792

• http://groups.google.com/group/agile-cyl/browse_thread/thread/4da91dfc87545644

• http://tech.groups.yahoo.com/group/foro-agiles/messages/3681?o=1&xm=1&l=1