martes, diciembre 15, 2015

Buenas y Malas Prácticas en el Review / Demo de Scrum

o El Review no es una reunión de Testing




Hola a todos

En la medida que se va implantando Scrum, sprint tras sprint, el Scrum Master debe enfocarse cada vez más en que cada una de las reuniones de Scrum y la ejecución del mismo conserven el espíritu del agilismo: dar valor al negocio, con la menor cantidad de software posible a pequeños incrementos.

En este ejercicio se debe velar por que no se caigan en malas prácticas durante las reuniones de Scrum, en este post me enfocaré en la reunión del Review / Revisión / Demostración / Demo (la verdad me gusta más la palabra Demo) la cual esta definida según la guía como:

"Una reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración."(1)



A continuación comparto unos tips y malas prácticas que he observado en los Demos:
  • Malas prácticas
    • Creer que la reunión de Demo es una reunión de User Acceptance Testing (UAT), revisando paso por paso los casos de prueba: 
      • Esto hace que la reunión se vuelva extensa, que no se cumpla el timebox (2), además ¿Cuándo se logra probar en una reunión de 2 horas el software que se produjo en 2 semanas?, implicando que se desconfía en el "Done" / "Terminado" que asegura el equipo y/o los testers encargados de realizar las pruebas.(3)
    • Realizar la Demo con capturas de pantalla (pantallazos) de los casos de prueba que lograron el Done durante el Sprint
      • La ventaja del Demo es esa, poder hacer una demo de lo que se hizo, y el hecho de presentar los pantallazos, no cumple con uno de los principios ágiles "software funcionando es la principal media de progreso". Es necesario poder navegar y "jugar" con el software durante la demo.
    • No invitar a Interesados / Stakeholders claves a la reunión
      • El Product Owner debe trabajar para que haya inspección y adaptación sobre el producto, de esta forma dentro de la reunión del review se brinda a stakeholders claves la posiblidad de realizar feedback sobre el producto y poder dar lineamientos sobre su progreso, el demo es el espacio para realizarlo, y no hacerlo en este tiempo es perder tiempo valioso.
  • Buenas prácticas
    • Preparar la Demo
      • El equipo debe preparar la demo y guardar un tiempo al final del sprint para preparar data a ser usada, ambientes, etc. en caso contrario el review puede llegar a ser fallido, o alguno de los ítems del incremento no funcionar correctamente y no darse por aprobado.
    • Cuidar el Timebox
      • El Scrum Master debe velar para que el timebox del la reunión se cumpla, proporcionando feedback oportuno a cualquiera de los asistentes cuando alguna solicitud vaya en contra del propósito de la reunión o el tiempo del a misma.
    • Realizar revisiones JIT (Just in Time / Justo a Tiempo)
      • Esta práctica consiste en que durante el Sprint el equipo cuando alcanza el Done de algún item del Sprint Backlog, lo presenta al Product Owner para recibir feedback, aceptación y/o rechazo del mismo, de forma que no se espera hasta el review, y de esta forma recibir feedback oportuno. 
      • Esta práctica tiene la ventaja de hacer un review (o demo) más exitoso y más liviano en el tiempo.

Hasta acá esta pequeña lista, espero sea de ayuda y provecho para los demos en sus equipos



Saludos ágiles

Jorge Abad



Referencias y Aclaraciones
(1) Guia de Scrum - scrumguides.org
(2) Timebox de las reuniones de Scrum - clic aquí -.
(3) Existen equipos que no tienen alguien destinado específicamente al testing y existen equipos en que sí, en general lo que hay que garantizar es que el equipo sea multifucional, no polivalente (cada persona sabe realizar bien todos los roles).

Ejemplos de Artefactos Empleados en Metodologías Ágiles / Scrum UNAB 2015-02

Hola a todos

Siempre he reconocido en los ejemplos el poder de ayudarnos a comprender mejor los conceptos.

Nuevamente les comparto el resultado del trabajo de la cátedra TÓPICOS TÉCNICOS  II, que impartí en la ESPECIALIZACIÓN EN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DEL SOFTWARE, de la Universidad Autónoma de Bucaramanga (Colombia).

