Llevando Scrum a grandes organizaciones

Ha sido un año muy intenso. Tan intenso que he dejado mi pobre blog abandonado. Tenía tantas cosas que contar que no he podido contar nada. Ha sido el trabajo de Sisifo, no lo voy a negar, pero ha sido muy enriquecedor. Y parece que con Septiembre todo vuelve a empezar. El mito de Sisifo continua.

Angel Medinilla y un servidor solemos bromear sobre quien de los dos llevo la primera implementación ágil en este país. Entre los dos anda el juego. Sin duda hemos visto mucho del proceso que ha llevado a la popularización de Scrum. El primer post sobre agilidad en este blog es de 2006. Ya ha llovido. Ahora puedo hablar con algo de perspectiva.

Si este año ha sido tan intenso es por que la percepción de la empresas hacia las metodologías y las prácticas ágiles ha cambiado de manera clara. El boom ha sido grande, las metodologías ágiles han ganado tracción y se han popularizado. Han surgido cientos de telepredicadores, de certificaciones de dudosa utilidad, de interpretaciones de Scrum que pondrían los pelos de punta a los padres de la criatura, de gente que habla de agilidad y en su vida ha tirado una línea de código, y menos aun gestionado un proyecto, de telepredicadores, de empresas que han tirado CMMi a la basura y se han lanzado de cabeza a Scrum… sin duda no todo lo que se deriva de la popularidad de las metodologías ágiles ha sido bueno, aunque el balance es netamente positivo. Cada vez hay en España empresas ágiles más grandes o más granes empresas ágiles. Eso si ahora es más difícil separar el grano de la paja: todo el mundo es ágil, todo el mundo quiere se ágil, todo el mundo te quiere vender agilidad y pocos se dan cuenta de lo lejos que está el objetivo, de lo largo que es el camino.

Pero bueno voy a dejar de divagar y a centrar el tiro en lo que es el objeto de este post, contar a grandes rasgos, la experiencia vivida y adquirida durante este año en el que mi trabajo en lo relativo a Scrum a cambiado de manera radical. He pasado de llevar Scrum a equipos de entre 4 y 9 desarrolladores a llevarlo a empresas con entre 5 y 15 equipos de desarrollo. Un cambio radical.

El manifiesto ágil no es suficiente. Los empresas quieren ser ágiles, pero necesitan respuestas. No vale ponerse el modo gallego y decir depende. Las inercias son difíciles de romper. Tienes que dar respuestas, respuestas que a veces no están en los libros de gestión ágil de proyectos sino en libros de ingeniería del software. La gente quiere saber como organizar sus ramas de desarrollo, cómo evalúo mi backlog, cómo hago estimaciones, cómo hago mi sistema testable, como implemento testeo automatizado en sus múltiples variables, que hago para mejorar la calidad, por qué necesito testers, cómo evalúo las métricas, como mido el avance del proyecto, … y no las empresas no quieren especular, no vale decir eso de el manifiesto ágil dice que valoramos más los elementos… que no, que quieren respuestas, bibliografía y respuestas claras, tajantes y convincentes que puedan transmitir, punto. Y que nadie se olvide, Scrum está muy bien como marco, pero sus fundamentos y las técnicas básicas de calidad e ingeniería del software que lo sustentan llevan más de un cuarto de siglo descritas. Lee sobre gestión de proyectos básica.

Dos días de formación no te hacen ágil. Sin duda formarte en Scrum es una condición necesaria. Hay que formar a todos los miembro del equipo, sin que falte ninguno. No funciona eso de formar a los mandos intermedios y que estos lo transmitan. El motivo es claro, Scrum  cuando se lleva a la práctica y más a nivel empresarial está lleno de preguntas, y es necesario una bagaje importante en gestión de proyecto y un plus de credibilidad extra para responderlas. Los mandos intermedios que me encuentro, en su gran mayoría buenos profesionales, no tienen el conocimiento necesario sobre gestión de proyectos y carecen de la credibilidad extra que tiene alguien de fuera. Una formación de Scrum dura dos días, ni más ni menos. Pero no te capacita para hacer Scrum de igual manera que estudiar dinámica no te hace esquiador. Solo la práctica de Scrum te habilita a hacer Scrum y los golpes que te vas a dar, dependen de lo bueno que sea quien este esquiando a tu lado. Cuantos más golpes se haya dado tu Scrum Master, menos se va a dar tu equipo. Un curso de dos días no da margen para caerse lo suficiente. Las certificaciones están haciendo daño. Mucho Scrum Master de postal. No voy a cometer nunca más el error de simplemente formar a equipos de empresas. Si una empresa quiere solo formación sobre Scrum y cree que eso es suficiente para llevar Scrum a una organización, que llame a otro. Algunos incluso te dan una etiqueta de Anís del Mono. Si quieres que lleve Scrum a tu empresa, no me pidas solo formación, por que no es suficiente. Te voy a decir que no quiero ese proyecto, así de simple. No me va a volver a ocurrir dar formación a varios equipos de una empresa, que se maten a golpes tratando de hacer funcionar Scrum y que luego sea otro el que venga a corregir el desaguisado. Visibilidad, inspección y adaptación: los errores una vez y no más.

