jueves, 16 de mayo de 2019

¿El tamaño de una tribu/ART (Agile Release Train) está limitado a semejanza de un equipo de Scrum?

¿Alguna vez habéis asistido a un boda de 90 personas? ¿A que os lo habéis pasado bien y hasta interactuado con la mayoría de los invitados? ¿Y en una de 300 invitados? También nos lo podemos pasar bien, pero en un subgrupo y sin tener consciencia del grupo de los invitados, lo que es el sistema; es por ello que una boda de 300 invitados es un sitio ideal para colarse a comer bien... todos piensan que vienes de parte de la familia de la otra parte o una amistad lejana.

Tribu o tren con cultura única
Cortesía de Pixabay
Al igual que los equipos integrados, como lo son los ágiles o de Scrum, donde existe una limitación neurobiologica de como máximo 9 miembros, existe un tipo de limitación similar que ocurre con la cantidad de individuos que pueden relacionarse plenamente en un sistema determinado, que es de aproximadamente de 125-150 individuos. Ese límite del tamaño de grupos grandes está relacionado con el tamaño de la neocorteza cerebral y su capacidad de proceso.

Este número se conoce como el número de Dunbar y que es resultado de los estudios e investigaciones del antropólogo Robin Dunbar que explica el tamaño de las tribus y villas y por ende de redes sociales (los amigos, la familia, la profesional y también virtuales como facebook y linkedin). Históricamente las villas y las tribus, compuestas de familias en lugar de equipos, se dividían en dos cuando alcanzaban este número, es algo que está enraizado en la naturaleza del ser humano.

Por tanto el tamaño de una tribu (ágil) o de un tren (ART) no debe de ser superior en número de individuos al número de Dunbar. Por encima de ese número no es posible crear una cultura única y conseguir cierto grado de autoorganización.

La autoorganización en el tren ocurre cuando colaboramos y nos ayudamos; si una persona me pide ayuda y la conozco y sé que está subida al tren, se la voy a prestar: sé que mañana esa persona u otra me ayudará mi. Pero si no conozco a la persona, no la asocio a mi tren, ayudaré si tengo buena voluntad, pero no lo haré desde la perspectiva sistémica de unidad de un tren.

Este post nació de una conversación con Matt, un RTE experimentado en toda clase de trenes, tanto ARTs como Solution ARTs. Me contó que una vez le pidieron que acompañara un tren con más de 180 personas, primero se resiitió pero insistieron y aseguraron que lo arreglarían después. Aparentemente todo fue muy bien, la sorpresa ocurrió en la tercera PI Planning cuando dio la bienvenida a dos personas que pensó se acaban de incorporar y descubrió que llevaban subidos al tren desde el primer momento... ese hecho puso de relieve la limitación de Dunbar y muestra como un system thinker, que es el RTE, puede no percibir el sistema al completo y por tanto errar en su trabajo
El número de Dunbar muestra una limitación a 125-150 individuos para trenes y tribus que deriva de la naturaleza humana

domingo, 12 de mayo de 2019

¿Cuándo usar Scrum o métodos ágiles?


Marco de Cynefin de Dan Snowden
En los acompañamientos y en las clases suele ocurrir que alguien pregunte: ¿qué es mejor, Scrum o la gestión de proyectos tradicional?

Realmente una forma de trabajar no es mejor o peor que la otra, son formas distintas y cada una ellas es la mejor solución para diferentes contextos.

Para clarificarlo vamos a adentrarnos en el marco de Cynefin de Dan Snowden que se muestra en la imagen de la derecha, un modelo que contiene una tipología de contextos que se describe como un "marco de control empírico".

Simple