En esta materia vimos tanto el Agile Inception, el desarrollo y ejecución de un proyecto empleando Scrum, como la atención de un area de gestión de incidentes empleando Kanban (debo un post sobre este tema).

Los entregables desarrollados son:

  • Agile Inception
    • Mapa de Impacto (Impact Map)
    • Product Vision Board
      • Visión
      • Grupos de usuarios
      • Necesidades
      • Funcionalidades
      • Beneficios
    • Product Backlog  Board
      • Técnica Personas
      • Restricciones
        • Lo que no nos deja dormir (Riesgos)
        • Sería genial que pasara (Oportunidades)
        • Prioridades (alcance, tiempo, costo, calidad, usabilidad, adaptabilidad, seguridad, etc)
        • Incluido en el alcance
        • Fuera del alcance
      • Modelos /Diagramas
        • Despliegue
        • Procesos
        • Diagrama de contexto
        • Mockups
    • User Story Map / Construcción del Release Plan 
    • Calculo del tiempo y costo de la construcción del producto,  empleando una hoja de cálculo de mi autoría (clic aquí para acceder a la hoja de cálculo y su explicación)
    • Construcción del Product Backlog basado en requerimientos con historias de usuario
  • Simulación de Scrum
    • Simulación de tres sprints de scrum, durante una sesión de 4 horas, generando los siguientes entregables:
      • Historias de usuario
      • Bocetos asociados a las historias de usuario
      • Gráfica de Burndown de cada Sprint
      • Gráfica de Velocidad
      • Gráfica de Release Burn Up
      • Mejoras identificas cada sprint


En estos links encontrarán los cuatro proyectos con los entregables citados:

  • SerVIP -Sistema para la notificación oportuna de daño en los servicios públicos  link
  • Enjoytravel -Sistema planear un viaje empleando un vehículo propio- link

Espero los disfruten y les ayude en sus proyectos.

Saludos ágiles

Jorge Abad

sábado, diciembre 05, 2015

Ejemplo User Story Map - Solicitud de Crédito

Hola a todos

Les comparto este Mapa de Historias de Usuario - User Story Map, para un proceso de solicitud de crédito.

User Story Map - Sin Priorizar



User Story Map - Con Releases



Espero les sea útil.


Saludos Ágiles

Jorge Abad.





viernes, diciembre 04, 2015

Ejemplo Mapas de Impacto - Impact Map

Hola a todos

Les comparto dos mapas de impacto que elaboré en clase, bien recibido el feedback.

Mapa de Impacto - Reducción de tiempo de solicitud de Crédito

Mapa de Impacto - Reducción de accidentalidad


Saludos ágiles
Jorge Abad

lunes, noviembre 23, 2015

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

domingo, noviembre 22, 2015

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?



lunes, noviembre 16, 2015

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"


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.

miércoles, noviembre 11, 2015

Tweets sobre Scrum: Ideas que me rondaron hoy





martes, octubre 20, 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í -.





domingo, octubre 11, 2015

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


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.

domingo, septiembre 20, 2015

Ejemplos de Artefactos Empleados en Metodologías Ágiles / Scrum (Semestre 02 - 2015)

Hola a todos

Con mis alumnos de "Gestión de Proyectos Informáticos" del semestre 8 del pregrado Ingeniería de Sistemas de la Universidad Eafit - www.eafit.edu.co, realizamos durante el primer módulo la simulación de la gestión ágil de un proyecto de software, generando los siguientes entregables:


  • Agile Inception
    • Product Vision Board
      • Visión
      • Grupos de usuarios
      • Necesidades
      • Funcionalidades
      • Beneficios
    • Product Backlog  Board
      • Técnica Personas
      • Restricciones
        • Lo que no nos deja dormir (Riesgos)
        • Sería genial que pasara (Oportunidades)
        • Prioridades (alcance, tiempo, costo, calidad, usabilidad, adaptabilidad, seguridad, etc)
        • Incluido en el alcance
        • Fuera del alcance
      • Modelos /Diagramas
        • Despliegue
        • Procesos
        • Mockups
    • User Story Map / Construcción del Release Plan 
    • Calculo del tiempo y costo de la construcción del producto,  empleando una hoja de cálculo de mi autoría (clic aquí para acceder a la hoja de cálculo y su explicación)
    • Construcción del Product Backlog basado en requerimientos con historias de usuario
  • Simulación de Scrum
    • Simulación de tres sprints de scrum, durante una sesión de 3 horas, generando los siguientes entregables:
      • Historias de usuario
      • Bocetos asociados a las historias de usuario
      • Gráfica de Burndown de cada Sprint
      • Gráfica de Velocidad
      • Gráfica de Release Burn Up
      • Mejoras identificas cada sprint


