¿Qué hacer para tener reuniones de valor?

Reuniones de valor - Cortesía de Pixabay

Una de las cosas que más me sorprende es el mar de reuniones que suele haber en algunas empresas. Reuniones que muchas veces se solapan y que carecen de la facilitación adecuada. Suele ocurrir entonces una escasa asistencia y cancelaciones de las mismas media hora antes. A mi me ha pasado recibir una cancelación estando de camino, y a Jaume le ha pasado viniendo de Barcelona, recién llegado la noche anterior al hotel en Madrid.

Alexandre me comentaba que en Brasil pasa tres cuartos de lo mismo y lo que hizo fue crear un sistema en que hay que ganárselo para poder ir a una reunión, y que se resume en los siguientes puntos:

• Si alguien quiere tratar un tema lo propone y ha de encontrar a dos personas que le respalden.
• Conseguidos dos respaldadores se comunica la reunión y los interesados deben pedir apuntarse.
• El proponedor acepta y declina a los peticionarios, con lo que ir a una reunión es algo que se vuelve de valor. De esta manera el proponedor hace que las personas adecuadas estén dentro y las no adecuadas queden fuera.

Cuando tenga oportunidad de probar este sistema contaré mi experiencia... aunque intuyo que voy a tardar un poco.

¿Se puede hacer una retrospectiva con un tablero virtual?

Las personas no dejan de sorprenderme... aunque todo lo que ocurre sea naturaleza humana, y sabiendo que cuando permites que florezcan aparecen los comportamientos humanos más espectaculares, como la colaboración, no deja de sorprenderme como evolucionan los equipos a través de las retrospectivas... y eso hace que me sienta muy bien :-D

Tablero Trello de retrospectiva

6 de 8 equipos de una tribu con la que trabajo han optado por hacer sus retrospectivas con Trello. Algunos de los miembros están localizados en otras ciudades de España, y todos, incluidos los que están en Madrid, hacen sus retrospectivas con Trello.

Los que están colocalizados se reúnen en una sala y participan con los que están en remoto por videoconferencia. En las salas se proyecta a las personas en videoconferencia, así que se ven todos y pueden leer sus expresiones y gestos, a la vez que todos comparten un tablero Trello que trabaja cada uno en su portátil. Trello se sincroniza al momento en los diferentes dispositivos de los miembros con lo que todos participan del mismo punto de referencia. El tablero suele tener las siguientes columnas:

• :-) ¿Qué ha funcionado bien?
• :-( ¿Qué no ha funcionado?
• Las ideas para mejorar
• Agradecimientos
• Acciones exitosas

Las retrospectiva comienza con un vaciado de la columna de "Agradecimientos", seguido de un repaso de la/s acción/es votadas en la retrospectiva anterior, de la que se mueven las que han funcionado a la columna "Acciones exitosas", las que no han funcionado se descartan. Así tenemos la evolución de las mejoras a lo largo del tiempo.

Luego todo el mundo añade post-its virtuales a las primeras cuatro columnas, en individual y a la vez. Lo interesante es que post-its de veces anteriores siguen ahí, con lo que la adición es incremental y se focaliza en mejoras nuevas.

Una vez acabado, cada uno lee sus post-its, en algunas ocasiones un miembro del equipo lo hace para todos, y finalmente se vota a viva voz. En un pequeño brainstorming se añaden ideas al/los post-it/s votados y se le/s señala con un sticker como mejora para el sprint entrante.

De esta manera equipos maduros en Scrum han creado su propia práctica de retrospectiva evolutiva que además ocurre en una media hora escasa. ¡Espectacular!

¿Un poco de historia de Scrum y Scrum Manager?

Póster del cuadro com las reglas de Scrum

Uno de lo cuadros sinópicos de Scrum que más comprensibles y claros son es el de Juan Palacio de Scrum Manager. Yo utilizo su póster impreso en un hule para explicar el ciclo de Scrum en mis clases.

Recientemente vi una noticia en LinkedIn que mostraba la versión 0.4 del cuadro, lo que me hizo mucha ilusión porque representaba un poquito de historia de Scrum Manager. Escarbé un poco en google, escribí a Juan y recopilé unas pocas versiones del cuadro, así que este post nació de la idea mostrar esas pequeñas obras de arte ágiles.

Marco en su primera concepción y presentación en sociedad por
Ken Schwaber en OOPSLA (1995) - SCRUM Development Process

1990: A principios de la década Ken Schwaber empleaba una primera aproximación a Scrum en su compañía, Advanced Development Methods, a la vez que Jeff Sutherland desarrollaba una aproximación similar en Easel Corporation y fue quien le diera el nombre de Scrum.

1995: Ken Schwaber y Jeff Sutherland presentaron una serie de artículos que describian Scrum en la OOPSLA (1995). Ken Schwaber lo hizo en su artículo SCRUM Development Process donde describió la implementación de Scrum para software que él empleaba en el desarrollo de Delphi. A partir de ese momento Schwaber y Sutherland colaboraron para consolidar las mejores prácticas de la industria en lo que hoy se conoce como el marco de Scrum.

Figure 1.1: Scrum Summary de Schwaber y Beedle

2001: Ken Schwaber y Mike Beedle describieron el marco en su libro "Agile Software Development with Scrum".

"Las implementaciones de Scrum para desarrollo de software se vienen enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken Schwaber. Ahora es muy raro que alguien configure un campo de Scrum con los controles originales (paquetes, cambios, riesgos, soluciones…), la pila única ha evolucionado a pila de producto y pila de sprint." nos cuenta Juan Palacio en "Así era la primera implementación de Scrum para Software".

Scrum: Ficha Sinóptica Rev.0.3 - 2005

2005: Juan Palacio funda Scrum Manager que es el resultado de una iniciativa personal de un gestor de proyectos que decide ofrecer altruistamente una alternativa de formación de Scrum libre y gratuita a través de su plataforma on-line.

Una de las primeras versiones del cuadro que vió la luz fue la revisión 0.3. El facilitador y gestor de la ejecución del proceso recibe el nombre de Scrum Manager, sus responsabilidades no son del proyecto sino del grupo de procesos y métodos de la organización. Con el criterio de Scrum Management, es recomendable que las responsabilidades que cubre este rol, estén identificadas en una única persona, sobre todo cuando se comienzan a aplicar prácticas de Scrum en la organización.

Scrum: Ficha Sinóptica Rev.0.4 - 2006

Modelo Académicio de Scrum Rev.0.6 - 2008

2008: El rol del facilitador / coach / gestor del marco toma el nombre del Scrum Master.

Desde la concepción inicial el marco de conocimiento se viene definiendo "de abajo arriba", el crecimiento y evolución son resultado de aportaciones de la comunidad profesional sobre la semilla de OOPSLA. En esta evolución de Scrum se fue añadiendo la reunión de revisión de sprint, la de planificación de sprint, y más tarde, sobre 2010, otra de retrospectiva.

En abril de 2014 Juan creó la versión del cuadro actual con el titulo Las Reglas de Scrum que corresponde a la revisión 1.1.

Las reglas de Scrum Rev.1.1 - 2014

Rev.1.1 con el Propietario del Producto en la retrospectiva

Y por último la revisión 1.1 tal como la utilizo yo con mis equipos.

En esta versión el Propietario del Producto asiste y es parte activa en las retrospectivas. Al fin y al cabo un Propietario del Producto está íntimamente ligado a un equipo de desarrollo, por tanto su asistencia a las retrospectivas puede aportar mucho a la mejora continua del proceso.

Descargas / Downloads

Descarga el póster con las reglas de Scrum Rev.1.1 a alta resolución.

---

ACTUALIZACIONES POSTERIORES

---

El ciclo de Scrum V.3 - marzo 2020

Manual Scrum Master

En 2020 Scrum Manager revisa el material del curso troncal en la parte referida al Scrum Master.

Gracias a Marta Palacio la guía de Scrum Manager es revisada con mejoras sustanciales en la maquetación, una revisión orto-sintáctica e ilustración profesionales.

El ciclo de Scrum V.3.03 - junio 2020

Y con la versión 3.03 se introduce el Propietario del Producto en la retrospectiva en función de su madurez ágil:

"Es importante que el Propietario del Producto se considere equipo más que cliente. Que la persona que desempeña el rol sea participativa y conocedora de los principios y valores de scrum.

Si esto no fuera así, el Scrum Master debe actuar como facilitador para lograr su compromiso y participación o, si la situación lo requiere, no incluirlo en la retrospectiva."

---

Mis agradecimientos a Juan Palacio por compartir sin pedir y haber hecho posible Scrum Manager :-)

¿Cómo ha de ser la estrategia en una compañía ágil?

Estrategia deliberada o intencional - cortesía de Pixabay

Entre mediados de los años 50 a mediados de los 70, en un mundo relativamente predecible, la estrategia de una compañía se hacía exclusivamente en la planificación estratégica.

