Reflexiones: SCRUM y 5M

Tenemos visiones parciales, incompletas, segregadas… Es inevitable.

Fue hace unas semanas.

A los alumnos de un grado en informática (es un ejemplo, pero es real) les enseñan ya metodologías ágiles e incluso cómo desencadenar un proceso de design thinking para afrontar un wicked problem, con toda su artillería metodológica… pero nadie les habla de cómo resolver un problema que probablemente tenga poco de wicked.

Y es que espero que nadie, a estas alturas, estimados lectores, se plantee siquiera que SCRUM pueda garantizar un camino de éxitos, exento de problemas y solo sujeto a un número incierto de iteraciones tras las cuales, sin duda alguna, aparecerá el santo grial…

Es más, las metodologías ágiles y el pensamiento de diseño están concebidos como un reto y no como un proceso de resolución de un problema, porque incluso cuando el problema es el origen de todo (algo extremadamente frecuente e incluso recomendable), el trabajo se centra en el reto de superarlo y no en corregirlo, independientemente de si se atacan las causas o no, mediante dosis masivas de observación, pensamiento lateral y experimentación.

El camino es diferente, gratificante, desafiante y motivador… pero no siempre resuelve un problema, sino que en muchas ocasiones elimina sus efectos o la necesidad de que éstos nos afecten o de que ni siquiera nos lo tengamos que plantear.

Y claro… a veces los problemas son tozudos y no quieren «dejarse desaparecer», jejeje…

Un buen SCRUM trata de garantizar que se alcancen las funcionalidades requeridas y un buen diseño de UX se preocupa de satisfacer e incluso superar las expectativas del cliente… pero en cualquier caso, durante el desarrollo de un proyecto, en su implantación y posteriormente a su implantación, surgen problemas que muchas veces los equipos no saben cómo afrontar.

Y si han trabajado con proveedores recientemente en un marco SCRUM, estoy seguro de que entienden de qué les hablo.

¿Cómo han tratado de corregir sus proveedores un problema relacionado con la entrega de un producto con rendimientos insatisfactorios o claramente por debajo de lo esperado, a pesar de numerosas interacciones? ¿Cómo han abordado retrasos significativos que incluso han afectado el potencial de su negocio como cliente? ¿Cómo han gestionado el aprendizaje posterior y cómo se lo han comunicado?

«Mira, lo hemos hecho mal… pero hemos aprendido. Nos vamos a hacer cargo de esta y esta otra manera y, además, te vamos a contar cómo hemos analizado los problemas, cuáles han sido las causas que creemos los han motivado y qué cambios vamos a introducir para que no nos vuelva a ocurrir«. ¿Recuerdan a algún proveedor que haya adoptado una iniciativa similar? ¿La han adoptado en sus propios equipos para con sus clientes? No, ¿verdad?

El mundo de los servicios de consultoría, ingeniería o diseño no está en general acostumbrado a este tipo de relación con sus clientes. Para un desarrollador de software, que su cliente haga de beta tester, o que incluso lo haga durante semanas y en correcciones sobre correcciones, entra dentro de lo que cabe esperar, dentro de lo que puede ser normal que pase.

Eso es un anatema en el mundo de la industria. Pecado mortal. Si haces algo así, estás fuera.

Y sin embargo, muchos de los problemas que surgen en el desarrollo de un proyecto de software no son diferentes a los problemas que surgen en cualquier otro orden de la vida, en cualquier otro tipo de negocio, tecnología o disciplina. O sea, que las metodologías clásicas de resolución de problemas (sí, incluidas las viejas y nuevas herramientas de calidad y calidad total) son perfectamente aplicables.

A los que ya hemos pasado de los 50, nadie nos enseñó en nuestras carreras cómo resolver un problema en una empresa. El conocimiento y las técnicas implicadas formaron parte del aprendizaje experimental que luego fuimos desarrollando en nuestras actividades profesionales, en función del sector o de la función que nos hubiera tocado en suerte. Entonces, la mejora continua, los conceptos lean o la calidad total no formaban parte de los estándares de aprendizaje y, aunque parezca mentira hoy, conformaban la cultura emergente… 😮