El dominio simple representa los "conocidos conocidos". Son problemáticas simples en donde hay reglas (o mejores prácticas), la situación es estable, y la relación entre causa y efecto es clara: si haces A ocurrirá B. No es necesario pensar la solución, se afronta con "percibir-categorizar-responder": percibe los hechos, categoriza y luego responde siguiendo la regla o aplicando la mejor práctica. Snowden y Boone ofrecen el ejemplo del procesamiento de pago de préstamos: un empleado identifica el problema (por ejemplo, un prestatario ha pagado menos de lo requerido), lo categoriza (revisa los documentos del préstamo) y responde (sigue los términos del préstamo).

Complicado

El dominio complicado consiste en "desconocidos conocidos". La relación entre causa y efecto requiere de un análisis o de una experiencia previa; hay un rango de respuestas correctas. El marco lo afronta con "percibir-analizar-responder": evaluar los hechos, analizar y aplicar la práctica apropiada. En este contexto es necesario "pensar" para aplicar la mejor práctica, es en este contexto donde se mueven los ingenieros, cirujanos, analistas de inteligencia, abogados y otros expertos. Un ejemplo sería la ingeniería civil, la construcción de un puente.

Complejo

El dominio complejo representa los "desconocidos desconocidos". Causa y efecto sólo se pueden deducir en retrospectiva, no sabemos con anticipación si una determinada solución va a funcionar, hay que descubrir la mejor solución. No hay buenas respuestas. Requiere pensar e innovar, y lo único que podemos hacer examinar los resultados y adaptarnos. Cynefin llama a este proceso "probar-percibir-responder". Casos de seguros difíciles o el desarrollo de software son un ejemplo de este contexto en el que se requieren niveles altos de creatividad, innovación, iteración y comunicación. 

Caótico

En el dominio caótico la causa y el efecto no están claros. Los acontecimientos en este dominio son "demasiados confusos para esperar una respuesta basada en el conocimiento", escribe Patrick Lambe. No requiere pensar, "acción", cualquier acción, es la primera y única forma de responder adecuadamente. Un ejemplo es una sala de urgencias de un hospital, es imposible preveer, simplemente se puede reaccionar y actuar.

Vistos los cuatro contextos, el contexto por excelencia para Scrum es el complejo; es en este contexto donde con Scrum podemos encontrar prácticas emergentes a problemas adaptativos complejos a través de sus ciclos de inspección y adaptación para desarrollar nuevos productos o la incorporar nuevas funcionalidades en productos existentes.

Scrum también podría aplicarse en un contexto complicado, pero probablemente haya formas más eficientes dado que es posible plantear la solución ideal al principio en base a buenas prácticas. Lo que no funcionaría es aplicar una solución para un contexto complicado, como la gestión de proyectos tradicional, a un contexto complejo... y este es un aprendizaje que muchas compañías tienen pendiente todavía.

sábado, 4 de mayo de 2019

¿Cómo hacer una implantación DevOps?

Preparando una implantación DevOps
DevOps es un acrónimo inglés compuesto de development (desarrollo) y operations (operaciones), que se refiere a una práctica de ingeniería de software enfocada en primera instancia en una cultura de colaboración e integración entre los desarrolladores de software y los profesionales de sistemas. Los primeros, los equipos de desarrollo ágil, viven en el cambio continuo, mientras que los segundos velan por la estabilidad y la expansión de servicios existentes, un claro conflicto de intereses. Para la entrega de software de valor a demanda del mercado ambas partes han de comprender que es necesaria la colaboración junto con un sentimiento de responsabilidad compartida.

En segunda instancia DevOps impulsa la automatización y el monitoreo en todos los pasos del flujo de construcción del software; desde la hipótesis de nuevas funcionalidades, la integración, el despliegue, el lanzamiento al mercado y posterior monitoreo de software para el aprendizaje sobre la hipótesis inicial. DevOps apunta a ciclos de desarrollo muy cortos con lotes de funcionalidades pequeños, alta frecuencia de implementación y lanzamientos más confiables que están en estrecho alineamiento con los objetivos de negocio de la compañía.

