archivo

Archivo de la etiqueta: compromiso

Un error muy frecuente que nos encontramos con las estimaciones lo tenemos en pensar que se van a dar condiciones ideales: no se van a sufrir interrupciones inesperadas, no vamos a sufrir contratiempos técnicos y la capacidad calculada para cada persona no va a sufrir cambios (en el momento en que una persona por el motivo que sea no puede ir a trabajar un día, rompe ya los esquemas).

Si a eso le sumamos lo difícil que resulta acertar, estamos sometiendo cada sprint a una presión que los desarrolladores no van a poder aguantar porque la realidad será que para cumplir los compromisos se tendrá que incrementar la capacidad de todos y eso se traduce en overtime. El otro camino es dejar historias de usuario comprometidas para más adelante (sacarlas de la pila de sprint). Ambas soluciones son malas. La primera porque no es sostenible, ya que incluso los equipos más motivados no pueden aguantar un ritmo por encima de sus capacidades físicas durante un tiempo prolongado y la segunda porque perdemos predecibilidad y fiabilidad.

Ten en cuenta en que fase del proyecto te encuentras, no tienes el mismo conocimiento al principio que tras la sexta o séptima iteración y ten en cuenta que no se puede asegurar capacidades del 100% de nadie. Se puede estar asignado al proyecto un 100% pero prever una capacidad para el sprint inferior a esa, si después resulta que no han existido contratiempos y puede estar al 100% pues mejor, ya que así aprovechará para ayudar a otros compañeros, para ayudar a resolver contingencias que hayan podido ocurrir en la iteración, para refactorizar, etc…).

El equipo recibe muchas presiones (y quién esté libre de pecado que tire la primera piedra) para que asuma el mayor número de historias de usuario posible. Se tiene que aprender a decir que no y a respetar las condiciones para que un conjunto de personas puedan cumplir sus compromisos sin tener que reventarse.

Personalmente soy partidario de tener pilas de sprints cerradas porque eso quiere decir que se han trabajado las historias de usuario y que se dispone de toda la materia prima necesaria para ejecutar el proyecto. Además representa predecibilidad, con lo complicado que resulta eso en el desarrollo de software, ya que es el reflejo de una serie de compromisos del equipo de desarrollo con respecto al product owner dentro de la capacidad de trabajo que se puede asumir.

Para darle un tratamiento a las incidencias soy partidario de la existencia de personas, fuera del alcance del sprint, que se encarguen de ellas (no quiere decir que sean personas que específicamente se encarguen de esto, ya que podría ser válida la decisión de reservar una capacidad concreta del equipo de proyecto sobre el total para la realización de estas tareas). De esta forma, el cumplimiento de los compromisos no se debería ver afectado por la resolución de las incidencias (aunque esto es teórico porque una incidencia mal corregida o de gran impacto puede afectarle).

En el caso de que no llegasen incidencias en número y complejidad que consuman la capacidad disponible, siempre se puede aprovechar ese tiempo para trabajar sobre el sprint y ayudar al cumplimiento de los compromisos, además de realizar otro tipo de tareas que pueden resultar positivas: refactorizar código para reducir deuda técnica, realización de testing, automatizar pruebas, hacer mejoras sobre la infraestructura de desarrollo, etc…

Pero independientemente de que mi preferencia sea esa, soy de la opinión de que siempre hay que estar abierto a las circunstancias que se puedan producir en el proyecto y que si hay que abrir la pila de sprint, hacerlo.

Me parece muy interesante la siguiente reflexión de Mike Beedle (traducción libre): “El coraje en Scrum no es algo visible o tangible. Tampoco es una especie de heroísmo romántico. En su lugar, consiste en tener el coraje y la determinación de hacerlo lo mejor que puedas. Es la obstinación de no darse por vencido y cumplir los compromisos. Este tipo de coraje es valiente, no glorioso”.

Beedle lo asocia a Scrum, sin embargo su cita me parece interesante porque refleja una actitud que va más allá de la utilización de una determinada estrategia de desarrollo de software y que desde mi punto de vista es absolutamente acertada: la actitud por intentar cumplir unos compromisos, por hacerlo lo mejor posible, de dar lo mejor de nosotros para conseguir esos objetivos.

Esto supone en primer lugar un compromiso con nuestro, con nuestro equipo y con nosotros mismos de lo contrario como mucho llegaremos a ser cumplidores (incluso con una cierta eficiencia) pero falta el empuje necesario para vencer determinadas resistencias que nos encontraremos en el proyecto y que requieren lo mejor de nosotros mismos, así como la capacidad de levantarse y recuperarse ante las dificultades que vayan surgiendo.

Como comenta Beedle no se trata de sacar la varita mágica y convertir en sencillo lo difícil sino de saber que nos encontramos ante un reto que exigirá lo mejor de nosotros mismos y que para superarlo requerirá mucho esfuerzo. ¿Qué después no es para tanto? Mejor, pero eso no quita que en el siguiente proyecto nos encontremos con mayores dificultades.

Para Jeff Sutherland: “El compromiso de trabajar juntos sólo ocurre cuando las personas están de acuerdo en objetivos comunes y luego luchan para mejorar como personas y como equipo”.

