Back to Blog

Al mal SCRUM buen Agile

Fecha: 18-junio-2020 Tiempo de lectura: 7 min

Author

David Bonet

No quiero sentirme orgulloso sólo de lo que he hecho, sino también de cómo lo he hecho. El fin no justifica los medios. Eso y ser feliz con mi familia

El 90% den el desarrollo web en empresas y startups se hace intentando usar SCRUM, aun así, en experiencia, muy pocas empresas son Agile. El problema es que SCRUM existe como una forma de implementar Agile, y si no eres Agile tu SCRUM va a ser una fuente de tensiones y conflictos. Solo como referencia antes de empezar, leamos las definiciones de Agile y SCRUM de la Wikipedia:

Agile software development comprises various approaches to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customers/end users.

Scrum is an agile process framework for managing complex knowledge work, with an initial emphasis on software development, although it has been used in other fields and is slowly starting to be explored for other complex work, research and advanced technologies.

Por lo que podemos ver, SCRUM es un framework basado en Agile.

Ejemplo de un SCRUM no Ágil

Supongamos un equipo de 5 personas: 1 Product Manager y 4 Programadores. A este equipo se le encarga hacer un panel de administración para mejorar la eficiencia del departamento de operaciones. Hasta aquí todo bien. El equipo se pone a investigar y propone este panel a los jefes:

my img

El proyecto se aprueba y el equipo empieza el desarrollo. Como internamente se organizan usando SCRUM lo primero que hacen es partir el trabajo en tickets. Más o menos queda así:

my img

De ahí hacen una estimación de complejidad usando puntos, Tamaños de camisetas u otros sistemas y más o menos llegan a algo así:

my img

Llegados a este punto, el equipo asume que cada segmento vertical es un Sprint y un programador. Así que asignan A y B a una persona, E a 3 personas, C y D a otras 2, etc. Este proceso cambia de empresa a empresa pero al final siempre se llega un punto parecido.

Pasado un Sprint empiezan los primeros conflictos. La tarea E se retrasa, C y D hay que cambiarlas por que el departamento de operaciones cree que con unos pocos cambios podría ser mucho mejor, etc.

En el tercer Sprint la tarea E, H e I no avanzan y parece que el equipo no es capaz de sacar el trabajo al que se ha comprometido. Además negocios y el departamento de operaciones no paran de cambiar los requisitos. No es que sus sugerencias sean malas, pero no ayudan cuando el equipo ya está bajo presión.

Al final, después de otros 4 Sprints el equipo tiene todo listo y funcionando. Para entonces negocios, el departamento de operaciones y el equipo de desarrollo están ya un poco a la defensiva, pero lo importante es que el trabajo ha salido. Por su puesto, ya hay una versión 2 esperando por que ahora que operaciones está usando el proyecto quiere mejoras.

El problema

Pasado el 50% del desarrollo el equipo está permanentemente estresado, salen tensiones con operaciones y negocios y sea cual sea el proyecto siempre, repito, siempre, se retrasa con respecto al tiempo que “tendría” que costar.

Todo esto pasa por que el realidad el “SCRUM” que el equipo ha usado es un Waterfall con Sprints sin la planificación inicial del Waterfall.

Cambio de perspectiva

Seamos honestos. Pero brutalmente honestos. ¿Estás listo? Ni tú ni yo conocemos el futuro ni conocemos todos los entresijos del departamento de operaciones. Y a no ser que te hayas pasado el último año trabajando en el departamento de operaciones, tú idea de lo que hacen es bastante inexacta.

Pero aún así negocios espera que conozcas lo que operaciones necesita, el Product Manager intentas demostrar que conoce (¡incluso mejor que ellos!) lo que operaciones necesita y todo el mundo vive en la fantasía de que el proyecto es fácil de hacer y cosa de ponerse “en serio”.

Veamos, para el proyecto que el equipo ha acabado, lo que realmente sabían que operaciones necesitaban:

my img

Para las partes sencillas puedes estar seguro que la solución propuesta es más o menos lo que se necesita. Para las partes complejas (o dicho de otra forma, que tienes muchas subpartes no intuitivamente divisibles) la historia es distinta. Podemos estar seguros que habrán cambios de requisitos.

Toda esa planificación y desarrollo se tendrá que rehacer cuando el producto se lance.

Reintroduciendo Agile

Volvamos al inicio, cuando se plantea la necesidad de un panel de control. En ese estadio intentemos crear la versión mínima (pero mínima de verdad, raquítica incluso). Eso sería, de la imagen previa, la parte blanca (no marcada) de las columnas.