En estos links encontrarán los cuatro proyectos con los entregables citados:

  • Optitraffic Gestion -Sistema para apoyo de la movilidad de la ciudad-  link
  • MetroTime -Sistema para conocer tiempos del metro y sistemas integrados- link
  • Uber Bus App site -Sistema de información de movilidad pública- link
  • Sismat -Sistema de Gestión de Matriculas de Colegios- link

Espero los disfruten y les ayude en sus proyectos.

Saludos ágiles

Jorge Abad





miércoles, septiembre 09, 2015

Empezar una Retrospectiva y la Directiva Principal de las Retrospectivas Ágiles





Empezar una retrospectiva ES UN RITUAL (por lo menos para mí lo es)

Te paras frente a un grupo  que acaba de salir de un Review (Ver en que consiste Scrum y sus distintas reuniones/ceremonias/conversaciones haciendo clic aquí), hay una serie de emociones:

  • el equipo salió bien, 
  • el equipo salió mal. 
  • no tan bien como lo hubieran deseado 
Tienes tu taco de post-it en la mano -por lo general -  y estas ahí como su Scrum Master (1), su coach, ellos saben y esperan que acompañados por ti se encuentre la mejora, y que realices en la retrospectiva las labores de líder jardinero (8):
  • se corten hojas y ramas
  • se limpien otras
  • se abonen algunas raíces
  • se fumiguen algunas plagas 
  • y se remueva la tierra 
Para que el equipo siga creciendo en el siguiente ciclo de forma constante, continua y saludable.

Y comienzas a hablarles... 

Todo esto es tensión y emoción es el momento donde agregas más valor tangible para el equipo.

Y es por eso que lo llamo RITO, pues debe ser visualizado, preparado para que los participantes reciban el efecto esperado.

Yo, por mi parte comienzo más o menos, con las siguientes palabras:

--

"Bueno señoras, señores, señoritas... muchachos..

por favor soltemos celulares, vamos a realizar bien esta reunión.

Terminó un sprint,  observo que nos fue de tal y tal forma 
  • tantos puntos comprometidos, 
  • tantos puntos logrados, 
  • tuvimos tales y tales incidencias de calidad (mejoramos o disminuimos en calidad)
  • el feedback del producto fue tal
Vamos a entrar en la retrospectiva y el objeto acá no es encontrar culpables, pero si es entender qué pasó, qué podemos entender para que en el siguiente ciclo corrijamos y mejoremos.. 

Recordemos los 4 acuerdos (7): ser impecable en las palabras, dar siempre lo mejor, no tomarse nada personal y no hacer suposiciones.

El derrotero que vamos a seguir es más o menos el siguiente
  1. entender cómo se sienten después del sprint (armar el escenario)
  2. cuales fueron los hechos que tuvimos en este sprint (recolectar datos)
    • puntos
    • bugs
    • cumplimiento de compromisos
    • cumplimiento (o no) de mejoras identificadas en retrospectivas pasadas   (en caso de que esta sea al menos la segunda retrospectiva)
  3. entender que sucedió (generar un entendimiento profundo de lo que pasó)
  4. proponer posibles pasos a seguir (decidir que hacer - empleando pensamiento divergente)
  5. priorizar la mejora (pensamiento convergente - máximo 3 cosas a mejorar en el siguiente ciclo)
    • mirar como llevar estas mejoras a acciones concretas, 
      • ejemplo: no solo decir mejorar la comunicación sino como mejorarla, es decir ¿creando un grupo de whatsapp para X situaciones?
  6. y cerrar la retro,
