¿A qué huele Scrum?

Cómo ya vengo comentando últimamente, cada vez hay más hype, o como lo queráis llamar con el tema de metodologías ágiles, y más concretamente Scrum, y la verdad es que cada vez que hablo de Scrum, más hay que poner énfasis en los valores de Scrum.

La gente, en algunas ocasiones, se pierde en el tema de las prácticas de Scrum, que si, que por si solas nos ayudan, y bastante, a organizarnos y centrar el trabajo, pero Scrum es más que eso, y lo realmente importante para mi son sus valores, la esencia que podríamos decir en el plano filosófico trascendental.

Lo primero, y algo que Rodrigo Corral no se cansará de decir, es que es una metodología empírica, esto es, tenemos que estar constantemente inspeccionando y adaptando nuestras decisiones y los procesos en tiempo real, basándonos en datos actuales y respondiendo rápidamente a las condiciones cambiantes del entorno. Esto es básico en todas las metodologías ágiles, ya sabéis, responder a los cambios antes que simplemente seguir los planes a ciegas.

¿Para qué vamos a dar soluciones a problemas que no tenemos?, esto es, partiendo de lo anterior, tenemos que estar atentos a los posibles problemas que nos vayan a surgir, por supuesto, pero hemos de ser flexibles, de nada nos vale intentar dar solución aun problema que nos puede surgir dentro de 3 meses, cuando no sabemos como el entorno va a evolucionar en estos 3 meses. Esto está muy relacionado con, por ejemplo, la arquitectura de las soluciones, en las que muchas veces el Big Upfront Design nos da como resultado una arquitectur totalmente inflexible, que no da respuesta ni aa los problemas actuales, ni a los que no conocemos aún que tenemos.

Muy importante en Scrum, y algo que no me cansaré de insistir, es la auto-organización, es básico, cuando acometemos un sprint es un compromiso (otro de los valores fundamentales), que adquirimos como equipo. Por tanto es importante conceder al equippo la capacidd de auto-gestionarse, para esto contaremos con equipos multidisciplinares, que tengan la capacidad de poder tomar las decisiones necesarias para crear productos de alta calidad y gestionar sus propios procesos, ¿quién puede tomar mejor las decisiones sobre un trabajo, más que el que lo va a hacer?. Ojo, nadie dice que esto sea fácil, pero tampoco quiere decir que necesitemos obligatoriamente un equipo de, únicamente, superhombres, héroes, o como queráis llamarlos, por supuesto, para producir productos de calidad, necesitas equipos de calidad, de gente predispuesta a enseñar y aprender (sí, las dos cosas), nadie nace sabiendo, y vamos aprendiendo por el camino, apoyándonos en gente que sabe más que nosotros y en gente que sabe menos, para esto lo importante es dejar a la gente auto-organizarse, y proporcionarle los medios necesarios para ello.

El compromiso, ufff, esto suena difícil ehh, pero es importante, cuando cerramos un sprint planning meeting, estamos adquiriendo un compromiso en ambos sentidos, por un lado el equipo, que se compromete a gestionarse para cumplir el objetivo, ya que ellos mismos han sido parte importante, mediante sus estimaciones, ¿cómo puedo comprometerme si no, a algo que yo no he sido partícipe?, si el equipo, reiteradamente, no se toma en serio este compromiso, incumpliendolo, o sin tomarselo en serio, lógicamente no podemos pedir que nos dejen auto-gestionarnos, en ese caso ya hemos demostrado que no sabemos hacerlo.

Esto no quiere decir jornadas de 16 horas trabajando, fines de semana, etc., esto siginifica tomarse en serio el compromiso y ser realistas con lo que nos comprometemos, no sentar falsas expactativas ni similares. Por supuesto, como dicen los americanos shit happens, pero lo importante es tener la información de en que punto estamos, hacia dónde vamos, como nos afecta el shit happens, etc., otra de las partes fundamentales, tener la información (¿recordáis lo que son los daily scrum?)