Lo alucinante es que, hoy en día, el poder de lo cool esconda muchas veces carencias que, en estos tiempos, es increíble que se permita permanezcan en el territorio de la ceguera cognitiva de un profesional. Como en el caso del grado en informática con el que abría el post, el adiestramiento en los procesos de resolución de problemas está universalmente al margen del aprendizaje académico, cuando en mi opinión debería formar parte de una cultura generalizada de estar en el mercado de trabajo. Su transversalidad es absoluta.

Incluso si adoptamos SCRUM como metodología de desarrollo de proyectos. Veámoslo.

Imaginemos un «proyecto A» en el que se ha generado un conflicto con el cliente: se ha entregado con un retraso considerable, la calidad del producto está lejos de satisfacer las expectativas de quien paga, los costes de desarrollo se han disparado y ha habido que renegociar el contrato, o han surgido dificultades técnicas que han forzado al cliente a renunciar a determinadas funcionalidades deseadas.

Venga… seguro que no les es muy difícil acordarse de un proyecto en el que haya surgido alguno de estos «problemillas»… o varios de ellos a la vez…

Imaginemos pues que hemos hecho uso como estándar de metodologías ágiles y singularmente SCRUM. ¿Qué podemos hacer para aprovechar la experiencia para aprender y mejorar nuestro desempeño? ¿Cómo nos podemos hacer cargo del problema para robustecer nuestras competencias y habilidades en la gestión de proyectos? ¿Cómo identificamos nuestros errores para aprender de ellos y ser más competitivos, más eficientes, más efectivos y en definitiva mejores?

Da igual si se han sentido aludidos como clientes o como proveedores. Se trata de un problema para ambos y por lo tanto ambos pueden exprimirlo para aprender.

Es perfectamente posible hibridar el pensamiento de diseño con la utilización de herramientas de resolución de problemas. De hecho, y aunque los guay del design thinking no lo sepan, algunas de las herramientas que usan son o derivan directamente de aquéllas, jejeje…

Veamos las clásicas 5M. Se trata de ser sistemático en el análisis de causas para que no se nos escape ninguna cuando tratamos de identificar el origen de un problema. El objetivo es siempre determinar todas las causas que provocan su aparición, para atacar la raíz de las mismas y evitar que en el futuro se reproduzcan.

Suelen ser preludio del uso de otras herramientas adicionales (los 5 WHY o el diagrama de Ishikawa, por ejemplo) que nos ayudan a ello, pero hoy nos quedaremos en este primer paso, el más básico.

Cuando uno comienza a enfrentarse al análisis de un problema, es muy recomendable escoger un esquema mental que ayude a colocar el foco de nuestra mente en todos y cada uno de los ingredientes relevantes que suelen ser origen de cualquier problema, sin olvidar ninguno. Un brainstorming simple, abierto y no guiado por restricciones bien segmentadas, suele conducir siempre a lugares comunes, lo que implica que habrá aspectos que se nos escapen del análisis y, en definitiva, que el problema conservará potencial de reaparición.

Si hemos sido buenos profesionales y hemos tratado de corregir nuestros errores y aprender de ellos, pero no lo hemos hecho con método y los problemas se repiten a pesar de las acciones tomadas, acabaremos pensando en lo buenos o malos que somos… y no en cómo hacemos lo que hacemos. Mal camino.

Las 5M proponen que concentremos nuestra mente en identificar las causas de un problema (las razones por las que un proyecto ha sido fallido) en 5 focos diferentes:

• Máquina: causas relacionadas con el mal funcionamiento o la insuficiente capacidad de proceso de máquinas, equipos o herramientas.
• Método: causas relacionadas con el mal uso o la no aplicación adecuada de metodologías contrastadas o de estándares de trabajo definidos.
• Materiales: causas relacionadas con el uso de materiales de insuficiente calidad o inadecuados para la función a desarrollar.
• Mano de obra: causas relacionadas con bajos rendimientos personales, insuficientes competencias técnicas, errores humanos o comportamientos dañinos para el proyecto.
• Medio: causas relacionadas con factores del entorno que tienen capacidad de influir en el rendimiento de producto o en el desarrollo del proyecto.

Pues vayamos a analizar cómo aplicar las 5M al «proyecto A» que mencionábamos antes, un proyecto gestionado con SCRUM… que no ha ido bien.

A pesar de que SCRUM es en sí mismo una metodología y de que por lo tanto lo más fácil es que nos surjan preguntas sobre el funcionamiento del método en sí mismo o sobre las personas (al ser un proyecto donde los recursos fundamentales suelen ser de conocimiento), en función del tipo de proyecto o problema podríamos hacernos preguntas como las siguientes:

• Máquina:
  • ¿Se adecuaban las interfaces, nuevas o disponibles, que hemos utilizado, a las especificaciones técnicas? ¿Y al lugar de uso? ¿Por qué no?
  • ¿Su robustez y calidad eran las necesarias para un funcionamiento continuo y sin fallo? ¿Estaba todo ello garantizado? ¿Por qué no?
  • ¿Estaba la máquina en que se insertaba o integraba nuestra solución, preparada para ello? ¿Cumplía las necesidades mínimas para absorber el funcionamiento del nuevo sistema? ¿Por qué no?
  • ¿Eran las plataformas tecnológicas usadas las adecuadas para las necesidades del proyecto? ¿Estaban suficientemente disponibles? ¿Eran seguras? ¿Se disponía de redundancia, respaldo o alta disponibilidad? ¿Por qué no?
  • ¿Se disponía de la suficiente capacidad de cálculo y en el tiempo preciso? ¿Por qué no?
  • ¿Disponíamos de planes de contingencia para el fallo en nuestras instalaciones? ¿O frente a fallo catastrófico? ¿Por qué no?
• Método:
  • ¿Se definió adecuadamente la misión del proyecto? ¿Representaba fielmente el objetivo deseado? ¿Existía una comprensión compartida en el equipo y con el cliente del significado, las limitaciones y las implicaciones de la misma? ¿Por qué no?
  • ¿Era claro el campo de decisión interna del equipo y los elementos que necesitaban de validación externa? ¿Se respetó? ¿Por qué no?
  • ¿Recogía adecuadamente el contrato las expectativas para el producto, los plazos, las limitaciones y condicionantes del proyecto, las formas y penalizaciones de pago, la propiedad de los fuentes y de los datos o los niveles de servicio, por poner algunos ejemplos? ¿Por qué no?
  • ¿Se definieron con la suficiente precisión las funcionalidades del product backlog? ¿Y las de los sucesivos sprint backlog? ¿Por qué no?
  • ¿Se construyó una estructura de releases y sprints razonablemente ajustada a la naturaleza y necesidades del proyecto? ¿Por qué no?
  • ¿Se definieron con suficiente detalle las acciones a desarrollar en cada sprint? ¿Se desglosaron lo suficiente, en dimensiones manejables? ¿Había suficiente conocimiento en el equipo como para estimar con la suficiente aproximación el coste en horas de cada acción? ¿Por qué no?
  • ¿Se ajustaron las dedicaciones previstas a las disponibles? ¿Mostró habitualmente el burn down chart un ajuste razonable de recursos y necesidades? ¿Se establecieron acciones para corregir las desviaciones? ¿Por qué no?
  • ¿Se realizaron sistemáticamente las reuniones diarias? ¿Y los cierres de sprint? ¿Por qué no?
  • ¿Se utilizaron como herramienta eficaz de gestión las herramientas de gestión visual? ¿Por qué no?
  • ¿Fueron los entregables, en general, bien recibidos por el cliente? ¿Estaba su estructura y contenido bien definidos con antelación? ¿Respondían claramente a una funcionalidad del backlog que podía ser testada? ¿Respondían a una necesidad de feedback para consolidar el avance del proyecto? ¿Por qué no?