Vamos entonces a realizar la siguiente actividad...(por lo general tomo de aquí - clic acá - las que me gustan según el momento del equipo)(2)...

..." 

---


Unas veces digo más otras menos- según las circunstancias-  pero siempre comienzo mi retrospectivas con un pequeño discurso que "setea"/configura los ánimos, busca bajar los egos y disponer el espíritu para el proceso de mejora continua del equipo.

Este paso que yo hacia a mi modo - y que considero indispensable, siempre que se inicia una retrospectiva, ya sea con un equipo nuevo o no - , fue una sorpresa para mi encontrarlo corregido y aumentado por Tobias Mayer en su libro "Por un Scrum Popular" - clic aquí -, se le llama La Directiva Principal de las Retrospectivas (The Prime Directive) y existen muchas versiones:


  • English: Regardless of what we discover, we must understand and truly believe that everyone does the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.(4)
  • Español:Independientemente de lo que descubramos, debemos entender y creer de verdad que todo el mundo hace el mejor trabajo que él o ella podría, dado lo que se sabía en ese momento, sus habilidades y capacidades, los recursos disponibles y la situación actual.(5)
(Esta es la versión inicial)

  • English: We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so. Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones? We don’t always do our best. So let’s get real. (6)
  • Español: Somos seres emocionales y vulnerables, sujeto a un flujo continuo de influencias de cantidad innumerable de fuentes. A veces nos desempeñamos magníficamente, otras veces nos equivocamos. Mayormente estamos en algún lugar entre estos dos extremos. En este último período de trabajo todos hicieron lo que hicieron, y probablemente tenían razones para hacerlo. Aceptemos lo que es. Y ahora, ¿qué podemos aprender de nuestras acciones pasadas y qué podemos pensar para orientarnos en el futuro? No siempre hacemos nuestro mejor esfuerzo. Así que seamos realistas (6)
(Propuesta por Tobias Mayer)

y si seguimos buscando, podemos encontrar varias polémicas al respecto

Pero más allá de eso, siempre comienzo mis retrospectivas (o retros como les digo) con un pequeño discurso, igual o no, - no importa -, es el momento de aprender y avanzar, de empujarnos a ser mejores y para esto las mentes y los corazones deben estar dispuestos y un bálsamo para el alma y el espíritu siempre es bienvenido.


Saludos ágiles y hasta la próxima

Jorge Abad








Notas, aclaraciones y referencias
(1) En español se podría decir: Maestro del Scrum, Amo del Scrum, Experto del Scrum 
(2) Generador de retrospectivas - Retromat: http://plans-for-retrospectives.com/index_es.html
(3) Tobias Mayer. Por un Scrum Popular - clic aquí - 

sábado, septiembre 05, 2015

Errores de "Lesa Agilidad"

Hola a todos

Les comparto unos tweets y pensamientos sobre como fallamos al agilismo #LesaAgilidad

un abrazo

--









domingo, agosto 23, 2015

Comenzando con un equipo en Scrum: Bonus Track | Entrenando la Inteligencia Emocional

Cerrando  el ciclo  de

"Comenzando con un equipo en Scrum "  -- clic aquí – 

Quisiera recomendarles este curso virtual y gratuito sobre Inteligencia Emocional, elaborado por  Ingrid Astiz  @IngridAstiz (gran amiga, experta en capacitaciones vivenciales, proporcionar y mejorar ambientes en los cuales las metodologías ágiles pueden fluir) para Fuerza tres.


CURSO EIE = Entrenando la Inteligencia Emocional - ( clic aqui) 




Espero lo disfruten tanto como yo.

Saludos ágiles

Jorge Abad

Comenzando con un equipo en Scrum: Parte 4 - Triángulo dramático de Karpman

Continuando con la serie

Comenzando con un equipo en Scrum 
- clic aquí – 

