100 días en Agile (y V)

El cierre

     Quiero cerrar esta pequeña serie de mis primeros 100 días en Agile, con unas conclusiones y, como me han pedido, algún pequeño consejo.

Consejos

     La verdad que no sé muy bien que consejos dar, al final es una cuestión personal como te enfrentas a un cambio así, y de tus habilidades de comunicación y liderazgo. 
     A mí me ha funcionado muy bien la confianza. Como Product Owner confiar en el Scrum Master y en el equipo Scrum, ha sido la mejor decisión. Confiar en que saben hacer su trabajo, y por lo tanto me darán la mejor solución técnica que conocen o se les ocurra, para construir el producto que les estoy pidiendo. Y escucharles, hacerles ver que su opinión cuenta, aunque luego al final no se haga lo que proponen. Animarles a hablar y dar su opinión libremente, sin juicios, explicándoles desde un punto de vista del Negocio por qué se quiere tal cosa u otra.
     Personalmente creo desde ahí, desde la confianza mutua, la aplicación del resto de Agile es bastante más sencilla.

Conclusiones

     Nos queda mucho por recorrer, eso es lo que más claro tengo. Estamos dando los primeros pasos en un camino que ahora mismo no tenemos ni idea adonde nos va a llevar, ni que nos vamos a encontrar. Lo que está claro es que no va a ser fácil, ni nos lo van a poner fácil.
     Agile es un cambio, un enorme grande e inmenso cambio en todos los aspectos de nuestro trabajo. Y lo estamos haciendo mientras a nuestro alrededor el resto del mundo sigue igual, sin tener ni idea de lo que hacemos, sin entenderlo, e incluso sin ganas de saberlo. Como dijo uno de los Coach en los primeros días que hablé con él "Hemos decidido cambiar las 4 ruedas de un Fórmula 1, a 300 km/h y en medio de una curva". Ciertamente hasta ahora no alcanzaba a ver todas las implicaciones de esa frase.
    Y sin embargo, veo personas ilusionadas por todos lados, más o menos implicadas, más o menos escépticas o resistentes, con mayor o menor entusiasmo, pero con un ambiente diferente al que estaba acostumbrado hasta ahora cuando he participado en proyectos de software. Claro que hay alguno que se resiste, que intenta mantener su "cuota de poder" o hacer las cosas como las ha hecho siempre, pero poco a poco entre todos eso está cambiando. Hace poco una persona de nuestro equipo en la daily dijo "¡Eh, eh! Eso de que la tarea es de X, no. Aquí cada uno va cogiendo lo que le apetece, que las tareas son de todos." Aparte de la sorpresa, me sentí orgulloso de nosotros como equipo, por fin estamos rompiendo hábitos.
    No sé quizás esté siendo algo ingenuo (o cursi), es como si todos sintiéramos que somos pioneros de algo muy importante que está ocurriendo ahora, que está pasando ahí justo delante de nosotros, y que esta vez además somos parte activa de ello. Hay un ambiente de colaboración, de cooperación, de ganas de hacerlo bien, de dar lo mejor que tiene cada uno, como nunca había visto antes. Informática, Negocio, Internos, Externos de mil empresas diferentes, demostrando que se puede trabajar de otra manera. Por supuesto, no es perfecto, ni todo tan maravilloso; hay roces, hay discrepancias, hay mandones, hay pasotas, hay estrellas, hay malos momentos, etc... Y aún así, apenas hay caras largas o tristes o con desidia, lo que más hay son personas relajadas haciendo su trabajo, y ¡hasta disfrutando! Vale, y también agotados mentalmente.

     ¿Dónde acabaremos? ¿Bien? ¿Mal? ¿Hartos de Agile? Quien sabe, lo que está claro es que hoy por hoy estamos explorando y divirtiéndonos del camino, y decididos a llegar a los 1000 días en Agile.

     Nos vemos en los tablones...