Y también, como no, compromiso por parte del Product Owner, que se compromete a no cambiarnos el ámbito del sprint, sin este compromiso, el equipo tampoco puede comprometerme, por qué, ¿cómo puedo comprometerme a cumplir un objetivo en un plazo de tiempo si me cambian el objetivo o el mismo no está claro?

Y llegamos a otro punto, bueno otros dos puntos, la priorización y los plazos de tiempo. Si tenemos que responder al cambio ¿por dónde empezamos?, priorizando, aquí entra en juego el Product Owner, que tiene que decidir que es lo más importante en el punto actual, y empezar a acometerlo. Y claro, para esto necesitamos fijarnos plazos, en Scrum, estos son de unas cuatro semanas, durante las que nos centraremos en lo que hemos priorizado como más importante, y el equipo ha estimado que se puede comprometer a ello, pasado ese tiempo, habrá que volver a juntarse, repriorizar el siguiente trabajo a acometer.

¿Qué fácil parece todo cuando está escrito verdad?, efectivamente no es fácil acometer esto, y requiere de un cambio organizacional importante. Todo esto del compromiso, la auto-organización, el trato directo con todas las partes implicadas en el proceso es muy importante, por desgracia, estamos acostumbrados al entorno de trabajo de “yo-mando-tu-haces”, y pasar de ahí a un entorno colaborativo no es fácil.

Hay que promover el coraje del cambio, la apertura a las aportaciones de todos, y a favorecer el avance colectivo, por encima de los héroes, o las personas imprescindibles. Todo esto se resume en el respeto mutuo a todos los niveles en las organizaciones.

Pero esto del cambio organizacional, el coraje, etc, ya lo dejo para otro post ….

