Llevando Scrum a grandes organizaciones

Ha sido un ao muy intenso. Tan intenso que he dejado mi pobre blog abandonado. Tena 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 contina. Angel Medinilla y un servidor solemos bromear sobre quien de los dos llevo la primera implementacin gil en este pas. Entre los dos anda el juego. Sin duda hemos visto mucho del proceso que ha llevado a la popularizacin 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 ao ha sido tan intenso es porque la percepcin de las empresas hacia las metodologas y las prcticas giles ha cambiado de manera clara. El boom ha sido grande, las metodologas giles han ganado traccin y se han popularizado. Han surgido cientos de telepredicadores, de certificaciones de dudosa utilidad, de interpretaciones de Scrum que pondran los pelos de punta a los padres de la criatura, de gente que habla de agilidad y en su vida ha tirado una lnea de cdigo, y menos an 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 metodologas giles ha sido bueno, aunque el balance es netamente positivo. Cada vez hay en Espaa empresas giles ms grandes o ms granes empresas giles. Eso si ahora es ms difcil 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 ao 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. Las empresas quieren ser giles, pero necesitan respuestas. No vale ponerse el modo gallego y decir depende. Las inercias son difciles de romper. Tienes que dar respuestas, respuestas que a veces no estn en los libros de gestin gil de proyectos sino en libros de ingeniera del software. La gente quiere saber como organizar sus ramas de desarrollo, cmo evalo mi backlog, cmo hago estimaciones, cmo hago mi sistema testable, como implemento testeo automatizado en sus mltiples variables, que hago para mejorar la calidad, por qu necesito testers, cmo evalo las mtricas, como mido el avance del proyecto, y no las empresas no quieren

especular, no vale decir eso de el manifiesto gil dice que valoramos ms los elementos que no, que quieren respuestas, bibliografa 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 tcnicas bsicas de calidad e ingeniera del software que lo sustentan llevan ms de un cuarto de siglo descritas. Lee sobre gestin de proyectos bsica. Dos das de formacin no te hacen gil. Sin duda formarte en Scrum es una condicin necesaria. Hay que formar a todos los miembros 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 prctica y ms a nivel empresarial est lleno de preguntas, y es necesario un bagaje importante en gestin de proyecto y un plus de credibilidad extra para responderlas. Los mandos intermedios que me encuentro, en su gran mayora buenos profesionales, no tienen el conocimiento necesario sobre gestin de proyectos y carecen de la credibilidad extra que tiene alguien de fuera. Una formacin de Scrum dura dos das, ni ms ni menos. Pero no te capacita para hacer Scrum de igual manera que estudiar dinmica no te hace esquiador. Solo la prctica 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 ms golpes se haya dado tu Scrum Master, menos se va a dar tu equipo. Un curso de dos das no da margen para caerse lo suficiente. Las certificaciones estn haciendo dao. Mucho Scrum Master de postal. No voy a cometer nunca ms el error de simplemente formar a equipos de empresas. Si una empresa quiere solo formacin sobre Scrum y cree que eso es suficiente para llevar Scrum a una organizacin, que llame a otro. Algunos incluso te dan una etiqueta de Ans del Mono. Si quieres que lleve Scrum a tu empresa, no me pidas solo formacin, porque no es suficiente. Te voy a decir que no quiero ese proyecto, as de simple. No me va a volver a ocurrir dar formacin 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, inspeccin y adaptacin: los errores una vez y no ms. Todo el mundo quiere atajos. Todo el mundo quiere que formes a su equipo en medio da. Y tener Scrum en toda la empresa en un mes. Pero esto no funciona as. Hacer funcionar Scrum exige tiempo, dedicacin, una inversin. 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 porque alguien haba decidido que el logo antiguo no era dinmico. 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 inversin vers cmo se recupera con creces. Scrum es una inversin, no un coste, pero como toda inversin exige un desembolso inicial. El balance entre tiempo y dinero depende de cuanta experiencia ests dispuesto a pagar. No necesitas un coach para hacer Scrum, yo lo implemente sin un coach la primera vez, pero es ms probable que cometas errores o fracases. Despus 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 ha cortado una oreja en La Monumental no demuestra que ests haciendo Scrum. Ni siquiera demuestra que ests en el camino de Scrum, demuestra que ests 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. S que es motivador, s que es excitante, s que ests visualizando tu proceso y que ahora tienes mtricas que hace semanas ni soabas. Pero eso no es nada!, al menos hasta que tengas un proceso claro de crtica continua y continua mejora de tu proceso de desarrollo. Las herramientas importan. Evidentemente las herramientas no son lo ms importante. La gran mayora 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 tcnicas sin las que Scrum es ms duro de implementar. Valora que herramienta es adecuada y si tienes varios equipos procura que compartan herramienta cmo van a aprender unos de otros si usan herramientas diferentes?. Presta atencin a tu herramientas, aflalas, plelas, 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 organizacin asegrate de tener alguien que afile el cuchillo. La ingeniera del software importa. Nadie me va a convencer de que Scrum es suficiente. No lo es. Scrum no es nada sin buenas prcticas de ingeniera del software. Si formas a tu equipo en Scrum y no lo formas en TDD, calidad, automatizacin, gestin de la configuracin etc Cmo va a actuar tu equipo cuando encuentre impedimentos tcnicos? La experiencia me ha demostrado que los impedimentos tcnicos 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 tcnicos. No hay Product Owners. No existen. Son como el monstruo del Lago Ness. Es un rol clave que las empresas tienen ms 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 sistemticamente insuficiente. Acabas con un PO para seis equipos, situacin claramente insostenible. Y dos, los PM de Power Point y reunin 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 versin con Cirintione o destacaremos ms el nuevo condensador de fluzo de nuestro software, no. Se trata de definir en detalle caractersticas, evaluar el retorno de la inversin, priorizarlas y asegurar que se desarrollan con la calidad suficiente y no ms que el cliente demanda. Casi nada. No hay Product Owners, hay que crearlos. Tendrs que formarlos, entrenarlos, dejar que se equivoquen varias veces, lograr que aprendan y luego podrs 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 organizacin es saber qu carajo es un equipo en esa organizacin. 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 visin. 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 difcil,

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 ms grande, la que ms equipos tiene, nos llev ms de dos das de rompernos la cabeza. Los tester, si existen, tienen que cambiar radicalmente su rol. Ya no son la polica de la calidad que certifica los indolentes que somos los desarrolladores en este aspecto (que lo somos). No seor. Los testers pasan a ser los facilitadores de la calidad. Establecen los mecanismos necesarios en colaboracin con el equipo de desarrollo e incluso integrndose 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 aos 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 mxima que debemos recordar. Solo acercando a los testers a las fases ms tempranas del desarrollo logrars que el trabajo sea eficiente y los desperdicios mnimos. 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 tcticas 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 cmo 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 fantstico es que cada vez ms y ms organizaciones ms y ms grandes estn 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 organizacin en la que trabaja oigo cosas positivas. Tengo clientes que incluso estn 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 organizacin. Las empresas que implementan Scrum lo estn contando con orgullo al mundo, estn evangelizando. Con todos sus problemas, dificultades y fallos Scrum funciona!. El balance es claro: Scrum ha llegado y est aqu para quedarse. Published 15/9/2010 0:01 por Rodrigo Corral