• Materiales:
  • ¿Las carcasas, los soportes del interfaz y en general de los equipos instalados, eran adecuados a la agresividad del entorno de trabajo (acidez, salinidad, partículas en suspensión, humedad, presión, temperatura…)? ¿Por qué no?
  • ¿Los materiales de los soportes eran adecuados para la transmisión o recepción de señales inalámbricas (evitando encajonar en aluminio, por ejemplo, la recepción de señales de geoposicionamiento)? ¿Se había previsto prestar atención a este asunto? ¿Por qué no?
  • ¿Eran los equipos, interfaces físicas, soportes y conexiones, suficientemente robustos como para impedir casos de daño accidental, vandalismo o robo? ¿Por qué no?
  • ¿Respetaban los materiales utilizados las normativas del sistema en que se integraban, incluyendo compatibilidad electromagnética, reglamentación, seguridad, eficiencia energética o reciclabilidad? ¿Por qué no?
• Mano de obra:
  • ¿Hemos destinado al proyecto a las personas adecuadas? ¿Eran técnicamente competentes y profesionalmente responsables, a los niveles necesarios? ¿Por qué no?
  • ¿Hemos podido atender a las puntas de trabajo con la flexibilidad necesaria en el equipo o fuera del mismo? ¿Por qué no?
  • ¿Ha habido un nivel de dedicación y compromiso con el proyecto que impida negligencias? ¿Por qué no?
  • ¿Ha habido un nivel de comunicación fluido entre los miembros del equipo, entre éstos con el product owner, entre éste y el scrum master y, en definitiva, entre el equipo y el cliente? ¿Por qué no?
  • ¿Se han cubierto adecuadamente las funciones de product owner o scrum master? ¿Se han sabido separar bien del trabajo operativo, cuando procedía? ¿Por qué no?
  • ¿Ha estado el proceso libre de interferencias significativas de elementos externos (jerárquicos, por ejemplo, o presiones procedentes de entornos multiproyecto) en la capacidad del equipo de gestionar el proyecto y tomar decisiones? ¿Por qué no?
• Medio:
  • ¿Ha sido posible asegurar la buena marcha del proyecto frente a la aparición de tensiones laborales o sociales? ¿Por qué no?
  • ¿Ha estado el proyecto libre de herencias nocivas fruto de experiencias previas cliente-proveedor o de relaciones personales tóxicas internas o externas al equipo? ¿Se previeron y gestionaron? ¿Por qué no?
  • ¿Han aparecido, en el transcurso del proyecto, limitaciones no previstas (internas o externas) o modificaciones en los objetivos, que introducían variaciones relevantes en la misión asignada al mismo? ¿Se han negociado a satisfacción de todos los stakeholders implicados? ¿Por qué no?
  • ¿Se disponía de los espacios y medios de trabajo necesarios para el proyecto y para las dinámicas de trabajo en equipo? ¿Por qué no?
  • ¿Ha funcionado adecuadamente la estructura corporativa que aportaba los recursos auxiliares necesarios (en compras, subcontratación, asesoría legal o selección de personal, por ejemplo)? ¿Por qué no?

Una vez obtenidas las primeras respuestas, conviene preguntar de nuevo a cada una «¿por qué?», sucesivamente hasta 5 veces (como los niños en periodo de descubrimiento), para acercarnos a la verdadera causa raíz. Y una vez identificada una causa raíz, las soluciones se mostrarán evidentes en un alto porcentaje de las veces.

