Los mayores enemigos del agilismo … ¡los profesionales del escapismo!

La elección de una metodología adecuada para un proyecto dado es, sin duda, una de las claves del éxito del mismo. Decir que las metodologías ágiles han llegado al panorama del mundo de la gestión para quedarse y que están irrumpiendo con fuerza es sin duda una afirmación anacrónica: no han llegado ahora, sino que han adquirido un nivel de madurez suficiente como para no ser vistas como un modismo, una excentricidad, entre los directores de proyectos medianamente bien informados.

Sin embargo, no son el bálsamo de Fierabrás, la solución mágica a todos los problemas de la gestión, como pretenden hacer creer sus más acérrimos defensores. Como tampoco lo es cualquier otra metodología que uno quiera imaginar. Cada proyecto, cada empresa, cada cliente, tiene un contexto y unas necesidades que marcarán la metodología más adecuada a utilizar.

Las metodologías ágiles, como puede ser SCRUM, tienen una especie de canto de sirena que hace que te lances a sus brazos sin saber los peligros que pueden esconder. Peligros que, bien gestionados, son precisamente una de las fortalezas de las mismas. Y si el peor enemigo de cualquier proyecto es la falta de involucración de los diferentes actores del mismo, en el caso del agilismo ataca a su línea de flotación, a su esencia. El peor enemigo del agilismo es el escapismo.

houdini-1899--644x362

Cuales avezados discípulos de El Gran Houdini, uno intenta mantenerles encadenados (figuradamente hablando, por supuesto) al proyecto, pero al final siempre escapan.

Centrémonos en SCRUM. Si el Product Owner es un escapista profesional, sencillamente no hay proyecto. Si, como representante del cliente, no aporta la perspectiva de negocio, no detalla las historias de usuario y las prioriza adecuadamente, no hay nada que hacer. Y además son los más complicados de gestionar, tanto en cuanto, siendo parte del cliente, se dispone de poca (o nula) capacidad de dirigir la situación hacia el interés común. Se requieren las más altas sofisticadas técnicas de persuasión para ello (recordemos la historia de Catón El Viejo). Otras veces, no queda más remedio que escalar el problema en la organización (u organizaciones) involucradas, para que pueda ser gestionado por quien tenga la potestad para ello.

Diapositiva5

En otras ocasiones el escapista es el Facilitador (SCRUM Master). Dicho muy superficialmente, El SCRUM Master debe eliminar todas las barreras que se presentan en el proyecto, permitiendo al equipo de desarrollo centrarse precisamente en eso: el desarrollo. Al mismo tiempo, vela por la correcta implantación de la metodología. Si el SCRUM Master es un campeón del «No es asunto mío», si malinterpreta la autoorganización de los equipos SCRUM con el «estos chavales son muy espabilados y seguro que lo resuelven solos», si no es garante del cumplimiento de la metodología y los planes establecidos, no tenemos SCRUM. Tendremos, a lo suma, un conjunto de aguerridos soldados que tratarán de sobreponerse a las vicisitudes de la batalla de la mejor manera posible.

Diapositiva7

Que haya escapistas en el equipo de desarrollo de un proyecto SCRUM, como en cualquier proyecto en general, no hace sino contribuir al mal desempeño y mal ambiente en el mismo. En SCRUM los equipos trabajan como relojes perfectamente sincronizados y todo está orientado a la alta eficiencia de los mismos. Se les da la confianza y empoderamiento suficientes para ello. Deben tener sentimiento de equipo. Debe existir una comunicación fluida, honestidad y confianza para reportar diariamente los avances conseguidos y problemas encontrados. Con solo un escapista profesional que haya … Os podéis imaginar.

Por supuesto, también puede haber escapismo entre las partes involucradas (stakeholders) y la dirección de las organizaciones, pero los efectos en el proyecto no son (siempre) tan inmediatos.

