agile, Organizaciones Diferentes, scrum

Si un pintor va a tu casa y te dice lo que tarda, ¿Por qué en software no lo hacemos?

Durante mi carrera profesional he trabajado en muchos sitios y en diferentes ciudades. He visto muchos sectores diferentes: seguros, banca tradicional, pymes o sectores públicos. También he tenido la suerte de acompañar a equipos de otros sectores como retail, telefonía o multimedia. Hay algo común en todos ellos ¡Se gestionan por estimaciones!
El concepto es simple, antes de empezar a trabajar se realiza una estimación de cuánto tiempo y dinero nos llevará el trabajo que nos han pedido. Esto se conoce como “Estimation Based Management” (EsBM) y es el modelo que se aplica en casi todos los sectores. El motivo, querer tener control antes de empezar a trabajar. Los motivos son diversos: saber lo que me va a costar, estudiar viabilidad, ajustar presupuestos, coordinar proveedores o garantizar que llegamos a una fecha concreta.
<modo irónico: on> El EsBM es maravilloso, nos permite saber antes de empezar todo lo que va a ocurrir, porque como todo el mundo sabe las estimaciones nunca fallan <modo irónico off>.

Si estimar es jugársela, le sumamos presiones como “esto tiene que estar en navidad”, o “no le podemos decir al cliente otra cosa que no sea que llegamos” o “si cobramos eso perdemos dinero” entonces la receta para el fracaso está garantizada.

color-3371184_1280.jpg
Cuando entramos en el debate sobre las estimaciones y su importancia siempre hay alguien que se saca de la manga el ejemplo del pintor con frases parecidas a estas: “Cuando un pintor va a pintar tu casa, te dice cuanto va a tardar y te da un presupuesto, ¿Por qué nosotros no?”
Acabemos con la falacia del pintor:

  • El pintor va a tu casa y ve el problema, en software muchas veces no podemos ver los sistemas del cliente.
  • El pintor no tiene dependencias de terceros más allá de la pintura por lo que no hay que perder tiempo en eso.
  • Un pintor suele ver una casa normal en un tiempo corto, cuando nosotros vemos el código que vamos a crear/sustituir pueden ser decenas de miles de líneas de código, es imposible hacerse una idea.
  • Cuando contratas un pintor, si a mitad del trabajo le pides un color diferente, tu (como cliente) asumes ese coste, esto en software muchas veces no está tan claro. Igual pasaría si le dijeses que tiene que pintar n-habitaciones más que no se había tenido en cuenta en el presupuesto inicial.
  • Un pintor suele trabajar solo o como mucho en pareja, la cantidad de interacciones entre ambos es baja comparado con un equipo de software de muchas personas.
  • El pintor trabaja en un mundo mucho más predictivo que el software que al ser complejo no se puede predecir.
  • El trabajo del pintor no es un trabajo creativo, el pintor tiene siempre el mismo problema, pintar algo, y la misma solución, aplicar pintura. Esto no pasa con el desarrollo.

Si aún así no te he convencido, te animo a que contrates un pintor para tu nueva web con microservicios, seguro que la tiene a tiempo y sin desviaciones económicas. No tengo nada en contra de la profesión de pintor, es más, no es fácil encontrar uno bueno, sin embargo, es el típico ejemplo simplista que realmente no es comparable con un desarrollo software. La pintura como mucho se mueve en el mundo complicado, esto lo hace predecible. Por contra, el software se mueve en el mundo complejo, lo que impide que podamos estimar.