Otro de los aspectos que explico a los equipos cuando comienzan con Scrum, casi siempre luego de la primera retrospectiva es el Triángulo Dramático de Karpman.



En donde pongo en evidencia que en los equipos -  por muchas circunstancias en la vida - hay quienes juegan al triángulo dramático,  siendo

  • perseguidores
  • superhéroes
  • víctimas o
  • más aun, hay quienes saltan continuamente en estos tres roles, siendo superhéroes luego perseguidores y luego víctimas.


Descripción de los roles del Triángulo Dramático [3]

Pero el objetivo entonces es hacer que el equipo sea CONSCIENTE de esos juegos  para que:
  •  se rompan los círculos 
  • y se detenga  la manipulación consciente o inconsciente.
 y en consecuencia se comiencen a sanar las relaciones en el equipo y comiencen a trabajar mejor.


Una forma de romper Triángulo Dramático [3]

La forma como lo hago es que envío un correo con los links [1] y [2], luego he notado que entre el equipo dicen:

- fulano es perseguidor
- sutano le gusta jugar a la victima
- perano le gusta ser superhéroe
- y se ríen

y luego lo reflexionamos en la retrospectiva.

Los dejo pues con este sencillo instrumento, que sirve sanar relaciones enfermas en los equipos y les ayuda a avanzar

Saludos ágiles

Jorge Abad.



<COROLARIO> 
Solo una nota para quienes son Scrum Masters:

¿TIENE SENTIDO ESTAR DISTANTE DEL EQUIPO FISICAMENTE?

yo creo que no, pues es necesario ver y sentir las relaciones del equipo, de forma que se puedan encontrar y apoyar mejores forma de trabajar e interactuar.

Recordemos el manifiesto: Preferimos las personas y sus interacciones (clic aquí)

</COROLARIO>




Referencias:



martes, agosto 11, 2015

Comenzando con un equipo en Scrum: Parte 3 - Dando Feedback

Siguiendo con la serie

Comenzando con un equipo en Scrum 
- clic aquí – 

Existe otro aspecto a explicar y es el del Feedback y la Comunicación Asertiva, pues en un equipo que está pasando de ser Tradicional, donde cada uno es responsable por ciertas filas del Diagrama de Gantt – y pare de contar -, a uno Ágil donde el equipo asume una responsabilidad y compromiso colectivo, es natural que comiencen a existir fricciones naturales en el equipo en pro de lograr el objeitvo ( Ver fase de Conflicto (Storming) en la formación de equipos ) y es allí donde es necesario saber comunicarnos.

Vamos por partes


Consejo 1. Al comunicar algo compártelo con base en los hechos y no los juicios

Veamos unos ejemplos

Es muy diferente decir:

  • Estas llegando tarde a todas las reuniones del equipo (hecho real y tangible)


A decir
  •  Eres un irresponsable, no te importan el equipo ni la empresa (juicio de valor)

La primera afirmación está basada en los hechos, la segunda es una generalización y hace afirmaciones que pueden no ser ciertas del todo y que rompen el lazo del diálogo y la comprensión.


Consejo 2. Al comunicar algo basado en los hechos acompáñalo de las emociones, para generar empatía

Las emociones son el punto de contacto común entre todos, en sí los hechos pueden ser o no malos, me gusta mucho este video de OASIS – Stand by Me (clicacá)  donde hechos que creíamos que eran de una forma resultan ser de otro modo.

Volviendo a las emociones, todos hemos sentido tristeza, decepción, amor, rabia, etc, son nuestro punto de contacto, de empatía, es por eso que las condolencias dadas por alguien quien ha pasado una pérdida similar son sentidas más sinceras, al igual que la felicitaciones, etc.

Es por tanto, importante acompañar nuestras afirmaciones sobre los hechos con nuestros sentimientos, así logramos empatía y comprensión, y de igual forma nos abrimos a la escucha y a ser entendidos.

Sigamos con el ejemplo

  • Estas llegando tarde a todas las reuniones del equipo y esto me hace sentir que no te importa el equipo y su trabajo, la verdad me hace sentir frustrado tu actitud.
  • [Hecho] + [emociones producidas por el hecho o evento]


