Las organizaciones se enfrentan a clientes que piensan que pueden demandar lo que quieran, hay que darles lo que piden y todo se puede hacer con el nivel de presión adecuado. El resultado es: Una industria que mucha gente odia, clientes descontentos y empresas que quiebran. ¿Cómo cambiarlo?
Hace tiempo, un lector de mi blog me escribía:
Hola Jerónimo,
He descubierto tu página hace poco y desde entonces soy un asiduo a ella. Es más a raíz de tus posts ya tengo en mis manos el libro de Scrum - A pocket guide de Gunther Verheyen.Te cuento, he estado 5 años trabajando en una empresa de IT que apuesta muy fuerte por las metodologías ágiles. Hace 7 meses cambié a otro sitio y aquí me está costando mucho hacerles ver las ventajas de trabajar con Scrum frente al waterfall tradicional.
Aquí cuando entra un proyecto nuevo, en base a una estimación sobre suposiciones se elabora un plan de proyecto y una oferta económica que acaba siempre en incumplimientos de fechas de entrega y budgets.
Como ahora me toca más de cerca el tema de los presupuestos no tengo muy claro cómo hacer con Scrum para presupuestar un proyecto. Te pongo ejemplos. Si en una fase inicial donde apenas conocemos el alcance del proyecto y el cliente está pidiendo un presupuesto, o incluso si nos presentamos a un concurso, cómo podemos hacer para decirle al cliente lo que le va a costar el proyecto?
Scrum se basa en el empirismo y en la confianza entre cliente y proveedor, pero cómo le puedes decir a un cliente que de primeras no tienes ni idea de lo que le va a costar el proyecto y que hasta digamos la mitad del transcurso del proyecto no tendremos una idea aproximada de lo que puede llegar a durar (y por tanto) costar su proyecto.
Muchas gracias por adelantado!
Alberto Gómez
El mito del 100% de certidumbre
Me parece una pregunta muy interesante, y quizás la respuesta que pueda dar parezca sorprendente. Vamos allá:
Cuando te pregunten por proyectos cerrados, responde con complejidad y métricas de predictibilidad. NO discutas sobre lo indiscutible. En lugar de eso fomenta una conversación que ayude a pensar en cómo mejorar.
Una de las habilidades más importantes como Scrum Master es tener la capacidad de establecer el contexto adecuado a la hora de hablar de problemas y soluciones. Ver más allá de la cuestión e intentar establecer nuevas ideas para que las personas con las que trabajamos puedan desarrollar su propia visión de las cosas.
El caso que me comentas me lo he encontrado muchas veces a lo largo de mi carrera. A pesar de querer utilizar Scrum, las organizaciones insisten en tener fechas, alcances y precios cerrados. Lo ven como un factor de reducción de la incertidumbre y algo a lo que agarrarse en caso de que las cosas vayan mal. Y es que las cosas irán mal. Y no porque no hagamos nuestro mayor esfuerzo en ceñirnos al plan. Sino porque el plan, desde el primer momento que lo escribimos, está mal.
El desarrollo de Software como entorno complejo
Déjame presentarte a Dave Snowden. Es uno de los contribuyentes más importantes al movimiento ágil y sin embargo, despotrica de Scrum cada vez que tiene oportunidad ¿Por qué? Porque ve como Scrum se ha convertido en el palo con el que las organizaciones atizan la complejidad.
Dave es experto en complejidad. Basándose en el trabajo de Ralph Stacey, ha creado el framework Cynefin (Pronunciado Kin-fin) dentro de su compañía para explicar este concepto.
Sí, los planes funcionan en entornos simples y en parte de los complicados, pero en el momento que aumentamos la complejidad, es imposible mantener un plan y de tontos intentar ceñirte a él. En esos entornos, es mejor contar con una forma de trabajo que permita inspeccionar y adaptar.
Te daré un ejemplo. Si tengo una habitación que mantener a la misma temperatura todo el día, ¿Cuantas variables influyen?
Muchas. Muchísimas.
¿Tendría sentido hacer un plan para todo lo que hay que hacer en la habitación (poner el aire, quitar el aire, poner la calefacción, abrir las ventanas) para ejecutarlo una vez al día? ¿O tendría más sentido utilizar un climatizador, que se encarga de inspeccionar la temperatura y adaptarla? Scrum es al Software lo que el climatizador es a la habitación. Nos permite descartar variables, inspeccionar y adaptar en entornos complejos.
Para aquellos clientes que demandan predictibilidad, no hay más que utilizar herramientas que tienen en cuenta la complejidad, como son el cono de incertidumbre, No Estimates o el uso de simulaciones de Montecarlo para poder estimar basados en situaciones previas.
Ten en cuenta que el truco es tener un histórico. Si no existe un histórico de delivery de ese equipo en ese proyecto, es imposible dar ningún tipo de predictibilidad. Tampoco si el equipo ha estado en otro proyecto. Lamentablemente este es el mundo del Software. No importa cuanto le grites a un cable, no va a transmitir más bits por segundo.
La próxima vez que te veas en esta situación, en lugar de decir ¡No se puede!, intentar crear una conversación sobre complejidad y sobre la experiencia de la compañía en el pasado con estas situaciones, para dar paso a una discusión sobre métricas alternativas de predictibilidad que ayuden al cliente y a la organización a entender mejor el proceso.
Por último te recomiendo un libro: Actionable Metrics for predictability, que ahonda mucho más en este tema.
Con paciencia y perseverancia, empezarás a tener conversaciones que hagan que el rumbo de la compañía cambie.