Todo el mundo quiere atajos. Todo el mundo quiere que formes a su equipo en medio día. Y tener Scrum en toda la empresa en un mes. Pero esto no funciona así. Hacer funcionar Scrum exige tiempo, dedicación, una inversión. He visto como me regateaban delante de un equipo el poder ayudarles con un Sprint Planning Meeting o como negaban comprar dos pizarras y un panel, mientras diez operarios pintaban y cambiaban todos los logos de la empresa por que alguien había decidido que el logo antiguo no era ‘dinámico’. Scrum te va a exigir invertir tiempo y dinero, vas a tener que hacer un esfuerzo. No te va a costar tiempo y dinero, cuando empieces a ver los frutos de tu inversión verás como se recupera con creces. Scrum es una inversión, no un coste, pero como toda inversión exige un desembolso inicial. El balance entre tiempo y dinero depende de cuanta experiencia estés dispuesto a pagar. No necesitas un coach para hacer Scrum, yo lo implemente sin un coach la primera vez, pero es más probable que cometas errores o fracases.

Después de tu primer Sprint Review solo has dado en primer paso. Entiendo perfectamente que los gestores de una empresa tienen que responder ante sus jefes y exhibir resultados. Pero lo siento, mostrar tu primer burdown chart o los resultados de una retrospectiva como quien a cortado una oreja en La Monumental no demuestra que estés haciendo Scrum. Ni siquiera demuestra que estés en el camino de Scrum, demuestra que estás dando pasos, que no es poco, pero que no es todo. No hay un fin. Este es un camino sin fin. Solo tras varios meses vas a ver tu éxito o tu fracaso. Se que es motivador, se que es excitante, se que estás visualizando tu proceso y que ahora tienes métricas que hace semanas ni soñabas. ¡Pero eso no es nada!, al menos hasta que tengas un proceso claro de crítica continua y continua mejora de tu proceso de desarrollo.

Las herramientas importan. Evidentemente las herramientas no son lo más importante. La gran mayoría del software que rige Internet se escribió usando vi como editor. Pero si que son importantes. Las herramientas que elijas van a afectar de manera clara a la curva de aprendizaje de técnicas sin las que Scrum es más duro de implementar. Valora que herramienta es adecuada y si tienes varios equipos procura que compartan herramienta ¿cómo van a aprender unos de otros si usan herramientas diferentes?. Presta atención a tu herramientas, afílalas, púlelas, mantenlas limpias y preparadas para la batalla. Automatiza, automatiza y automatiza. Lima todas las esquinas y asperezas de las herramientas que drenan productividad. Evidentemente si tus equipos comparten herramienta, te ahorras pulir ciertas esquinas dos veces. Es preferible un mal cuchillo bien afilado, que un buen cuchillo con el filo mellado. Aunque lo ideal, sin duda, es un buen cuchillo bien afilado. Si vas a llevar la agilidad a tu organización asegúrate de tener alguien que afile el cuchillo.

La ingeniería del software importa. Nadie me va a convencer de que Scrum es suficiente. No lo es. Scrum no es nada sin buenas prácticas de ingeniería del software. Si formas a tu equipo en Scrum y no lo formas en TDD, calidad, automatización, gestión de la configuración etc… ¿Cómo va a actuar tu equipo cuando encuentre impedimentos técnicos? La experiencia me ha demostrado que los impedimentos técnicos son un gran porcentaje de los que aparecen durante las retrospectivas. Si quieres tener éxito vas a tener que mojarte y capacitar a los equipos en aspectos técnicos.

No hay Product Owners. No existen. Son como el monstruo del Lago Ness. Es un rol clave que las empresas tienen más que serios problemas para cubrir. Casi siempre ocurre lo mismo. Se coge a los Product Managers o a los comerciales y se les dice: ‘ahora eres Product Owner, PO para los amigos’. Y eso es todo. Este enfoque falla por dos aspectos: uno, el ratio entre Product Managers y desarrolladores es sistemáticamente insuficiente. Acabas con un PO para seis equipos, situación claramente insostenible. Y dos, los PM de Power Point y reunión que tanto abundan resultan ser muy malos PO. No se trata de guiar a alto nivel un producto, de decidir si pondremos en letras grandes nueva versión con Cirintione o destacaremos más el nuevo condensador de fluzo de nuestro software, no. Se trata de definir en detalle características, evaluar el retorno de la inversión, priorizarlas y asegurar que se desarrollan con la calidad suficiente y no más que el cliente demanda. Casi nada. No hay Product Owners, hay que crearlos. Tendrás que formarlos, entrenarlos, dejar que se equivoquen varias veces, lograr que aprendan y luego podrás decir que tienes Product Owners. Ni siquiera puedes contratarlos, ¡recuerda que no existen!.

