Las mandarinas

    Andaba yo con el cerebro más o menos ocioso, mientras cenaba hace unas cuantas semanas, cuando al comerme una mandarina me fijé en algo curioso. Veréis, yo tengo la manía de coger los gajos de 2 en 2, y resulta que siempre me sobraba uno. Así que mi subconsciente (ya sabéis ese que me visita de vez en cuando, que llamarlo amigo invisible queda como si estuviera loco) me lanzó una pregunta: ¿Tendrán las mandarinas un número impar de gajos siempre? Así que me comí otro par y cual fue mi sorpresa, cuando de nuevo me sobró un gajo. Y encima eran siempre 9 gajos en total ¿Habría descubierto algo? ¿Me darían el Nobel al Frutero? ¿Si le cuento esto a alguien me mirará mal?

    En los días siguientes, continué con mi estudio, y ya fuera por casualidad o porque realmente era así, las mandarinas continuaban teniendo 9 gajos. Para ampliar mis pruebas, le pedí a mi madre que contara el número de gajos de las mandarinas que ella se tomara. De nuevo tuve esa sensación de que te miren como si hubieras chupado ranas tóxicas, pero aún así accedió. Si es que lo que no haga una madre...
    Poco a poco mi estudio tomó forma. La norma de los 9 gajos no se cumplía siempre, pero el que fuera un número impar si. Hasta me decidí a buscar algo en Internet, y apareció esta pagina: Mandarinas. Aquí decía que tenían entre 10 y 12 en el 68% de lo casos. Eso tiraba por tierra mi teoría del número impar, aunque mi experiencia era de un 100% con ese número de gajos. Decidí que sería un científico rival intentando quitarme mi Nobel.

    Cuando por fin mostré al mundo, es decir a los amigos que no me miran raro con mis freakadas, la realidad me dio un bofetón sorpresivo. Justo después de contárselo a una amiga que iba a desayunar mandarinas (Maribel siempre te odiaré por esto), abrió la mandarina y ¡salieron 12 gajos! Maldito destino cruel. Que desilusión, todos mis sueños, todo lo que iba a hacer con la pasta del Nobel, a la mierda. 

    En fin, voy a ver si cuento el número de frutos de las granadas...

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.

100 días en Agile (III)

El Tablero
     ¿Para qué leches quiero yo un tablero lleno de post-it? Esto fue lo primero que pensamos en el equipo, y como somos unos kamikaze empezamos sin tablero. Total ya teníamos JIRA, como excusa nos venía al pelo, cuando lo cierto es que nos daba algo de vergüenza saber que íbamos a estar de paseos con el tablero de un lado a otro.
     El primer día que el Product Owner (o sea yo) se empeñó en montar el tablero, y empezar a usarlo, nos dimos cuenta de la potencia del mismo. Y el primer comentario fue: "Madre de dios, nos hemos pasado planificando". Nuestra columna de "To Do" estaba cubierta de arriba a abajo de post-it con tareas técnicas, y ya llevábamos medio Sprint consumido.

    Es cierto que las herramientas como JIRA ayudan a tener controlado todo el proyecto, poder ir haciendo seguimiento de los cambios, generar un Burn Down del Sprint, sacar algún informe o gráfico, pero no tiene la presencia visual del Tablero. Quizás no sepas de que va el proyecto, pero cualquiera se pone delante de un Tablero donde esté planificado el Sprint, y tienes claro la cantidad de trabajo pendiente, en curso, y realizado de un solo vistazo.
     Por medio de post-it más pequeños con los nombres de cada persona del equipo Scrum puedes saber quién está con cada tarea y se puede controlar, de una forma muy simple, cuantas tareas puede tener asignada una persona a la vez. Para realizar las Dayli es fundamental, en seguida se ve y actualiza el trabajo realizado cada día, lo que queda pendiente, si hay impedimentos que paren o bloqueen una tarea, y muchas más cosas que no fuimos conscientes hasta que empezamos a usarlo.
     Lo malo es que ahora los bandarras de nuestro equipo no me actualizan el estado en JIRA...
     Aparte de la visión del Sprint, se puede utilizar para tener información adicional a mano. En nuestro caso para las dependencias con terceros que aún tenemos pendientes, y acciones que hayan salido de la Retro, principalmente. También tenemos el DoR y el DoD, pero la verdad que no le hacemos ni caso a esos 2 post-it (voy a arder en la hoguera para sacrílegos de Agile por esta frase).
     Esta es una foto de nuestro tablero tras finalizar un Sprint del primer Program Increment:

     En uno de los Item Backlog tuvimos un montón de trabajo extra y se nos acumularon un poco. La teoría del equipo (con 1 voto en contra) es que el experto en Google Analitics cobra por post-it y ese Sprint comió caviar iraní todos los días.

     Por la parte la otra cara del Tablero tenemos el Product Backlog no planificado, y el Sprint Backlog previsto para cada Sprint tras la última Planificación de PI:

     Incluso los colores de los post-it tienen un significado:

• Verde: Epics del Proyecto
• Azul: User Story o Product Item Backlog. Llevan además el número de la Epic a la que pertecen (abajo izquieda) y la estimación (abajo derecha).
• Fusia: US o PIB a refinar y dividir en otras más pequeñas.
• Naranja: Dependencias con terceros que afectan a US de la Epic
• Amarillas: Tareas técnicas de cada US o PIB.

     En resumen, el Tablero es una de las mejores herramientas para hacer Agile, que se  complementa perfectamente con aplicaciones de seguimiento y gestión.

100 días en Agile (II)

Intensa y Exigente
     Decía, en la entrada anterior, que Agile es intensa y exigente. Llevo cerca de 3 años en este puesto de trabajo (sin Agile), y he participado en proyectos que se consideraban críticos y con una gran presión. Y sin embargo, nunca he necesitado estar al 100% para desarrollar mi trabajo y sacarlos adelante.
     En estos 100 días en Agile como Product Owner (PO), no he parado. Cada Sprint, es justamente eso, un sprint de 2 semanas. Comienzan los miércoles y finalizan los martes dos semanas después, y tienen:

• Todos los días: Daily de 15m, a las 9:45h.
• Cada 2-3 días: revisamos el Scrum Master (SM) y yo: impedimentos, dependencias que aún tenemos que resolver, información nueva o actualizada que tengamos referente al proyecto, y cambios que hayan surgido por el camino.
• Cada 2 semanas los viernes: Comunidad de Product Owner, 1:30h.
• Día 1: Planificación del Sprint, unas 2h de media.
• Día 7: Refinamiento del Backlog, de 1:30h a 2:30h.
• Día 14: Sprint Review, de 30m a 1h
• Día 14: Retro del Sprint, de 1h a 1:30h.

     Además cada sesión hay que prepararla, si no es tiempo desaprovechado. 

     Cuando no hay una sesión planeada, como PO hay que ocupar el tiempo en averiguar que quieren y esperan los stakeholder (SH), entregar producto finalizado en cada Sprint y obtener feedback, recoger las nuevas necesidades de los SH, incluirlas en el Backlog priorizadas y explicadas, mantener actualizado JIRA (herramienta de seguimiento que utilizamos para proyectos Agile), perseguir al equipo Scrum para que lo actualice.

     Sesiones y charlas con los Coach: para aprender, para saber si estás aplicando bien Agile, para pedir apoyo, para el proceso de control de la ira, para que se enteren de verdad de que ocurre en esta "santa casa"...

     El equipo Scrum no va mucho mejor. Cierto es que estamos siendo optimistas en la planificación de los Sprints, y queremos hacer más de lo que realmente podemos, como consecuencia siempre van con la lengua fuera y justitos, justitos. Algún Sprint Review, vemos cosas que se han acabado una hora antes. 

    De todas formas, incluso planificando menos por Sprint, hay que hacer todo el trabajo que implica un desarrollo de software en 2 semanas: analizar, diseñar, codificar, probar, documentar, cambios de última hora, puesta en entornos de prueba y producción, cumplir con la metodología del banco, hablar con terceros, etc... Y tienen las mismas sesiones que yo durante el Sprint, cambiando la comunidad de PO, por la suya de desarrolladores o SMs.

    ¿Dan las 2 semanas para esto? Si, dar lo que se dice dar, dan. Pero lo cierto es, que no paramos. Yo sólo los viernes de 2 a 3, me permito el lujo de relajarme y monear.

    Agile exige mucho de ti, del equipo, de todo el que de una forma u otra esté involucrado. Si alguien baja la guardia o el ritmo, el Sprint se resiente, a corto-medio plazo lo hará también la cantidad de producto entregado, y por lo tanto no se cumplirán los compromisos adquiridos con los SH.

    Como recompensa a esa intensidad, exigencia y compromiso, entregamos producto viable y funcionando cada 2 semanas. A veces gusta más, a veces menos, a veces la DEMO falla, pero hace que siempre tengas sensación de avance.

    Personalmente me encanta y da esperanzas, y estoy viendo que lo mejor de las personas y los equipos sale cuando hay intensidad, cuando hay exigencia, y van unidos a la cooperación y la confianza. Y es Agile quién está provocando que se trabaje de esa forma.
    También entiendo que ahora mismo estamos en pleno aprendizaje, y según vayamos cogiendo experiencia, todo irá más rápido y fluido.
    Y bueno, si hay algo que me asusta un poco. Tengo la sensación de estar aplicando algo menos del 50% de Agile. Cuando lo hagamos al 100%, va a ser mucho más divertido, y, espero, un reto mayor...

100 días en Agile (I)

De Waterfall a Agile
     En la entidad financiera que en estos momentos dispone de mis servicios, estamos en un proceso de transformación de metodología de trabajo, para la construcción de software. Estamos cambiando de "Waterfall" (sigo sin entender el por qué de este nombre) a Agile con SAFe y Scrum. Ahí es ná...
     No quiero entrar en cual es mejor o peor, cada una es aplicable en un momento y proyecto determinados, sólo voy a decir que son diametralmente opuestas en cuanto a filosofía y cultura en la forma de trabajar.

    Nuestro (iba a poner mi, pero ya entenderéis por que no) equipo Scrum lleva alrededor de 100 días trabajando en Agile-Scrum, adaptándonos a y aprendiendo este nuevo estilo de trabajo. Algo más si contamos el primer mes y medio de arranque en el que "hicimos Agile". Y creo que, igual que a los gobiernos, es el momento de hacer un pequeño balance y sacar algunas conclusiones.