Consejo 3. Si hemos de dar un juicio, hagámoslo proporcionando un punto de comparación

No soy muy amigo de los juicios, soy más amigo del feedback (aunque la verdad prefiero el feedforward  -vermás acá- ), pero en caso que te veas abocad@ a realizarlo es sugerible la siguiente estructura:

  • En el desarrollo de este componente te faltó atención pues todos los anteriores los habias desarrollado de forma correcta, pero este tiene muchos bugs
  • [juicio] + [comparación con un hecho]


Adicionalmente, te comparto un excelente template para proporcionar feedback, elaborado por mis amigos de Kleer.


Espero estos sencillos consejos mejoren la dinámica de sus equipos y en sus diferentes relaciones laborales y familiares.


Saludos ágiles

Jorge Abad




domingo, agosto 09, 2015

Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos

Siguiendo con la serie

Comenzando con un equipo en Scrum - clic aquí - 


Otro de los aspectos que he notado que es importante al dar inicio con un equipo que quiere convertirse en Equipo Ágil, es hacerlos conscientes de los ciclos de vida de los equipos y que es natural todas las etapas por las que van a pasar:

Estas fases con conocidas como el Modelo de Tuckman de los equipos:

1. Formación ( Forming), se caracteriza por:

  • la incertidumbre en el equipo
  • los miembros del equipo estan sondeando a todos los miembros
  • estableciendo conductas aceptables
  • al finalizar esta etapa todos comienzan a sentirse parte del equipo
  • El líder debe dirigir
  • El Scrum Master sería Scrum Mom* (Mamá Scrum = Apegados a las reglas) 
2. Conflicto (Storming), se caracteriza por:

  • conflictos internos
  • los miembros del equipo acepta la existencia del grupo
  • hay resistencia a las restricciones que se les impone a sus individuos
  • al finalizar esta etapa el equipo cuenta con un esquema de liderazgo claro para todos
  • El líder debe actuar como coach
  • El Scrum Master comienza a ejercer su rol como es esperado en el modelo y ayuda a resolver conflictos
3. Normalización (Norming), se caracteriza por:
  • el grupo manifiesta su cohesión
  • se despierta un sentido de identidad y camaradería
  • se culmina esta etapa cuando
    • se solidifica la estructura del equipo
    • se ha asimilado las expectativas sobre el comportamiento correcto
  • El líder actúa como facilitador
  • El liderazgo comienza a ser compartido con el equipo
  • El Scrum Master ejecuta su rol como lo espera el modelo
4. Desempeño (Performing), se caracteriza por:
  • la energía del equipo ya no se dirige hacia concocerse sino hacia la tarea que lso cocupa
  • el equipo es consciente y responsable de sí mismos y realmente es un equipo autogestionado
  • Se consideraría la ultima etapa si el equipo no es disgregado
  • El equipo requiere que el  líder le delega tareas y proyectos, el equipo no necesita ser instruido o asistido
  • El líder delega
  • El Scrum Master actua como un Scrum Sensei*
5. Separación (Adjourning), se caracteriza por:
  • la conclusión de las tareas encomendadas
  • unos miembros reciben con gozo los logros alcanzados
  • otros miembros del equipo se entristecen por la finalización del equipo
  • Los miembros que llegaron a esta etapa son grandes facilitadores para acompañar a otros equipos en su jornada al alto desempeño


Comparto a continuación algunas imágenes y referencias en los que se puede profundizar y reflexionar:

MODELO DE TUCKMAN: RELACIONES Y DESEMPEÑO
Modelo de Tuckman

Relación entre los miembros de equipo en el modelo de Tuckman

Desempeño del equipo en sus diferentes etapas en el modelo de Tuckman


MODELO DE TUCKMAN: TIPO DE LIDERAZGO SEGÚN LA ETAPA DEL MODELO






MADUREZ DEL SCRUM MASTER EN EL TIEMPO*




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

Etapa del equipo
Tipo de Scrum Master Requerido

Scrum Dude
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





Saludos ágiles
Jorge Abad