No hay equipos. El primer trabajo que tienes que hacer para extender Scrum por una organización es saber qué carajo es un equipo en esa organización. Y no, no hay organizaciones a las que haya llegado y me hayan dicho de manera clara que es un equipo para ellas. Cada uno tiene una visión. Y nadie sabe en que equipo juega. Y donde hay equipos son de 20 o 30 y tienes que partirlos. Definir que es equipo es difícil, pero cuando logras poner en la pizarra los equipos, quien será su PO y quien será su Scrum Master, has dado un paso de gigante. En la empresa más grande, la que más equipos tiene, nos llevo más de dos días de rompernos la cabeza.

Los tester, si existen, tienen que cambiar radicalmente su rol. Ya no son la policía de la calidad que certifica los indolentes que somos los desarrolladores en este aspecto (que lo somos). No señor. Los testers pasan a ser los facilitadores de la calidad. Establecen los mecanismos necesarios en colaboración con el equipo de desarrollo e incluso integrándose en el para que la calidad brille. En un entorno realmente ágil los testes son miembros del equipo de desarrollo. Esto choca con la cultura imperante en las empresas donde se sigue concibiendo la labor del tester como el certificar la ausencia o presencia de calidad en fases finales del desarrollo. Desde hace años se sabe, todos los esfuerzos de calidad en el software tienen que estar orientados a detectar los defectos de manera temprana. El coste de los defectos crece exponencialmente con el tiempo. Esa es la máxima que debemos recordar. Solo acercando a los testers a las fases más tempranas del desarrollo lograrás que el trabajo sea eficiente y los desperdicios mínimos. Generalmente las organizaciones entienden bien este cambio cuando se explica. El problema es que muchas siguen pensando que la calidad surge de la nada.

Necesitas el respaldo de la gerencia. Estamos hablando de cambiar la manera en la que una empresa funciona. Esto transciende el ámbito del equipo. No valen tácticas que he sugerido en otras ocasiones. Si no tienes todo es soporte claro y absoluto de alguien de mucho peso, mejor vete a casa. Y empieza por un solo equipo, que no es moco de pavo. Ya hablaremos de como lograr ese respaldo en otro post.

No todo son malas noticias. Yo no voy a titular este post Agile mato a mi gato, no se trata de sensacionalismo sino de realidad. La realidad, al menos la que yo he visto, es la que he relatado, pero lo que es fantástico es que cada vez más y más organizaciones más y más grandes están luchando para cambiar la manera en la que desarrollan software. Y aunque el camino no está exento de dificultades, el balance es positivo. Cada vez que oigo como un desarrollador habla de la manera en que Scrum ha impactado en la organización en la que trabaja oigo cosas positivas. Tengo clientes que incluso están haciendo esfuerzos para extender Scrum a sus proveedores o que organizan charlas-café para que les cuente a sus clientes que es Scrum y transmitirles como han cambiado las cosas a mejor en su organización. Las empresas que implementan Scrum lo están contando con orgullo al mundo, están evangelizando. Con todos sus problemas, dificultades y fallos ¡Scrum funciona!.

El balance es claro: Scrum ha llegado y está aquí para quedarse.

10 comentarios en “Llevando Scrum a grandes organizaciones”

  1. Me encanta encontrar algo de realidad ágil …

    A ver si hacemos un flyer con todo lo que has escrito y lo repartimos bajo la puerta de tantas empresas que esperan ser ágiles en 1 mes.

    Y si, soy alguien más, que está viviendo eso…

    Y veo que grabas uno que otro podcast con mi buen amigo Juan Palacio, recuerdo hace un tiempo haber grabado algo con él también para scrummanager…

    A ver si conversamos y un día te vienes para Lima, Perú… a unir fuerzas.

    Tomando en cuenta que estamos organizando el Agiles 2010 de este año… que se viene en 2 semanas…

    Un abrazo,

    Raúl.

  2. Muy buen artículo Rodrigo.

    Aunque creo que pese a ser blogueros veteranos, no fuimos los primeros.
    Hay programadores y gestores muy buenos, de los que podríamos aprender mucho que no tienen blog ni dan clases: lo practican. 🙂

    Mis dos directores técnicos (espublico y safecreative) que son un auténtico lujo y ninguno bloguea ni enseña. 🙁

    Enhorabuena por el artículo.
    Un saludo!

  3. Hola Juan:

    Es un poco dificil aprender de quien no comparte mediante un blog o ayudando a otros a poner Scrum en marcha.

    Mi primer burndown chart es de enero de 2005, de un proyecto en el que, evidentemente estaba participando. Es tontería discutir quien fué primero, es un juego que nos traemos Angel y yo. Pero si estoy seguro, que si no fuí el primero en poner en marcha un proyecto con Scrum en España, si que estube entre los pioneros.

    Lo comento en este post simplemente para dejar claro que hablo desde la prespectiva que da el tiempo, nada más.

    Un saludo y gracias por tu comentario.

Deja un comentario

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