En el mundo VUCA actual la Agilidad no es una opción, esta hace que las compañías sean competitivas, por lo que se ha convertido en un imperativo de negocio. A su vez DevOps no es una opción, ya que sino la Agilidad no sería posible, no podemos ser competitivos sin los ciclos muy cortos de entrega de valor que posibilita DevOps.

La mayoría de compañías, por no decir todas, ya practican DevOps en alguna de sus facetas, la cuestión es cuan eficientes son. ¿Quién no tiene ya algunas pruebas automatizadas?, ¿quién no tiene un Jenkins rodando?...

DevOps Health Radar de SAFe
con la situación actual de una compañía
El radar DevOps de SAFe® tiene 4 dimensiones con un total de 16 subdimensiones. Cada subdimensión tiene 5 niveles, donde el 1 significa que todo se hace manualmente y 5 representa la máxima madurez DevOps. Hay técnicas, prácticas y herramientas que nos permiten pasar de un nivel a un nivel superior, por tanto el radar proporciona un total de 64 (4 posibles saltos por 16 subdimensiones) oportunidades y soluciones de mejora para nuestra aplicación de DevOps.

Una implantación de DevOps parte de encontrar la situación actual de la compañía averiguando cual es el nivel de cada una de las subdimensiones. SAFe proporciona la descripción de cada una de las coordenadas subdimensión/nivel del radar. En un taller a tal efecto, las personas de las áreas, los responsables y los equipos de desarrollo que participen en el flujo de construcción de software, conocido en SAFe como la Continuous Delivery Pipleline, identifican y representan la situación actual en el radar.

Seguidamente se representa el flujo de construcción mediante un Value Stream Mapping; se identifican todos los pasos desde que se concibe una funcionalidad hasta que es usada por usuario finales, se miden los tiempos de servicio (que miden el tiempo de puro trabajo en cada estado) y tiempos de entrega (que incluyen la espera entre estados) y el % de trabajo que pasa limpio y sin incidencias al siguiente estado. El mapa nos mostrará donde tenemos oportunidades de mejora en los puntos con los mayores retrasos o de más retrabajo. Basta con buscar la subdimensión afectada en el radar y decidirse por una de las prácticas, técnicas o herramientas que propone.

El mapa obtenido es un artefacto vivo, podemos implantar DevOps de forma paulatina actualizando el mapa de forma periódica para implantar mejoras. Se basa al igual que la Agilidad en un sistema de mejora continua que puede llevar años para su madurez, pero con el beneficio de la obtención de mejoras de forma muy rápida.
Value Stream Mapping del flujo DevOps actual para buscar mejoras en el radar
Si a alguien le interesara aprender sobre el radar de DevOps y como hacer el taller de Value Stream Mapping le quiero invitar a apuntarse a uno de los cursos de SAFe DevOps Practitioner (SDP) que hacemos en Estratecno. Es un curso/taller ideal para las áreas de sistemas cuyo objetivo debería de ser habilitadores para que los equipos ágiles sean más rápidos.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

viernes, 3 de mayo de 2019

¿Cómo comunicar la visión y misión de una compañía?

Sesión sobre managment y liderazgo en el Coach Camp
Thanks Kitty for the picture ;-)
Este año en el Agile Coach Camp de Madrid hubo varias sesiones sobre managment y liderazgo. Ante el creciente número de transformación ágiles la comunicad de coaches ya no solo se focaliza en los equipos, sino también eleva la vista para tratar sobre como acompañar a directivos y ejecutivos. Uno de los puntos clave es la visión de la compañía, que bien comunicada crea un objetivo e misión comunes e impulsa la colaboración dentro de la misma.

Entre los ocho grandes errores que menciona John P.Cotter en su libro "Al frente del cambio" hay tres de ellos que mencionan la importancia de la visión
  • Subestimar el poder de la visión
  • Subcomunicar el poder de la visión en 10-100X
  • Permitir obstáculos para bloquear la nueva visión