Para terminar, es altamente recomendable hacer un test de coherencia con un análisis de potenciales causas derivadas de posibles fallos en personas que hubieran podido intervenir, directa o indirectamente, en el proyecto. Se trataría de seguir los siguientes pasos:

1. Identificar las personas implicadas: scrum master, product owner, miembros del equipo, director de proyecto, cliente, responsable de compras, proveedores, responsable de infraestructuras, comercial, responsable de control de costes…
2. En cada una de ellas, pensar si se han producido fallos de rigor o de competencia, siempre teniendo en cuenta dos facetas de cada fallo: por qué sucedió algo indeseable, por un lado… y por qué no nos enteramos, o nos enteramos demasiado tarde como para mitigar sus efectos, por otro.
3. Verificar que los fallos que así encontremos estaban ya contemplados, aunque fuera de otra manera, en el análisis de causas anterior.

El objetivo de este test de coherencia no es «meterle el dedo en el ojo» a nadie. No se trata de buscar culpables sino soluciones, no lo olvidemos. Se trata de un proceso metodológico que busca exclusivamente robustecer nuestro desempeño y evitar la reproducción de un problema en el futuro.

Obviamente, la lista anterior de preguntas asociadas a cada una de las 5M no es exhaustiva (cada proyecto tendrá sus preguntas adecuadas)… y el ejemplo no es exclusivo: SCRUM puede utilizarse para gestionar un proyecto de desarrollo de producto físico o incluso de creación de una nueva línea de negocio. Cualquier entorno donde la incertidumbre sea elevada y exija moverse en ese escenario.

De hecho, si el proyecto descansa, total o parcialmente, sobre un producto físico, la aplicabilidad es incluso más evidente.

¿Y sobre un intangible, como un «negocio»? Imaginen, por ejemplo, un desarrollador de software que decide «montárselo por su cuenta»: darse de alta como autónomo, construir su propio modelo de negocio y enfrentarse al mercado como empresa independiente o como freelance. Imaginen que… no le va bien. Que no vende, a pesar de ser una persona técnicamente competente y de volcarse personalmente en construir su marca personal y en conseguir que ello le reporte ingresos suficientes como para que merezca la pena. «¿Por qué no vendo?» es una pregunta que se hará cada noche, ¿verdad? «¿Qué puedo hacer para cambiar la situación?»

Pues les aseguro que pensar en clave 5M sobre lo que identifique que no funciona en cada uno de los elementos de su canvas de negocio (supongo que a definirlo ya habrá llegado, claro) le va a ayudar a afrontar ese problema porque aflorará preguntas tan importantes como las siguientes:

• ¿Qué tecnología estoy utilizando y qué alternativas tendría?
• ¿Qué me están aportando realmente (y cómo) mis aliados y mi red de apoyos para la configuración de equipos de proyecto o para completar mi propuesta de valor?
• ¿Gestiono los capítulos principales de mi estructura de costes?
• ¿Sé realmente quiénes son mis clientes o quiénes tendrían que ser? ¿Me ayuda a entenderlo la estratificación que he hecho… suponiendo, claro está, que la haya hecho?
• ¿Cómo me relaciono con mis clientes? ¿Sé qué necesitan? ¿Y el mercado? ¿Cómo lo averiguo? ¿Cómo lo conecto con mi propuesta de valor? ¿Cómo les hago percibir que me necesitan a mí?
• ¿Con qué recursos cuento, con qué tecnología o equipos, para mi trabajo o para soportar mi propuesta de valor?
• ¿Cómo lleno mi dealflow de proyectos?
• ¿A qué he decidido expresamente renunciar? ¿Qué renuncias estoy dispuesto a hacer?

Lo hará en otro orden, adaptando estas preguntas genéricas a su circunstancia particular y probablemente desglosándolas en otras más específicas… pero lo hará.

Venga… Les dejo un ejercicio para casa: ¿identifican de cuál de las 5M puede haber procedido cada una de estas preguntas? 🙂