¿Cómo alardea la madre de un Informático?

    Hoy hablando con mi mejor amiga, nos hemos puesto a delirar sobre como puede la madre de un informático alardear del trabajo de su hijo. Pensadlo un momento...

    Mola y es gracioso cuando a ves a un grupo de madres hablando del trabajo de sus hijos:

Madre1: Pues mi hijo es banquero y ayuda mucho a la gente dándoles préstamos. - ¡Sonidos de admiración!  !oooooooh!

Madre2: Pues el mío es médico y se va África a ayudar a los negritos, y sólo por la mitad de su sueldo. - ¡Sonidos de admiración y aplausos!  !ooooooh! ¡clap! ¡clap!

Madre3: Pues el mío es electricista y ha metido todo el cable de las torres Etihad el sólo. - ¡Sonidos de admiración, aplausos y la ola!  !oooooooh! ¡oooooh! ¡oooooh! 

Madre4: Pues el mío es ingeniero aeronáutico y con un lego que teníamos en casa ha montado un satélite ecológico y súper barato, para que veamos la tele por cable gratis. - ¡Sonidos de admiración, aplausos, ola y desmayos de la emoción!  !oooooooh!

    Vale, igual exagero un poco, pero no anda muy lejos de la realidad. Coño (perdón por el palabro en horario infantil) si hasta de un okupa se puede alardear. 
    Imaginar ahora que de repente en esa conversación suelta una quinta madre (exagerando claro):

Madre5: Pues el mío es informático y hace programación extrema orientada a objetos en C++ y con punteros, e incrustando código ensamblador para las operaciones en coma flotante, que da mejor rendimiento. Se ha inventado un algoritmo de búsqueda Quicksort 25.0 que es capaz de localizar cualquier web en 314 milisegundos.

    El ruido de fondo sería: Cri, cri, cri, cri, ... y el resto la miraría como si fuera la Loca los Gatos. Si quieres ser la apestada social de los grupos de madres, esta es una técnica infalible. Pasarías a ser "¡Ay pobre! Lo que sufre, su hijo es informático. Pero no la mires que nos habla..."

    Ser madre de un informático no es fácil, no puedes alardear, no puedes soltar lo bueno que es tu hijo, por una causa simple, básica y elemental (querido Watson): nadie entiende que hacemos. Y con esa facilidad de palabra, elocuencia y sociabilidad que nos caracteriza, tampoco es que lo expliquemos muy bien. Vale, y que usemos un lenguaje que tiene más siglas que el wassap de un veinteañero, tampoco ayuda. Y no, explicarlo en klingon, élfico, o alto valyrio, tampoco es buena idea...
    ¿Quién no ha terminado oyendo? "Vale tú te pasas el día en interné con el ordenador, ¿a qué si pillin?. Si es que os tengo calaos a los informáticos"
    ¿Quién no ha terminado diciendo? "Trabajo con ordenadores."

    Así que levantemos una lanza en favor de las madres de informáticos que sufren la humillación de no poder alardear de ellos, y aguantan estoicamente las bárbaras exageraciones de las demás, sin poder dejar de sentir vergüenza porque su hijo "Se pasa el día en interné y sentado además"...

100 días en Agile (IV)

La Adaptación
     Empezar a trabajar en Agile, como con todo nuevo modelo, requiere un tiempo de adaptación a los cambios que provoca. Aparte de los culturales, de la forma de trabajo, y del ritmo que exige, ya comentados, tenemos muchos cambios en los roles de Agile respecto a Waterfall, y no sólo en el nombre.

     Empecemos por el que me toca más de cerca el Product Owner. El principal cambio para el P.O. es que ahora está mucho más cerca de los equipos de desarrollo. Tenemos 2 tipos de P.O.:

• El P.O. antes conocido como el Informático
• El P.O. Usuario

     El primero en algún momento de su carrera profesional ha formado parte de equipos de desarrollo de software, en todos o en alguno de los roles. Y le encanta meterse al barro, diciendo al equipo Scrum que solución técnica debe construir. Por que claro, como buen informático que se precie de serlo tiene un máxima: el resto no tiene ni idea y mi solución siempre es la buena. Suele terminar "dialogando amistosamente" con el equipo Scrum, hasta que por fin se da cuenta que su responsabilidad es otra, definir el producto, y no cómo construir el producto.
    Otra adaptación que debe sufrir este P.O. exinformático, es que en el Backlog haya User Story que de verdad aporten valor al producto final, y no funcionalidades o requerimientos que se adapten a la solución técnica.

    El segundo es un P.O. que desde el mundo de los informáticos se ve como una persona que sabe encender el ordenador, mover el ratón, y manejar el Office (sobre todo el powerpoint), es decir, un USUARIO. En realidad, es una persona que ha estado siempre en departamentos de Negocio, y que sabe de eso, del negocio y las necesidades de la empresa. Este pobre se encontrará con el problema contrario. 
    De repente una serie de personas (freaks en su cabeza) empiezan a pronunciar palabras hasta ahora desconocidas para él: js, java script, properties, JCL, junction, servidor apache, json, COBOL, ... Su mayor reto será conseguir que los informáticos (que huelen el asombro) no le toreen, le lleven a su terreno, y termine como el anterior P.O. escribiendo en el Backlog funcionalidades y requerimientos en lugar de user story.  
     Además deberá conseguir explicar a los informáticos el producto que quiere entregar a su stakeholder, sin utilizar la jerga propia de los desarrolladores. Alguno ha decidido que le costaba menos aprender Klingon...

     Ambos tendrán también problemas comunes. Mantener el Backlog como ellos quieren sin que nadie "meta mano", evitar interferencias de terceros a todos los niveles, controlar las expectativas, el tener que estar negociando constantemente con todos: equipo scrum, stakeholder, terceros, Scrum Master, la señora de la limpieza para que no tire los post-it (este lo comparte con el SM)...
    Y sobre todo adaptarse al Poder. "Un gran poder conlleva una gran responsabilidad" (Tio Ben, Spiderman) El P.O. tarda en darse cuenta de la cantidad de "poder" que acumula su rol. La responsabilidad compartida, el cooperar para un objetivo común, y todo lo que ya he comentado en entradas anteriores, están muy bien y realmente son necesarias. 
     La realidad es que sobre los hombros de P.O. está la mayor responsabilidad del éxito o fracaso de un proyecto en Agile, debido a la gran cantidad de decisiones que debe tomar el P.O. y que afectan a todos los aspectos del producto. Desde la negociación con los stakeholder para ver la prioridad de sus necesidades, hasta la exigencia o laxitud en el contenido de los sprint, pasando por el refinamiento de las epics y user story. Todo, excepto la construcción, gira en torno a las decisiones que tome el P.O. Y eso algo para lo que no todo el mundo está preparado, o acostumbrado.

     Para los Desarrolladores, aparte de la autogestión, el mayor cambio son los tiempos. Ahora tienen que hacer todo lo que antes podían "ir haciendo" en un Sprint de 2 semanas. Bueno, y que el Usuario ese que viene todos los días se entere de algo.

     Y por último el Scrum Master. Reconozco que aún no me queda muy claro el peso del SM en los proyectos Agile. Y ese es precisamente su mayor reto, que ellos tampoco lo tienen claro.
     La mayoría viene de ser Jefe de Proyecto en Waterfall, que más o menos todos sabemos de que va. Ahora se le pide que sea un Facilitador:

Un facilitador es la persona que ayuda a un grupo a entender los objetivos comunes y contribuye a crear un plan para alcanzarlos sin tomar partido, utilizando herramientas que permitan al grupo alcanzar un consenso en los desacuerdos preexistentes o que surjan en el transcurso del mismo.

     "Sin tomar partido"... "Alcanzar un consenso"... Claro, y un unicornio rosa... Dile a un Jefe de Proyecto que no puede organizar el trabajo del equipo, pedir tiempos, que en realidad no tiene capacidad de decisión, etc, etc, etc. Sinceramente es el rol que tiene una adaptación más dura, ya que pierde protagonismo. A veces parece que si el SM desaparece, nadie se va a dar cuenta hasta que pasen los días y huela a muerto.