Por tanto la visión es un elemento clave en toda transformación o construcción de un producto; esta describe un logro o el estado futuro que la empresa quiere lograr y esta ha de ser compartida en todas las áreas de organización, tanto a nivel de equipos como a nivel de personas individuales. 

Los directivos y ejecutivos no pueden hacer realidad cambios exitosos por su cuenta, necesitan la comprensión, la aceptación y el entusiasmo de los equipos para colaborar entre todos y hacer avanzar a la empresa hacia la visión.
Se debe compartir la visión para que haga lo que se supone que
debe de hacer - cortesía de Pixabay
Si cada individuo, equipo y unidad de negocio tiene un concepto claro de cómo su trabajo y misión ayudan a contribuir a los objetivos más amplios del logro o la empresa, es mucho más probable que puedan colaborar y trabajar en armonía para lograrlos.

La responsabilidad de un líder es comprender y comunicar la visión de una manera que sea relevante para cada equipo e individuo, debe inspirar, aclarar, enfocar y ejemplificarla mediante un comportamiento alineado con la visión.

Una forma muy potente para comunicar una visión es involucrar a los mandos intermedios en el diseño de la misma, así sentirán la visión como suya y se encargaran de comunicarla con pasión y de forma muy eficaz.

Hay empresas como Ericsson que ponen en cada área un experto que entienda la visión y decodifique el mensaje para ayudar a entender qué implica en ese área, cuál es la misión y da guía de qué hacer. Así la visión y objetivos de la compañía son idénticos a lo largo de diferentes localizaciones geográficas, un empleado en Suecia tiene la misma visión y misión que un empleado en Singapur por ejemplo, lo que facilita enormemente la colaboración

Del artículo "SEIS BREVES RECOMENDACIONES PARA COMUNICAR LA VISIÓN" que propone Darlene Price para compartir una visión de forma que consigamos influir en los demás y conseguir que la adopten:
  1. Apoyarnos en una historia atractiva: Cuando contamos una buena historia le damos vida a una visión, a las personas les resulta más fácil repetir una historia que hablar sobre la visión.
  2. Tener la capacidad de en forma muy breve comunicar la visión: de forma concisa, clara, breve y convincente, por ejemplo a través de un elevator pitch bien elaborado.
  3. Utilizar una palabra o frase que enganche: Una palabra o frase corta, bien elegida, capta la atención, comunica valor y ayuda a que los demás recuerden nuestro mensaje.
  4. Programar conversaciones cara a cara: recomendación totalmente alineada con el sexto principio del Manifiesto Ágil; las conexiones que se generan cara a cara brindan a los líderes la oportunidad de transmitir información, recibir feedback, generar apoyo y crear energía en torno a la visión.
  5. Actuar: Si apoyamos la visión con acciones y la reforzamos con comportamientos para alcanzarla, los demás nos creerán con mayor facilidad.
  6. Preparar y practicar una presentación dinámica: usar ayudas visuales y actualizaciones para que todos estén al tanto del progreso que está logrando en la visión.

domingo, 28 de abril de 2019

¿En una organización muy madura podemos prescindir del Propietario del Producto?

¿Propietario del Producto o Feature Owner?
Photo by bonneval sebastien on Unsplash
A medida que una compañía madura en su forma de trabajar, un Scrum Master en su forma de coach de equipos, llega a ser prescindible cuando los equipos de desarrollo están rodados y la cultura empresarial está fuertemente asentada para que estos puedan evolucionar sin acompañamiento a través de la mejora continua.

La cuestión es si en una empresa madura, en la que exista un verdadero sentimiento de compromiso en todos los empleados, es posible prescindir del Propietario del Producto. Este, en un ambiente muy maduro y como parte del equipo de Scrum que enlaza con los interesados y la gente de negocio, puede convertirse en un cuello de botella que dificulte la aceleración del flujo de entrega de valor.

El compromiso de los business owners, o interesados/usuarios/cliente clave, es la mayor garantía de que la empresa esté invirtiendo adecuadamente en el producto, ya que estos aseguran que los equipos están trabajando en lo que dé máximo valor de negocio. Entendido esto, ¿no seria más deseable que los equipos trataran directamente con los business owners?

