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

Cálculo del SPI en un Proyecto Ágil

Una de las preguntas más frecuentes que se hacen quienes comienzan a trabajar en el mundo de la agilidad es, ¿cómo calculo el avance de la construcción de mi producto?, en este post quiero compartir como es posible hacerlo.

Vamos a comenzar con poner los equivalentes del método del valor ganado (1)(2) en un proyecto agil:

• Valor :
• funcionalidad puesta a disposición del cliente que le reemplaza una existente o le mejora su negocio,
• Generalmente medida en puntos en proyectos ágiles, 
• Las funcionalidades inicialmente construidas tienen mayor valor de negocio que las construidas al final debido a la priorización del backlog  (3). El valor de negocio es subjetivo y es dado por el Cliente y/o Product Owner en Scrum (3)
• Punto: 
• Percepción (debido a la incertidumbre) del esfuerzo requerido para construir una funcionalidad
• Por lo general se usa la serie de fibonacci alterada para "tallar" (poner talla), estimar una funcionalidad (historia de usuario, caso de uso) a ser construida, La serie usada es 1,2,3,5,8,10,20
• BAC 
• Presupuesto a la terminación del proyecto. Budget at Completion
• En ágil emplearemos como BAC la cantidad de puntos estimados del release
• EV
• Valor ganado del proyecto
• En ágil emplearemos la cantidad de puntos en DONE (5) al momento de hacer la medición
• PV
• Valor planeado
• En ágil emplearemos la cantidad de puntos  planeados en DONE al momento de hacer la medición.
• El insumo de los puntos planeados en Done es proporcionado por la gráfica del Burn Up Release
• Release Burn Up
• Gráfica empleada en proyectos ágiles en la cual en el eje "x" se encuentran los Sprints, en el eje "y" los puntos acumulados. De igual forma se gráfica la cantidad de puntos estimados que tendrá el release (como techo del mismo) y en el tiempo se presentan los puntos acumulados sprint tras sprint, en aras de buscar una tendencia y un estimado para lograr el posible despliegue de una versión liberable.
• SPI
• Indice de desempeño del cronograma
• Indica la proporción en la que se cumple el planeado a la fecha 
• si es mayor que 1 se encuentra el proyecto adelantado vs el planeado
• si es menor que 1 se encuentra el proyecto atrasado vs el planeado

Dado estos insumos los cálculos de los índices son:

• Avance = EV / BAC = Puntos en Done al momento de la medición/ Puntos totales del  Release

• SPI = EV / PV = Puntos en Done al momento de la medición / Puntos proyectados

Condiciones, Restricciones y Aclaraciones
Es importante aclarar que en un proyecto ágil pueden darse las siguientes condiciones:

• Si se alcanza valor de negocio más temprano se puede parar la construcción de este release y comenzar el siguiente
• Si existe una fecha límite se le puede ofrecer al cliente:
• dado que el equipo tiene una velocidad (tasa a la cual produce software sprint tras sprint) que funcionalidades desea sacar del product backlog para cumplir la fecha impuesta
• cuales funcionalidades cumplen el objetivo de negocio que quiere resolver con la solución
• Dada la incertidumbre inherente al desarrollo de software (clic aquí), muchas veces se puede contestar:
• esa capacidad de negocio la logramos aproximadamente entre el sprint 7 y 10, en función de la priorización del backlog

Espero haber aportado/ayudado a la solución de esta inquietud frecuente.

Saludos Ágiles

Jorge Abad

Post relacionados:

1. EVM, CPI, SPI en AGILE / SCRUM - clic aquí -.
2. Diferencia entre Valor de Negocio (Ágil) y Valor según el PMI - clic aquí -.
3. Mi versión de : SCRUM EN POCAS PALABRAS / SCRUM RESUMIDO - clic aquí -.
4. Planning poker  - clic aqui -.
5. Una versión inicial de Definition of Done (Definición de Hecho / Terminado / Realizado) - clic aquí -.

El tinto * / café (o té) del Scrum Master

Lograr un entendimiento profundo del rol de Scrum Master es algo que me ha costado tiempo, fallas, y experiencia.

Me gusta mucho el modelo de Angel Medinilla (@angel_m)
1. Scrum Dude
2. Scrum Mom
3. Scrum Master
4. Scrum Master Sensei
Ver más aquí - clic aquí - 


Esta es la hora que no se si estoy en el nivel 3 o si llegaré al cuarto nivel, pero mas allá de eso, he notado dentro de las grandes herramientas del Scrum Master en su papel de Coach del Product Owner y Coach del Scrum master:  Es el tinto* (o café - como le dicen en otras zonas- )

Como lo tuitie (o lancé un twit – no sé como rayos se escribe - ) hace unos días

No tiene sentido que el #ScrumMaster no sea cercano al equipo, debe estar en la misma área de trabajo.

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

Para qué:

• Para ver y sentir las interacciones de su equipo
• Para notar como se teje el equipo
• Escuchar como se va construyendo o destruyendo la auto-organización en función de los eventos y conductas de los miembros. entorno, o de la organización
• Para dar feedback y feedforward, respetuoso y oportuno
• Gestionar y palpar los impedimentos
• Para evitar interrupciones al equipo

Y en ese sentir su equipo, el/la Scrum Master tiene una herramienta de valor incalculable, las “CONVERSACIONES” y esas conversaciones acompañadas de un tinto o un té son geniales y de gran aporte para el equipo..

A veces invito a cualquiera del equipo : “ven, vamos a tomarnos un tinto*”, y con la excusa del tinto, conversamos de:

• La familia
• El proyecto
• De mi
• Conciliamos puntos de vista
• Hablamos de puntos de vista diferentes
• Nos damos mutuo feedback acerca de cualquier circunstancia, o solo feedback unidireccional
• De todo

Y es allí donde – desde mi experiencia– siento que puedo influenciar al equipo hacia la mejora continua, de la misma manera que sucede en la retrospectiva (a veces talvez más), pues muchas veces se logran entendimiento profundo de ciertos eventos y logramos decifrarlos/desamarrarlos a la aroma de dos buenos tintos..

Aclaro, cualquiera de mi equipo se siente en la libertad de invitarme a tinto y conversar.


 –  Vení, nos tomamos un tinto*....


Saludos ágiles

Jorge Abad

---

Notas:

• Esta "revolucionaria técnica" : )    puede ser usada con té, y por gerentes de proyecto, líderes, team members y cualquiera que esté interesado en mejorar el resultado de su equipo de trabajo.
• * Tinto: Así se le dice a un pocillo de café negro en Colombia.