Product Owner - Interno o del Proveedor

Hola a todos, les comparto esta gráfica que desarrollé sobre  las ventajas y riesgos de tener Product Owner Interno o Externo, espero les sirva [1].

Saludos ágiles
Jorge Abad


Referencias
[1] Experiencia, y charlas de Ángel Medinilla @angel_m

Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado

"Un gran poder conlleva una gran responsabilidad", le decía el tío Ben a Spiderman, y la verdad, es de los primeros mensajes que se debe dar a un equipo cuando se les habla de autooganización

Muchos team members (miembros de equipo en Scrum) malinterpretan el término y lo consideran una declaración de anarquía que implica que ya no deben cumplir su contrato laboral, con expresiones como:

• "Como soy autogestionado no tengo que avisar a nadie a que horas entro o salgo de trabajar", considerando que tienen una jornada laboral contratada de 8 ó 9 horas (según el contrato laboral (¡¡¡PLOP!!! - caso real -)
• "Trabajaré haciendo lo que mejor pueda, aunque pueda dar más no lo voy a hacer"
• "Como soy autogestionado, puedo dedicar todo el tiempo que desee a facebook o whatsapp"
• "Salgo a hacer una vuelta y no tengo por que avisarle a nadie"
• "Aunque todos llegan a las 8 am para el daily, la verdad  a mi eso no me aporta llegaré todos los días a las 9 am y no estaré en el daily por qué eso no me aporta" (¡¡¡RE_PLOP!!! - caso real -)
• "Ya hice mi parte y la pasé al equipo de Quality Assurance"
• Cuando salgo antes del horario de oficina sin importarme el compromiso del sprint por que soy "autogestionado"
• Cuando inflo las estimaciones en el planning para trabajar con "muy buena holgura" 
• etc.[1]

Mike Cohn (@mikewcohn) argumenta (clic aquí)

• Autogestión no significa (clic aquí)
• El equipo decide que objetivo alcanzar
• o incluso quien es parte del equipo
• Autogestión es:
• acerca como el equipo determina como responder al ambiente (a los objetivos planteados)
• y los líderes y gerentes influencian el ambiente

La autogestión es mas orientada a ser capaces de gestionar el trabajo en progreso y monitorear el progreso, y en un nivel superior cuando el equipo es autoorganizado (cuando el equipo es más maduro) ser capaces de diseñar el equipo y su contexto, como lo muestra la siguiente imagen:

tomada de[2]: 

Entre tantas cosas he descubierto que un equipo es autogestionado cuando

• Son dueños del sprint backlog durante el sprint.
• Deciden cual es la mejor estrategia para consumir el sprint backlog durante el sprint.
• Honran los compromisos y la palabra dada en el planning  y utilizan el timebox del sprint lo más productivo posible, y en caso de que se termine el sprint backlog pedir al PO más ítemes
• Si me comprometí con mi equipo a hacer una cantidad de puntos, a no dejar tirado a mi equipo con el compromiso
• Dan visibilidad de los impedimentos
• Ponen todo el empeño para que en la jornada laboral se cumpla el compromiso y en caso de observar que no se va a cumplir dar visibilidad de las razones que ocasionaron que no se cumpliera
• Gestionan el progreso durante el sprint tanto en el kanban, burdown chart o cualquier herramienta de gestión y/o gestión visual
• Sus team members cumplen con el contrato laboral (la verdad es lo mínimo, pero hay personas que es necesario explicárselo)

Y es allí donde el papel del Scrum Master toma importancia pues guía al equipo y a los respectivos team members a entender el concepto, a hacerles entender la responsabilidad que tienen y el poder que tienen en sus manos. De manera  que están cambiando el micro-seguimiento o RC [3], por la libertad de dar visibilidad del progreso y de potencializar la interacción con sus compañeros generando verdadero trabajo de equipo.

Yo creo en el agilismo, lo he visto funcionar, pero siempre que comienzo con un equipo scrum es de los primeros mensajes que doy, pues libertad no significa libertinaje, y agilismo no significa que no te enfoques responsable y maduramente en cumplir los compromisos que adquieres al principio de cada ciclo o sprint.

Termino como empecé, parafraseando un poco

"Team Member ser autogestionado es un gran poder, y un gran poder conlleva una gran responsabilidad"

Saludos ágiles

Jorge Abad

Referencias 

1. Hay algunos pensamientos extractados en el hashtag de twitter #LesaAgilidad (sería genial que aportaras algunos que consideres)
2. http://www.applitude.se/2011/05/self-organizing-teams-the-most-debated-agile-principle/
3. RC: "Respiración en el Cuello" del gerente de proyecto, que por ejemplo pregunta cada hora, ¿cómo vas?

Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización

Desde hace un tiempo vengo profundizando en cómo lograr la autoorganización en los equipos,  este tema me apasiona entenderlo e intriga de forma insistente a quienes pasan de la gestión tradicional (comando - control) a la agilidad, como lograr la autoorganización (la confianza, la inspección y adaptación). He escrito varios post con este tema de trasfondo:

• Ejecutando proyectos con equipos autogestionados - clic aquí
• ¿Y por qué dudamos de la auto-organización de los equipos? - clic aquí
• Como Jugando Fútbol - Un Símil con Scrum - clic aquí
• Cualquiera puede ser ágil / Cualquier equipo puede ser ágil - clic aquí
• Más en el label Autoorganización- clic aquí

Y lo que quiero compartir hoy es, como un Scrum Master lleva al equipo a la autoorganización (algo comencé en este post - Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos -) pues es allí donde toma valor la presencia de un Scrum Master como parte del equipo.

Coincido plenamente en el modelo propuesto Ángel Medinilla  @angel_m, para los pasos o edades que vive un Scrum Master, en el cual se pasa de "The Scrum Guy" hasta "Scrum Sensei"

Tomado de agile coaching / Coaching de equipos Ágiles

Pero, aunque se alcance el estado de "The True Scrum Master" o "Scrum Sensei", es necesario considerar el liderazgo situacional (propuesto por Blanchard) cada que se inicia un nuevo team de Scrum.

Ese liderazgo situacional (o estilo de acompañar a un equipo Scrum por parte del Scrum Master) debe ser según el estado de madurez del equipo

*Etapas del equipo vs Tipo de Scrum Master Requerido (elaboración propia)

Etapa del equipo (Tuckman)	Tipo de Scrum Master Requerido
	Scrum Dude / Scrum Guy
1. Formación ( Forming)	Scrum Mom
2. Conflicto (Storming)	True Scrum Master
3. Normalización (Norming),	True Scrum Master
4. Desempeño (Performing),	Scrum Sensei / True Scrum Master
5. Separación (Adjourning),	Scrum Sensei / True Scrum Master

Y ese estilo de acompañamiento que lo lleva a la autoorganización lo veo muy similar a Enseñar a Montar en Bicicleta (wow me tomo mucha argumentación llegar hasta acá, pero sentí que debía hacerlo .. continuemos) pues:

• al principio tu debes guiar, dirigir, inspirar, dar instrucciones precisas para que el equipo vaya aprendiendo scrum (y el niño comience a montar en bicicleta) Acá es típico que:
• se tiene que insistir en lo importante de los dailys y como hacerlos bien -clic aqui-
• no falta quien diga: "soy autoorganizado entro a las 10 y me voy a las 2 ¡¡PLOP!! - prometo un post de esto - " y es necesario hablarle de compromiso, disciplina, confianza, madurez, de que la autoorganización se entiende como la capacidad del equipo de resolver independientemente su compromiso de sprint backlog sin faltar a sus compromisos laborales.
• Timebox de las reuniones, etc.
• luego comienzas a soltar poco a poco y es hasta probable que el equipo se caiga, aprenda y tropiece pero sigues soportándolo corriendo detrás de él agarrando el sillín/silla algunas veces.
• Fallen experimentos
• Propuestas de retrospectivas funcionen y otras no
• y luego lo "dejas solo" sin dejar de acompañarlo, dándole instrucciones lejanas de cuidado, o advertencia, u otras muchas animándolo.
• Tal vez, visitas el kanban y preguntas como van con la herramienta, si les ha servido, los felicitas o les explicas el por que de ciertas prácticas
• hasta que ya no necesita de ti para ser autoorganizado y el equipo completamente independiente

Aclaro, se sigue necesitando del Scrum Master para remover impedimentos y realizar las otras muchas tareas, pero ya no necesitan del Scrum Master para autoorganizarse, pero sí talvez para algún cuestionamiento que los lleve a ser cada vez mejores.

Nota: No creo en coach de Scrum o Scrum Masters certificados o no, que nunca hayan practicado Scrum, no saben transmitir la esencia del mismo y el espíritu que hay detrás del Framework. En el lenguaje de la bicicleta sería: aunque no dudo que hayan casos de quienes enseñen a montar en bicicleta sin haberla montado, la experiencia de quien enseña es importante para que quien esta aprendiendo aprenda más rapido, aprenda correctamente y aprenda mejor.

Hasta acá este compartir, hasta la próxima

Saludos ágiles

Jorge Abad.

Tweets sobre Scrum: Ideas que me rondaron hoy

Si como #ScrumMaster no estas adentro del TEAM, no sabrás que necesitan para lograr mejor fluencia #scrum #Agile pic.twitter.com/AwTJxfQCER

— Jorge Hernán Abad L. (@jorge_abad) noviembre 11, 2015

---

@jorge_abad exigir resultados no los garantiza. #Ágil #Scrum

— Lucho Salazar (@luchosalazarc) noviembre 11, 2015

---

mayor presión, menor motivación, y mayores reprocesos #Fail // #PMOT #PMI #Agile

— Jorge Hernán Abad L. (@jorge_abad) noviembre 11, 2015

---

Insisto: Un imposible en el tiempo, sigue siendo un imposible así yo haya hecho un compromiso sobre el #PMOT #Agile #Scrum

— Jorge Hernán Abad L. (@jorge_abad) noviembre 11, 2015

---

Si como #ScrumMaster no he eliminado la fricción no puedo esperar aumentos milagrosos de la velocidad #Fail #Agile #Scrum

— Jorge Hernán Abad L. (@jorge_abad) noviembre 11, 2015

Leído y Recomendado: How to Grow Effective Teams - Desde Thoughtworks

el verdadero rendimiento tiene poco que ver con la presión, y todo que ver con la motivación https://t.co/Q3rfNvB4KH // #Agile #Scrum

— Jorge Hernán Abad L. (@jorge_abad) octubre 2, 2015