Podríamos pensar en business owners desalineados y con intereses propios, pero en una empresa madura que fomente visibilidad y transparencia y que tenga una visión y misión bien definida y comunicada, existirá un objetivo y propósito que imperará por encima de los intereses individuales y fomentará la colaboración de todos los business owners hacia un objetivo común.

Hace poco tomando una cerveza con Alexandre este me contó de una empresa que había acompañado y en la que decidieron prescindir del rol del Propietario del Producto. Crearon el rol de feature owner, un interlocutor principal por funcionalidad, que es quién añade funcionalidades a la pila de producto y es el que la sigue hasta su validación en un entorno productivo. Esta idea está totalmente alineada con LeSS en su concepto de pila única cuyos propietarios son los equipos.

Para priorizar la pila de producto una buena opción es la técnica "buy a feature" en la que participan todos los features owners: 
  • Cada uno presenta sus funcionalidades que previamente han sido estimadas en esfuerzo por el/los equipo/s de desarrollo.
  • Cada feature owner obtiene un presupuesto de dinero ficticio para gastar, este debe estar entre un tercio y la mitad del esfuerzo total.
  • Los feature owners usan su presupuesto para comprar las funcionalidades que sean más importantes para cada uno de ellos.
  • A medida que los jugadores compran se recolecta el dinero y estos explican por qué están comprando esa funcionalidad.
  • El juego termina cuando se acaba el dinero o cuando los jugadores han comprado todas las funcionalidades en las que están interesados. Finalmente el total de dinero ficticio obtenido por cada funcionalidad, de más a menos, determinará la prioridad de la pila de producto.

martes, 16 de abril de 2019

¿Por qué utilizamos post-its en Scrum?

Tableros con post-its que gestionan los
flujos de valor y trabajo de la compañía
La Agilidad se ve rodeada de post-its, solemos asociar una pared con post-its con equipos de Scrum o Kanban, transformaciones ágiles y Agile. ¡Hasta he oído que la Agilidad consiste en pegar post-its en un tablero o las paredes!

A parte del colorido que aportan los post-its ¿cuáles son los beneficios de utilizarlos?

El post-it es algo muy flexible, podemos escribir en él lo que tenga valor, podemos llevarlo a otra área de la sala o del edificio y tener conversaciones con otros alrededor del concepto escrito, y llegar a acuerdos y decisiones que podemos refleja en otro post-it, quizá de otro color. Los colores de los post-its nos permiten mostrar items de diferentes naturalezas; quizá amarillo para unidades de trabajo, rojo para bloqueos, verde para incrementos funcionales, etc... las personas somos visuales y los post-its son un elemento de trabajo muy alineado con la naturaleza humana que nos hace asimilar y recordar mejor sobre lo que tratan.

En Agilidad los equipos de Scrum o de Kanban hacen que sus post-its recorran tableros en los que se representan diferentes estados en columnas, por tanto los post-its recorren flujos de valor o flujos de trabajo. Eso convierte a los tableros y sus post-its en una gestión visual del flujo y verdaderos puntos de referencia para los equipos, áreas y la compañía en sentido más amplio. Estos dan absoluta visibilidad y transparencia al progreso, podemos ver la situación general o agregada cuando observamos el tablero desde la distancia, y podemos ver el detalle acercándonos a los post-its individuales. Irradian de forma continua la situación actual, son puro elemento de gestión del flujo y de conexión y comunicación entre personas.

Pero, ¿no valdrían de igual manera herramienta con tableros y post-its virtuales como JIRA o Redmine

Visto el punto anterior una de las grandes desventajas de las herramientas con tableros virtuales es que no suelen estar preparadas para dar una visión agregada del tablero, este no suele caber al completo en un solo pantallazo, con lo que se minimizan los beneficios de la visión holística, y eso provoca que las personas pongan el foco en los elementos individuales, probablemente los propios, y se pierda la visión periférica y la colaboración se sienta resentida.