Una vez ahí, no planifiques más, simplemente lanza el proyecto. Deja que operaciones lo pruebe y te diga que es lo que más necesita ahora. Estamos hablado de algo así:

my img

Haz varias iteraciones. Deja que los programadores entiendan el problema también, que sepan como, lo que han creado, se usa. Que el Product Manager tenga tiempo de aprender las necesidades reales de operaciones. Y sobre todo, lo más importante, deja que el Product Manager pueda experimentar.

Iterar no solo te permite evitar tirar trabajo, si no que permite experimentar y descubrir las necesidades de quien va a usar el producto. Eso incrementa el potencial de calidad del producto ya que experimentar ayuda al Product Manager a crear mejores soluciones que si lo diseña todo de una vez.

La primera iteración tendría que ser, más o menos, esta:

my img

Al final quedaría algo así, siendo cada color una iteración del proyecto.

my img

Por su puesto, cuando estás en la primera iteración no sabes como van a ser el resto de iteraciones, es algo que descubres sobre la marcha.

Si desarrollas de forma iterativa no solo crearás soluciones de mayor calidad, sino que reducidas tiempo perdido, tensiones, cansancio y desmotivación del equipo.

Con esto espero poder ayudar a enfocar tú siguiente proyecto de forma iterativa y que eso mejore tu día a día.

Lean y Data Driven Management

Estos dos temas están muy relacionados con Lean Management y Data Driven Management. Ya hablaremos en otros posts sobre ellos, pero los concepto principales en todos ellos son Iterar, Experimentar y Decidir con datos en la mano.

TL;DR

En resumen, asegúrate de que tu SCRUM es realmente Ágil. Itera pronto y no asumas que sabes algo que puedes verificar experimentalmente. Con cada iteración descubrirás nuevas cosas que te guiarán a un producto de calidad.

Sobre Couragium

En Couragium nos gusta trabajar con Agile y Lean. Nuestros desarrollos son iterativos y nuestras decisiones se basan en datos que obtenemos experimentalmente. En nuestra experiencia esta es la forma de acercar el producto a un mercado siempre cambiante con un producto continuamente de calidad. Si Agile es lo que buscas, no dudes en pedir una cita en el botón superior del Menú.

Mitos

  • Mito: Pero si lo hago así el desarrollo tardará mucho más!

    Respuesta: No tiene por que. En un mundo ideal donde de verdad la solución propuesta es exactamente lo que se necesita, si. En el mundo real donde la solución propuesta es algo que nos imaginamos que es lo que se necesita, hacerlo de un tirón solo hará que tengas cambiar cosas ya hechas y pulidas una vez lanzado el producto.

  • Mito: Si itero los programadores estarán parados entre iteraciones.

    Respuesta: La realidad no es tan cuadrada. Si estas desarrollando 4 características, puedes tener varios lanzamientos en tiempos distintos. Cuando un equipo acaba una iteración puede empezar con otra iteración de otra o ayudar a otro equipo.

  • Mito: Negocios/Mi jefe nunca aceptará un proyecto si no está definido.

    Respuesta: Si tu empresa espera de ti que lo sepas todo sobre el trabajo de todos, bueno, igual puedes tener una charla con tu jefe. Si no hay forma de convencerles, igual merece la pena evaluar que tipo de confianza tienen en ti y si es algo que quieres aceptar.

  • Mito: Pero en mi empresa no podríamos trabajar así nunca por el tipo de proyecto.

    Respuesta: Puede ser, pero a no ser que estés en la industria miliar o en acuerdos comerciales de altísimo nivel, no creo que sea el caso. Desde sistemas empotrados hasta webs pasando por aplicaciones de móvil y PC se pueden hacer iterativamente.

  • Mito: Si no me firman los requisitos me pedirán siempre cambios y mejoras.

    Respuesta: Si la gente pide mejoras es que aun hay fricciones en el producto. Las quejas no se pueden escuchar literalmente. Si eres un empleado y lo que dicen no es tan prioritario como tus otras tareas, entonces no tienes por que hacerlo. Si eres freelance y haces Agile el contrato no puede ser cerrado temporal/económicamente. Si el cliente no acepta contratos abiertos igual puede ayudar proponer un contrato por fases y objetivos (consultoría, pago, definición de requisitos, desarrollo, aceptación, pago y repetir).

my img

Nunca dejarás de sorprenderte del resultado si iteras hasta descubrir lo que de verdad se necesitaba.