to-cathedral-3385818_1920.jpg
¿Qué alternativa tenemos entonces para tratar de ser predecibles?
La alternativa la encontré gracias a scrum.org a través de su paper Evidence Based Management (EvBM). La gestión basada en la evidencia se sustenta en la esencia de Scrum. Gestionamos en función de la experiencia que acumulamos. Si queremos compararnos con alguna profesión, pensemos en los científicos. Ellos se basan en la evidencia que encuentran para tomar decisiones y no se basan en la estimación. Sí, usan hipótesis, pero no son estimaciones son suposiciones de lo que podría ocurrir ¡Nadie sufre porque no se cumplan! Por ejemplo, una hipótesis en el mundo científico puede ser “voy a aplicar la encima X en esta célula y quizás cambie de pigmentación”. No son hipótesis del estilo “en 3 meses tengo que curar el Cáncer” (que son más parecidas a las del software).
En EvBM proponen 12 medidores de un producto software dividido en tres grandes áreas: valor directo, time-to-market y capacidad de innovación. De esta manera sabremos el estado de nuestro producto más allá del simple medidor de % de avance.
A la hora de aplicar la evidencia a una Sprint Planning os doy una alternativa. En vez de estimar en horas o puntos de historia, no estimes, ponte a trabajar. Cuando lleves tres Sprints mira cuantos elementos del Product Backlog has completado y calcula la media y la desviación. Por ejemplo, un equipo podría tener una medición de 10 +- 3 elementos. Lo que supone esto es que en el mejor de los casos hará 13 y en el peor 7. ¡Empezamos a ser predecibles!
Si hacemos esto empezaremos a tener menos tiempo dedicado a estimar y más tiempo dedicado a hablar sobre cómo nos vamos a organizar. ¿Qué vamos a hacer cuando Pablo se vaya la segunda semana del Sprint de vacaciones? ¿Y si a Rosa finalmente le operan de la pierna? ¿Qué hacemos con Pedro que es junior? Todo esto entra dentro del debate que debería tener un Scrum Team en vez de estar sacando cartas para “jugar” al planning poker.
El gran problema del EvBM es que requiere romper el paradigma de dar siempre fechas y de que si eso no ocurre es que no estamos comprometidos. ¿Qué mejor manera de comprometernos que ser capaces de decir “no se lo que voy a tardar”? Porque señores, esa es la verdad. Por muchos intereses económicos que tengamos, decir que se puede hacer algo sin haber “picado” una línea de código es mentirnos a nosotros, a nuestro cliente y a nuestra profesión. Y aquí aparece el valor de Scrum Compromiso. Compromiso con nosotros y con un buen trabajo.
Esto no quiere decir que nunca hablemos de fecha, solo que hablaremos de ellas cuando tengamos experiencia en este contexto con el equipo que tenemos. Se que es difícil porque muchas veces queramos o no tenemos negocio, esto requiere de una estrategia clara de venta y también de la imagen que queramos tener en el mercado. Por lo que en el mundo consultoría conseguir que Scrum cale cuesta mucho. ¡La competencia da fechas!
Finalmente, y si nos encontramos con un pintor que en vez de estimar nos dice que no sabe lo que va a tardar ¿Qué haremos?

4 comentarios en “Si un pintor va a tu casa y te dice lo que tarda, ¿Por qué en software no lo hacemos?”

  1. Lo difícil es que un gerente confíe en tu palabra cuando le dices : “no sé lo que voy a tardar” y apueste porque estás haciendo todo lo posible por sacarlo.
    “Este en lugar de estar trabajando a tope para sacarme las cosas va a tomarse su tiempo y eso no es bueno para mí producción”.

    Pero más difícil es que no se tenga una fecha para aproximar a tu cliente (el que te paga) cuando va a tener el producto.
    “Quiero el producto porque hace falta, si no me lo das tu se lo contrató a otro”.

    Pero más difícil si hay un coste por ese producto .
    “Si no entrego la semana de tal empezaré a perder valor de compromiso y económico, mi produyse penaliza con dinero y eso duele” .

    Me gusta

    1. Muy de acuerdo. Ahí es la confianza la clave, y alguna estrategia para que funcione es ir a un modelo cerrado con margen y tratar de ganártela, pero corres el riesgo de siempre… Es algo que debemos resolver los agilistas y las organizaciones 🙂 gracias

      Me gusta

  2. Cómo se podría calcular la predictibilidad para los siguientes sprints, si en el ejemplo donde se obtiene el 10+-3 se asume que los elementos son de características similares para su construcción. Muchas veces, no suele ser así para todos los elementos de un Backlog, ya que el esfuerzo, tiempo y complejidad son distintos entre sí.

    Me gusta

    1. Buenas,
      precisamente, por eso damos un margén de más menos 3, por que atendemos elementos de diferente dificultad. Puede ocurrir que haya sprints de 7 y Sprints de 13, ahí está la gracia. ¿Qué ocurre si tenemos elementos muy dispares? Puedes que nuestro margen será muy elevado, imagina un 10+-8 (mínimo 2 máximo 18). Esta margen tan elevado, hace que sea menos útil. Si como PO queremos ser más predecibles, hay que trabajar mucho el backlog para tener elementos “parecidos” que nos permita ser predecibles.

      ¿Crees que podría ayudar?

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s