Precisamente por eso es tan complicado alcanzar ese compromiso y por eso creo que se requiere un cierto bagaje personal y profesional para entender qué ventajas supone trabajar de esta manera y lo necesario que resulta para sacar adelante los proyectos.

Los equipos funcionan cuando existe un compromiso entre los miembros del equipo. Cuando cada cual va por su cuenta no estamos hablando de equipo sino de un conjunto de personas que comparten un espacio físico.

El compromiso es dar lo mejor de nosotros mismos por el equipo y por el proyecto y exigir a los demás que hagan lo mismo. Si el nivel de exigencia no es justo favoreciendo a unos sobre otros, no se debe llamar compromiso, sino amiguismo ya que el compromiso solo tienes con unos cuantos y esos cuantos contigo.

Tampoco son buenas las políticas del todo el mundo es bueno, porque generalmente cuando se aplican es precisamente para evitar ciertas decisiones poco agradables. Lo fácil siempre es hacer la media aritmética y tratar a todos por igual lo hagan bien o lo hagan mal, estén comprometidos o no. Este tipo de estrategias hacen mucho daño a aquellas personas que precisamente ofrecen un mayor compromiso.

Cuando un equipo funciona tiene como consecuencia natural la autogestión en la que cada miembro del equipo asume su responsabilidad y se resuelven los conflictos en el equipo (salvo que por su trascendencia tengan que escalarse).

Es lo que necesito en la gente que trabaja conmigo. Una persona comprometida incluso con menos conocimientos y experiencia que otros generalmente permite obtener mejores resultados a nivel individual y colectivo (siendo más importante lo segundo que lo primero teniendo en cuenta que los proyectos son el resultado del trabajo de muchas personas).

Cuando te falta compromiso te falta el cariño necesario en las tareas que realizas y te vuelves descuidado. Cuanto te falta compromiso piensas en ti y no en esos compañeros que sí están poniendo interés para que el trabajo salga adelante, los cuales merecen un respeto que no estás ofreciendo.

En el momento en que alguien pierde el compromiso hay que cortarlo de raíz (ver artículo: teoría de las ventanas rotas).

Soy consciente de que el compromiso se construye día a día y que el primero que tiene que comprometerse y ser un ejemplo es quien más responsabilidad tiene en el proyecto. No puedes pedir compromiso si no lo tienes y eso es un problema muy grande de muchos gestores que solo se preocupan de dar instrucciones sin ejercer un liderazgo real.

Con respecto al compromiso me gusta el punto de vista que le da Mark Beeson, donde lo asocia al hambre por conseguir retos (no todo el mundo tiene la misma predisposición al compromiso, tiene una visión del trabajo más allá de ejecutar las tareas que tienes encomendadas o le afecta igual un trabajo bien o mal hecho): “Cuando estoy formando un equipo, busco a gente que le encante ganar. Si no los encuentro busco a gente que odie perder. Quiero gente a mi alrededor que tenga pasión”.

El otro compromiso, tal vez el más importante es el que tiene uno consigo mismo. Este compromiso varía en cada persona en función de su escala de valores.

En el ámbito laboral mi compromiso personal es sacar adelante de la mejor manera posible los proyectos en los que participo, eso no quiere decir que todos vayan a tener éxito sino que lo voy a intentar, que voy a tratar de poner lo mejor de mi, sea mucho o poco, para que el objetivo se cumpla.

Ese compromiso, está por encima de mi contexto laboral. ¿Eso quiere decir que me hago inmune a él? No y muchas veces afecta a mi rendimiento y me genera en demasiadas ocasiones frustración e ira, sin embargo, no recuerdo ninguna situación en la que haya terminando bajando los brazos, incluso cuando la consecución de los objetivos en el proyecto ya no eran posibles.

No soy mejor que tu por esto, quiero que lo tengas claro, es solo mi forma de entenderlo.

Mi compromiso está por encima de lo que puede ofrecerme mi organización porque me niego a estar limitado por la misma, sería un doble castigo, no sentirme valorado y autolimitarme como consecuencia de lo anterior. No obstante, respeto, muy mucho a quien decide que hasta aquí hemos llegado, siempre y cuando sea objetiva la falta de compensación entre lo que compromete la organización y lo que compromete la persona, si bien, y desde mi punto de vista, cuando eso ocurra, el camino no debería ser la autolimitación, sino la búsqueda de otras alternativas profesionales, ya que tu libertad para reducir tu nivel de compromiso debe mantenerse en equilibrio con tu entorno y no es justo que tus compañeros carguen con tus problemas.

No puedes esperar o pedir compromiso si tu no le ofreces lo mismo.

Por otro lado, todo tiene un límite. Una persona podrá ser comprometida con su trabajo, con el proyecto y contigo pero si la organización a la que pertenecéis no lo valora en su justa medida terminará disminuyendo su nivel de compromiso, tal vez no en este proyecto, tal vez no en el siguiente, pero sí lo hará tarde o temprano y lo más probable es que te termine comentando sus motivos (si tiene confianza en ti).

Hay personas más mayor capacidad de comprometerse que otras, que pueden tener más paciencia o aguante, pero si el compromiso no se alimenta terminará por desaparecer paulatinamente o provocará que busquen otras alternativas profesionales en las que sí encuentren lo que hasta ahora se les estaba negando.