5 comentarios en “¿A qué huele Scrum?”

  1. Me encanta la agilidad, me encanta scrum… pero se está generando un clima de mal estar en contra de las metodologías de desarrollo predictivas, … no creo que sea nada bueno.

    Comentarios que implícitamente relacionan algunas de las expresiones que utilizas con metodologías no ágiles como por ejemplo: «yo-mando-tu-haces». Seguro que sin mala intención 😉 Pero el caso es que es así, parece que si no usas scrum no estás a la «moda» y no es así, no hay balas de plata!! Creo que antes de usar una metodología u otra, habrá que hacer un estudio previo del entorno (cliente, proyecto, equipo…)

    Me resulta muy gracioso hablar con gente que dice que hace scrum, pero cuando profundizas en la conversación te das cuenta que no saben cuantos puntos función han liberado en el último sprint, o no conocen la velocidad de su equipo, no utilizan técnicas de estimación ágiles, no saben el retraso acumulado que llevan… en fin! que porque hacen un daily scrum meeten cuando toman el café todos los días ya dicen que hacen scrum… pero se sienten guay por que son ágiles.

    Una cosa es el concepto de agilidad y otra es una metodología de desarrollo, me explico, … creo que puedes tener respuesta al cambio, valorar a las personas y reuniones informales diarias, colaborar con el cliente y hacer CMMi, ¿no? y … ¿eres ágil? … no está así escrito en el manifiesto ágil?? y no estás haciendo «scrumemei», no! luego habrá que separar el concepto de agilidad del concepto de metodología.

    Por lo que relacionar comentarios y prácticas de forma general con las metodologías tradicionales crea confusión y no es real.

    Perdón no quería extenderme mucho pero se me ha ido de las manos 😉 un saludo!!

    Miguel Sierra

  2. Gracias por tu comentario Miguel, si lees algún post mío previo, hablo en términos muy parecidos a los tuyos. Por supuesto que no hay balas de plata, y por supuesto que hay mucha gente que mola y no hace scrum. Es mas, nunca me oirás o me leerás que scrum asegure el éxito.
    Y no tengo nada en contra de las metodologías productivas, de hecho no leo nada en mi artículo en ese sentido. Si que tengo en contra cosas respecto a modelos en los que uno manda y el resto obedece a ojos cerrados, eso por lo general no funciona con personas con un mínimo de interés por lo que hacen.
    Pero por supuesto es una opinión personal, y por tanto totalmente subjetiva.
    Pero si quiero recalcar: en ningún momento digo que scrum sea lo mejor, lo que más mola y que el resto no, en ningún momento me he metido con las metodologías productivas, CMMI, formales o como quieras llamarlas, y en ningún momento he dicho que solo las metodologías ágiles, en general, aseguren el éxito, espero que mi opinión esté clara al respecto.

  3. Conociendo la opinión de Luis con el que he hablado en innumerables ocasiones respecto a las metodologías ágiles y no ágiles, y leyendo lo que dices Miguel, creo que los dos tenéis razón y los dos habláis de la misma idea.
    En mi ya conocido artículo de «Explicando Scrum a mi abuela» de hace 3 años y medio, indico algo que los dos habéis comentado, que Scrum no es válido para todos los equipos ni todas las personas, y obviamente tampoco para todas las empresas.
    Incluso encajar Scrum en algunas culturas empresariales es no difícil, sino imposible, y como es lógico también, Scrum no es la solución a los problemas, es un camino más de los muchos que hay, y coincido en que me da mucho miedo ver que la gente habla de Scrum como solución y remedio de todos los males y llevarlo a etiquetar de «moda», esto último me pone los pelos de punta. 🙁

  4. En mi empresa se utiliza SCRUM en casi todos los departamentos. Se empezó por IT, y funcionó relativamente bien, y desde hace un tiempo se aplica en el departamento de Marketing.

    Por experiencia, puedo decir que SCRUM tiene sentido en un departamento de IT, aunque cuando estás en la otra parte, NUNCA tienes la certeza de cuándo van a entregar un proyecto que TU necesitas. Al fin y al cabo el equipo decide lo que hace, y aunque el P.O. puede reconducir la situación, uno puede perder unos meses bastante valiosos.

    Por otra parte, aplicar SCRUM ciegamente al departamento de MK creo que es un gran error, pues ciertos roles se diluyen. Si, es bueno pensar en el global de la empresa, y por eso SCRUM quizás puede aportar cosas positivas, pero no tiene sentido, p.ej. que el responsable de un canal o área deje de ser responsable de ese canal o área y que los otros que no tienen nada que ver puedan decidir sobre su área. Especialización y conocimiento es necesario, y también estar encima de algo. Y el SCRUM no te permite esto.

    Además, SCRUM tiene un componente sectario que no «mola». Si no crees en él desde el principio, el grupo te margina y cuestiona cada una de tus acciones.

    SCRUM tiene cosas positivas, como todo, pero no se puede llegar al extremo como algunas consultorías especializadas en implantar el «cambio» en las organizaciones nos pretenden hacer ver. Se tiene que saber coger lo bueno del SCRUM y mantener muchas de las cosas que siempre han funcionado. Y sobretodo, adaptarlo a la realidad del departamento.

  5. Buenas Eric, gracias por el comentario.

    Lo primero, lo de que el equipo decide lo que hace es cierto, se autoorganiza, pero para la parte que les compete, el que debería dirigir las prioridades del producto es el PO, que es el que sabe cuando y que necesita, y en eso, el equipo puede recomendar, pero nunca imponer, de hecho nadie puede imponer nada.

    Lo del componente sectario, la verdad es que comparto tu opinión, cada vez veo más ese componente en listas de correo, foros, etc, y no, no me gusta nada 🙁 pero para eso ya escribí otro post de como scrum parece que se está conviertiendo en una moda que ciertas personas siguen ciegamente 🙁

    En fin, que gracias de nuevo por compartir tu opinión.

Responder a jorge Cancelar respuesta

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