¿Has sufrido escapismo en tus proyectos? ¿Pudiste revertir la situación? ¿Cómo? Ya sabéis que los comentarios en este blog sirven para aprender unos de otros, como de muro de las lamentaciones 🙂

¡Gracias por compartir tu experiencia!

Print Friendly, PDF & Email

22 comentarios

  1. Ángel estos días ando releyendo a Peter Drucker «El management del Siglo XXI» y ya en 1999 nos recordaba este gran maestro que: «Hay unas enormes diferencias en las estructuras organizativas, dependiendo de la naturaleza de la tarea que hay que realizar»

    Si el supuesto de «La Unica Organización válida» no deja de ser un paradigma más al que nos seguimos agarrando, pues algo parecido nos pasa con las metodologías.

    Según Peter Dreucker «La organización acorde con la tarea», pues lo mismo en la Gestión de Proyectos y los Equipos de trabajo.

    Así que, cuidadín con «los Cantos de Sirena» como única melodía. 😉

  2. Parece ser que los nahuales se están confabulando para que la quedada de Zaragoza sea todo un éxito. Lo digo porque mañana publicamos en el blog del ratón una adaptación Scrum ratuna de la que Ana y tú no os podréis escapar 😉

  3. Los escapistas no son solo enemigos de los proyectos ágiles, son en general enemigos de todo tipo de trabajo colaborativo. En un proyecto es importante eliminar este tipo de perfiles porque pueden dar al traste con los objetivos pero lo mismo ocurre en el día a día, si no se respetan los deadlines la cosa no fluye.
    Hay verdaderos especialistas en crear cuellos de botella buscando reconocimiento ralentizando el engranaje y haciendo ver lo imprescindibles que son, eso es frustrante cuando tus tareas dependen de otros y esos otros no están a la altura.
    Un abrazo!

  4. He trabajado con organizaciones con problemas de escapistas, que están en todas las organizaciones. El problema de todas las metodologías es eso, que son metodologías, es decir, abstracciones teóricas que quedan my bien cuando no introduces un concepto variable y que no se gestiona en las metodologías, que se estancan y no son capaces de seguir.

    El factor principal y olvidado es el humano, y hay personas que no pueden, aunque quieran, trabajar en equipo, por ejemplo hay muchas personas, sobre todo entre ingenieros, matemáticos, etc, que son brillantes individualmente, pero que tienen Asperger o autismo en el nivel inferior no diagnosticado a veces, y que no pueden trabajar en grupo.

    Determinar las necesidades de las personas permite reajustar equipos y hacer equipos invencibles y altamente productivos que funcionen desde la colaboración y no desde la competencia y que tengan claro que el bien del grupo es el bien de los individuos.

    De hecho el coaching de equipos es un campo ilimitado porque donde hay un equipo hay problemas, salvo que haya alguien en él que sea capaz de gestionar la capacidad cognitiva de todos los presentes.

    1. ¡Uf! No sabes cuánta razón tienes …

      Llevo 15 años en en sectores altamente tecnológicos, y desgraciadamente me he encontrado más de un caso de de gente que no puede trabajar en equipo (y, si me apuras, ni debe; y es mejor darle tareas autocontenidas y que interfieran lo menos posible en el trabajo de los demás).

      Y, sí, los perfiles técnicos/tecnológicos tenemos una especie de ego subido que …

      ¡Gracias por comentar!
      Ángel

      1. No me refiero al ego para nada, creo que ego hay en todos lados y depende de la persona, pero en el caso de perfiles técnicos, sobre todo los muy brillantes hay mucho Asperger y Autismo en grado mínimo, y son personas que como bien dices hay que estar conteniendo, darles tareas que no les desborden, no sea que contaminen el ambiente, las más de las veces de forma totalmente involuntaria.

        En Estados Unidos se está contratando coaches especialistas en autismo para organizaciones tecnológicas. Y es que muchas de las personas que menciono llegan a nivel genio, pero su capacidad de relación con los demás está limitada por su propio cerebro, les falta la evolución de la parte social, por eso pueden causar problemas, y desde luego intentarán escaparse como puedan de lo que no pueden controlar, pero sólo como una forma de evitar el malestar emocional que les produce no tener todo controlado, que es lo que les da seguridad.

        1. Gracias por el apunte, Ana.

          Tiene todo el sentido del mundo. He tenido la ocasión de trabajar con personas del perfil que comentas: excelentes profesionales en lo técnico, pero muy difíciles de gestionar. Recuerdo al responsable técnico de un subcontratista que tuve, en un proyecto complejo. La solución técnica que proponía era muy buena, pero no encajaba con los requisitos del resto de proveedores. Tal fue su insistencia (pese, incluso, a la oposición de sus propios compañeros) que tuvimos que ceder. Y mucho.

          Alguna vez hemos comentado en nuestros respectivos blogs de lo difícil que es gestionar personas cuando no tienes una preparación al respecto. Por eso digo que tiene todo el sentido del mundo contar con profesionales que van a permitir orientar y reconducir situaciones complejas, porque esos genios de los que hablas pueden y deben aportar mucho, si se les sabe tratar adecuadamente (y reciben las pautas adecuadas).

          ¡Gracias de nuevo!
          8)

          1. Una pregunta que si no quieres o no puedes responder no lo hagas, pero tengo curiosidad, ¿por qué entonces cedisteis? Quiero decir qué fue lo que hizo que decidierais ceder, fue por llegar a un acuerdo porque él no iba a seguir y así poder seguir adelante o fue otra la razón?

            1. Sin problema!

              Técnicamente era una muy buena solución, sobre todo a largo plazo. Complicaba el diseño y nos obligaba a dedicar un esfuerzo inicial mayor que el planificado.

              Lo que me hizo ponerme en guardia como director de proyecto no era solo cómo defendía su solución, sino como menospreciaba la nuestra (que te puedo asegurar que no era mala) Defendió con tal vehemencia su solución, que nos quitamos esa especia de orgullo y adoptamos la solución que propuso.

              En resumidas cuentas, el subco iba a desarrollar gran parte del sistema, así que mejor llegar a un acuerdo. Tratamos de ver todo con objetividad, analizamos con cuidado lo que proponía y nos lanzamos a ello. Las cosas fueron bien, aunque honestamente pienso que con nuestra solución, al menos técnicamente hablando, también hubiera ido todo correctamente.

              Esta situación me la encuentro con frecuencia en el trabajo (discrepancias con clientes, proveedores, …) Muchas veces el problema no es el qué se propone, sino el cómo. No acepto chantajes, pero muchas veces tengo que quitarme toda capa de subjetividad para decidir objetivamente.

              Espero haber contestado a tu pregunta 🙂

  5. Excelente artículo. Me permito agregar el «valor» de las certificaciones que en unas horas «construyen» expertos «certificados». Comparto el artículo porque es muy acertado. Me apunté para seguir tus escritos

    1. En primer lugar, muchísimas gracias por rebloguear el artículo. Es un inmenso placer y honor.

      Respecto a tu comentario, no puedo estar más de acuerdo. Te voy a contar un secretillo 🙂 Cuando empecé a usar metodologías ágiles, me apunté a un certificado de estos. Antes le había echado un vistazo rápido a SCRUM (no le había dedicado más de 2 o 3 horas). El caso es que, por error, empecé a hacer el examen de «certificación», y no había posibilidad de marcha atrás (salvo pagando de nuevo , claro).

      Creo que fueron 50 preguntas a contestar en una hora. Aprové. Y lo hice por lógica y por 14 años de experiencia gestionando proyectos no ágiles, y gracias a San Google. No sé si dice mucho de mí o poco de curso, pero ahí dejo la reflexión.

      Sé bastante de gestión «clásica» y de agilismo (aunque de éste último me queda bastante por mejorar). Pero pongo esta pequeña experiencia para rubricar tu comentario.

      ¡Gracias por comentar y compartir!
      8)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.