La desventaja más importante es que las herramientas tienen sus procesos embebidos, con lo que las personas ponen el foco en aprender a utilizar la herramienta y sus procesos, no a desarrollar su propio proceso a través de la mejora continua, tal como fomenta la Agilidad. A diferencia de estas los tableros con post-its fomentan la colaboración y el desarrollo del propio proceso a través de la mejora continua.

Para los ecologistas y los que piensan que los post-its hacen que empresas como 3M se forren, quiero invitarles a leer el artículo de Alexander Helleboogh "About post-its and trees" en el que se concluye que un árbol medio provee de 100 post-its al sprint a 10 equipos de Scrum durante 5,5 años, mientras que un árbol no es suficiente para proveer de papel de WC a una única persona en el mismo periodo.

sábado, 13 de abril de 2019

¿Qué significa que un Scrum Master es un System Thinker?

Equipo de desarrollo, el sistema del Scrum Master - cortesía de Pixabay
Imaginemos una situación en la que en un evento de Scrum, por ejemplo una planificación de sprint, un miembro del equipo participa escasamente y está sumido en su móvil.

Un facilitador no System Thinker lo que haría sería dirigirse a la persona en concreto, quizá en un break, y hacerle ver que su comportamiento no es el adecuado y que perjudica seriamente al resto y al evento.

Para fomentar un comportamiento adecuado como equipo integrado es necesario una comprensión superior del sistema y hacerles entender a todos los miembros que la creación del valor solo es posible mediante la colaboración de todos los miembros. Por tanto un Scrum Master System Thinker percibe y entiende el problema a nivel de equipo e intentará resolver el problema desde el equipo, utilizando el sistema para resolver el problema y así hacer evolucionar y crecer al equipo.

En la situación descrita al inicio del post un Scrum Master reconoce el problema que hay en el sistema y pensará en qué actividad o práctica puede intentar aplicar para hacer emerger el problema y que ayude a que el propio equipo lo resuelva. Por ejemplo una práctica colaborativa, como un planning poker, una retrospectiva, una dinámica de team-building... una dinámica en la que todos tengan que participar y donde la peer pressure hará que la persona disonante se alinee.

Liberating Structures tiene un repositorio de 33 métodos
Podemos utilizar actividades de Liberating Structures que nos provee de un repositorio de casi medio centenar de métodos accesibles a un Scrum Master para hacer que todas las voces de un sistema o equipo participen, son métodos 100/100, 100% de los miembros al 100% en el 100% de las actividades. Mencionar que un 20/80 no es inusual, un 20% de los miembros acaparan el 80% de la actividad. Con estas actividades el Scrum Master hará que todos se sientan incluidos y comprometidos.

En otras ocasiones el Scrum Master utilizará alguna dinámica dirigida a resolver el conflictoEn una ocasión distribuí tres caramelos a todos los miembros del equipo y les invité a regalar sus caramelos al resto acompañando cada caramelo de unas palabras de agradecimiento por alguna razón concreta. El miembro disonante se quedó sin caramelos; me quedé cerca de él y cuando se acercó conversamos; él sabía perfectamente porqué había ocurrido.

Por ello es tan importante que los Scrum Masters tengan habilidades blandas como las habilidades sociales y conocimiento de coaching sistémico como el impartido por ORSC™.

El coaching sistémico entiende a empresas y equipos como un sistema formado por elementos interconectados cuyas acciones y decisiones individuales repercuten en los demás y en todo el sistema. Este tipo de coaching ayuda a cada individuo a contribuir al sistema completo y a lograr un equilibrio global, aporta soluciones sencillas y rápidas a situaciones complejas a través de la interrelación entre los individuos. Por otro lado sirve para detectar el origen de diferentes problemas o conflictos organizacionales para analizarlos y ayudar a solventarlos.