Esta planificación es una responsabilidad y actividad del equipo ejecutivo, donde en base al contexto actual, este establece un objetivo final e identifica los pasos a seguir y que suele materializarse en un plan anual. Por lo general el equipo ejecutivo contribuye a la estrategia y el siguiente nivel de gerentes desarrolla partes locales que son integradas en este plan anual.

Una vez obtenido el plan anual la compañía se centra en seguir la estrategia definida, con una clara separación entre quién ha planificado y quién la ejecuta. Una evaluación anual de la organización, sus fortalezas, debilidades, oportunidades y amenazas llevan al desarrollo de nuevas estrategias y un nuevo plan anual. A este enfoque clásico se le conoce como estrategia deliberada o intencional.

Hoy en día la planificación estratégica es un oxímoron ya que asume que al definirla disponemos de toda la información y tenemos el control de nuestro mercado y producto. En los años 80 entramos de pleno en el mundo VUCA, un entorno de mercado muy volátil en el que los cambios ocurren a mucha velocidad y el medio y largo plazo a veces son impredecibles. En esta nueva realidad la planificación estratégica corre el riesgo de ser víctima de su rigidez y minimizar la competitividad de la compañía. ¿Qué empresa es hoy en día dueña de su producto?

Henry Mintzberg acuñó el termino de estrategia emergente

Henry Mintzberg, experto en management, sostiene que la planificación estratégica ciega a la dirección de las empresas, esta inhibe el pensamiento y el análisis de las condiciones cambiantes en las que se desenvuelve la compañía. Es necesario ser consciente de esta turbulencia del cambio y tener la flexibilidad de una planificación emergente para poder hacerle frente y adaptarse. Muchas de las estrategias emergen cuando las personas y los equipos experimentan y resuelven pequeños problemas de los que aprenden y generan nuevas oportunidades.

La estrategia emergente es el resultado de un proceso discontinuo, irregular, no sistemático y espontáneo de la ejecución estratégica, y que obedece al comportamiento y a las acciones que realizan las personas que intervienen en el proceso. Es un enfoque estratégico, aunque no deliberado, que consiste en aprender y sentir el camino a seguir y ajustar continuamente la visión a la realidad. Es un proceso de inspección y adaptación en el que descubrimos de forma continua las necesidades de nuestros clientes, sus propuestas e intenciones.

Como podemos imaginarnos Scrum es un marco de estrategia emergente, con cada revisión de sprint obtenemos feedback de aquellos que van a consumir el producto, por tanto cada sprint es un ciclo de aprendizaje para que negocio y Propietario del Producto puedan incluir información fresca en la estrategia del producto. La estrategia deliberada o intencional viene marcada por la visión inicial de producto, que primero se materializa en la pila de producto y luego evoluciona con la misma de forma emergente con cada sprint.

Los marcos de escalado también se basan en la estrategia emergente. Veamos donde esta está presente y como forma parte natural del marco de SAFe .

Puntos del big picture de SAFe donde se recoge la estrategia emergente

SAFe incorpora una capa de gestión de la demanda (portfolio) que es el punto donde la compañía inyecta temas estratégicos y que representa la estrategia deliberada o intencional. En este nivel el LPM (Lean Portfolio Management) identifica iniciativas estratégicas en forma de epics, todas ellas con un business case asociado. La estrategia emergente comienza cuando cada epic ha de consistir en un MPV (Mínimo Producto Viable), y por tanto sus hipótesis se han de validar mediante el ciclo Lean-Startup antes de enviarlo a desarrollar a los trenes.

El noveno principio de SAFe habla de descentralizar las decisiones; otorga poder de decisión a aquellos que están donde la información, por tanto Product y Solution Management tienen toda la autoridad para incluir decisiones estratégicas procedentes de las realidades a su nivel (programa y large solution). A nivel de tren SAFe prescribe la Exploración Continua, un proceso de exploración continua del mercado y las necesidades de los usuarios que redefine y ajusta mediante el ciclo Lean-UX la visión, la hoja de ruta y la pila de programa. Cada PO-Sync es un evento donde se trata información fresca proveniente de la exploración continua y por tanto es donde se produce gran parte de la estrategia emergente.

Otra fuente de estrategia emergente está en el evento core de SAFe, la PI Planning. Ocurre cuando los equipos "cocinan" las funcionalidades de la pila de programa, que representan la intención, y obtienen de forma emergente la factibilidad a través de los planes y los objetivos de PI. Recordemos que en la revisión de los planes Business Owners y Product Management aprenden sobre ajustes de visión, alcance y recursos, que no es más que otra manifestación de la estrategia emergente.

Quiero dedicar este post a Dani, quién me descubrió a Mintzberg :-)