¿Qué me está pareciendo Agile?
     En 2 palabras: me entusiasma.

     Sin dejar de tener claro que no deja de ser una metodología más, con sus pros y contras, para alguien que se ha pasado casi 20 años haciendo proyectos de software con un método y formas de trabajar que sabes que no funcionan bien y que tiene deficiencias, y que ya sea por desidia, desconocimiento, impedimentos, o cualquier otro motivo, tienes que seguir aplicando una y otra vez, intentando no repetir los mismos errores, o al menos que sean diferentes en cada proyecto, supone una corriente de aire fresco muy muy esperada y necesitada.

     ¿Es la panacea? ¿Idílica? ¿Utópica? No, por supuesto. Si fuera perfecta, sería aburrida. Pero es intensa, exigente, orientada al cliente, y comprometedora. Cuando se aplica tal y como está definida, sin hacer híbridos que nos llevarán a la frustración, da grandes resultados.

100 días

     No es nada fácil hacer Agile. Cuanto más voy conociendo de esta metodología, más claro lo tengo. Sobre todo por el cambio cultural tan brutal que implica, y ahora empiezo a entender porque puede costar años su aplicación completa en una gran empresa.

     ¿Cuales son los pilares de Agile? Desde mi corta experiencia son 4:

• Autogestión
• Responsabilidad
• Cooperación
• Confianza

      La importancia de todas ellas es la misma. Alguno dirá "Pues vaya, como en cualquier trabajo en equipo". Si, pero no. Puedes trabajar con el sistema actual o cualquier otro sistema basado en Cadenas de Mando, pero si quieres hacer Agile en tu empresa, ve concienciándote que sin estas 4 palabras, vas a fracasar.

     En una de las daily uno de los desarrolladores hizo este comentario: "A ver no me volváis loco, que si tengo que hacer todo eso a la vez no termino ninguna", y me di cuenta de algo muy importante, nos hemos habituado a esperar a que alguien nos mande. Estamos acostumbrados a trabajar en una cultura de Cadena de Mando, donde el escalón superior va ordenando al siguiente qué debe hacer, e incluso quién y/o cómo debe hacerlo, dando un margen de libertad de decisión al siguiente escalón, más o menos amplio.

     Agile nos pide una Cadena de Responsabilidades, parece igual pero no es lo mismo. La relación entre los diferentes niveles es de Confianza en la Autogestión del trabajo que se es Responsable, y todos juntos Cooperando conseguirán el objetivo común: construir el Producto final con la mayor calidad. El éxito o el fracaso, es Responsabilidad de todos.

     ¿Qué bonito verdad? ¿Quién no está pensando en una comuna hippie? 

     Volviendo a nuestro desarrollador. Queremos que él mismo se gestione su trabajo. Hay una serie de tareas que realizar durante el Sprint, tú decides sobre cual vas a trabajar, tratando de seguir las prioridades establecidas, y cuando la acabes coges otra.  Es decir, le estábamos pidiendo que se responsabilizara de gestionar su tiempo, se autogestionara.
     Esto mismo se va llevando a cada nivel:

• El equipo Scrum es responsable de cumplir con los objetivos a los que se ha comprometido en la planificación del Sprint: se realizó siguiendo las prioridades marcadas por el PO, y negociando con él qué se podía incluir y finalizar en el Spint.
• El Scrum Master (SM) es responsable de facilitar las sesiones de Scrum (dayli, planificaciones, retrospectiva, ...), ayudar a quitar los impedimentos que encuentre el equipo Scrum, y guiar al equipo hacia la autogestión.
• El PO es responsable de conocer perfectamente el Producto a construir, de negociar con los Stakeholder las prioridades del Producto, de explicar al equipo Scrum el Producto a construir, que el Backlog de Producto esté priorizado y bien definido, de colaborar con el equipo Scrum para planificar, revisar y detallar cada Sprint de forma que lo construido aporte valor al Producto final.

     Cada uno es responsable de su parte y de cooperar con el resto del equipo de proyecto (PO, SM, equipo Scrum) para lograr el objetivo común de construir el Producto esperado por el Stakeholder.

     Y esto sólo funcionará si cada uno de los componentes confía en los demás.

     Nadie "ordena" que hay que hacer, se establecen necesidades y prioridades.

     Cada uno se responsabiliza de su trabajo y entre todos se controla que se está haciendo.

     No hay una figura que marque ni un cuánto ni un cuándo, se negocia y colabora para hacer lo máximo en cada Sprint.

     Se me ha hecho largo, seguiré otro día. Ahí os dejo la semilla del cambio cultural propuesto por Agile...