martes, 31 de diciembre de 2019

¿Qué técnica de team-building utilizar que ayude a las personas a comprender mejor su relación con ellos mismos y con los demás?

Recientemente un grupo de coaches ágiles que tenemos interés en el nuestro desarrollo profesional apoyando y enseñándonos unos a otros, practicamos una herramienta que ayuda mucho a conocernos tanto internamente como a nivel de equipo; La Ventana de Johari.

Se trata de una herramienta de psicología cognitiva creada por los psicólogos Joseph Luft y Harry Ingham para ilustrar los procesos de interacción humana. Es un modelo de análisis que ilustra el proceso de comunicación y analiza la dinámica de las relaciones personales. Intenta explicar el flujo de información desde dos puntos de vista, la exposición y la retroalimentación, lo cual ilustra la existencia de dos fuentes: los "otros", y el "yo".

La teoría se articula mediante el concepto del espacio interpersonal, que está dividido en cuatro áreas definidas por la información que se transmite:
  1. Área libre: lo que conozco sobre mi y los demás conocen de mi
  2. Área oculta: lo que conozco de mi y no cuento a los demás
  3. Área ciega: lo que los demás conocen de mi y yo no conozco
  4. Área desconocida: lo que ni yo ni los demás conocemos sobre mi
Estas áreas están permanentemente interactuando entre sí, por lo que, si se produce un cambio en un área este afectará a todos los demás.
Nuestro tablero con las cuatro áreas
Por consiguiente en función del grado de conocimiento existen:
  • 2 áreas que yo conozco, la 1 y la 2
  • 2 áreas que los demás conocen de mi, la 1 y la 3
  • 2 áreas que yo desconozco de mi mismo, la 3 y la 4
  • 2 áreas que los demás ignoran de mi, la 2 y la 4
  • 1 área que yo conozco de mi pero que los demás ignoran, la 2
  • 1 área que los demás conocen de mi pero que yo Ignoro, la 3
  • 1 área que ni yo conozco de mi ni os demás conocen de mi, la 4
Construyendo modelos durante la sesión
La dinámica que propongo en este post se basa en como hacer team-building de forma innovadora y creativa mediante Lego Serious Play para buscar ampliar el área abierta de la Ventana de Johari.

Lego Serious Play es una técnica de facilitación grupal que permite la reflexión, comunicación y resolución de problemas a través de una serie de retos diseñados por el facilitador y pensados para lograr el objetivo de la sesión.

Durante la sesión los participantes construyen modelos LEGO para dar respuesta a los retos planteados a través de un conjunto especial de piezas de LEGO, los Kits de LSP (Lego Serious Play), y estos modelos constituyen las bases para la discusión, compartir y generar ideas, la toma decisiones o la construcción de modelos compartidos.

En la caso de la sesión de la ventana de Johari, después de trabajar con unas preguntas o retos de calentamiento, que permiten a los participantes familiarizarse con el método, con las piezas y con la temática a tratar, se realizan las siguientes preguntas para trabajar las distintas áreas de la Ventana de Johari:

Para trabajar el área 1, la conocida por mi y por los demás, se pide a los participantes que construyan un modelo que refleje sus principales cualidades y valores que son esenciales para él. Cada participante comparte la historia asociada al modelo para describirlo y comenzar una rica discusión a través de los significados, metáforas y preguntas que van surgiendo sobre el modelo. Una vez que todos los participantes han descrito su modelo se reflexiona sobre los aprendizajes adquiridos. Para este punto los participantes dicen que les sirve para conocerse mucho mejor a ellos mismos, para identificar las prioridades que tienen en cuanto a sus valores esenciales y para conocer más profundamente a cada uno de sus compañeros.

Para trabajar el área 2, la conocida por mi y desconocida por los demás, se pide a los participantes que construyan un modelo que refleje algún aspecto que su personalidad o de su vida que piensen que sus compañeros no conocen. Se sigue la misma mecánica descrita en el punto anterior y para este punto cuando los participantes reflexionan sobre los aprendizajes adquiridos. En este punto suelen decir que les sirve para darse a conocer más profundamente a sus compañeros y los compañeros dicen que les permite acercarse mucho más y profundizar sus interrelaciones al conocerse más profundamente tanto personal como profesionalmente.
Ejemplo con modelos que construimos en la sesión
Y para trabajar el área 3, la desconocida por mi y conocida por los demás, se pide a los participantes que construyan un modelo que refleje cualidades que ven ellos de alguno de los compañeros y que sea probable que ellos mismos no sean conscientes de que las poseen. Se sigue la misma mecánica descrita en el punto anterior y para este punto cuando los participantes reflexionan sobre los aprendizajes adquiridos dicen que reciben una gran regalo de parte de su compañero y muchas veces lo que reflejan los modelos construidos son un gran descubrimiento para ellos.

El área 4, la que desconocen ambos no se trabaja, después de la sesión esta se habrá reducido.

Una vez superados todos los retos el ambiente generado en el equipo es espectacular. Ha sido una oportunidad para conocerse mejor, para desarrollar la confianza, descubriendo y compartiendo aspectos positivos desconocidos y fortaleciendo los lazos personales y profesionales entre los miembros del equipo.

Y ya para compartir mi experiencia mencionaros que en la sesión he descubierto como mis compañeros tienen un perspectiva de mi de la que no era consciente y que ¡por ello me valoran! También he tomado perspectiva emocional de mis compañeros y como ellos lidian con sus conflictos y emociones.

Este post se queda corto para transmitir lo que se puede aprender y descubrir en una sesión de Lego Serious Play, así es que os invitamos a participar en una y experimentarlo por vosotros mismos.

Descargas / Downloads
Mis agradecimientos a Miguel Ángel y a Ana por compartir su póster a través de mi blog y por ponerlo a disposición de toda la comunidad y todos aquellos que les pueda ser de interés.

miércoles, 18 de diciembre de 2019

¿Cómo nos ven los laicos a los coaches ágiles?

Informáticos para todo, de Taringa
Con este post quiero introducir un poco de humor, no todo tiene que ser serio :-D :-D

Los que tenéis un recorrido algo más largo en TI, sobre todo en microinformática, ¿os acordáis como os salían "clientes" no deseados por doquier? Te invitaban a su casa personas que casi no conocías a "arreglar la impresora" o a instalar un juego de ajedrez que se les resistía... Y luego todo lo que tenía que ver con botones se suponía que caía en tu área de conocimiento, como por ejemplo las centralitas telefónicas, de las que tengo conocimiento nulo y sobre las que más de una vez me pidieron ayuda. Ya el colmo fue cuando me pidieron arreglar una bandeja de esas que a modo de cajón corredero soportaba los teclados situados debajo de los escritorios.
Meme para el coach ágil

Pues bien, ya tenemos el primer caso documentado (en este blog) de como nos salen ese tipo de "clientes" a los coaches ágiles: a mi compañera Gertrudis le pidieron ¿nos puedes ayudar a pintar unos carteles?... hay coaches ágiles que tienen habilidades de facilitación gráfica, pero esta habilidad no es core para un coach ágil.

Humor aparte, situaciones como la última mencionada sirven para hacernos reflexionar sobre cuál es la visión que tienen de nosotros como coaches ágiles, y sobre qué podemos hacer para llegar a las personas en nuestro entorno para darles una visión real de lo que hacemos, de qué otras cosas sabemos hacer además de pintar carteles o facilitar reuniones.

Lo primero en situaciones como esta es tener una conversación amena para profundizar en las opiniones de nuestro interlocutor. Una cosa que funciona muy bien es trasladar la situación a la realidad del interlocutor. Si nos lo dice un abogado de civil, por ejemplo, le podemos decir ¿verdad que no eres experto en mercantil y si te llega algo de mercantil se lo pasas al departamento correspondiente?, y luego tratar de explicar el core de lo que hacemos, dónde aportamos valor y finalmente preguntarle en qué otras cosas podemos ayudarle.

La clave de un buen coach ágil es enseñar a pensar, a crear un entorno seguro donde todo el mundo pueda pensar.

Mis agradecimientos a Gertrudis por haber participado en este post, y a mi amigo Luís con el que he disfrutado mucho compartiendo estas batallitas.

lunes, 16 de diciembre de 2019

¿Cómo comprobar la salud de un sistema in extremis?

Crash test de AXA - cortesía de Pixabay
Cuando la industria de la automoción crea un coche nuevo, antes de ponerlo en el mercado, coloca un crash test dummy, un maniquí para ensayos de choque dentro, y estampa el coche contra la pared. Esta prueba extrema pone de manifiesto debilidades del coche, debilidades que han de corregirse antes de lanzar un coche seguro al mercado.

Como símil al crash test Netflix ha desarrollado la Simian Army, el ejército de simios que resulta en un conjunto de servicios o "monos" para comprobar la salud de sus sistemas y hacer ensayos de crisis provocando fallos en su software.

La construcción de software es un ingeniería compleja que implica bugs, no se puede garantizar al 100% que alguna parte no pueda fallar. Aún invirtiendo en el hardware más costoso y en las herramientas de software más modernas nada garantiza que en una situación crítica haya un fallo y tengamos un problema en el sistema. En Netflix son conscientes de ello y desarrollaron su arquitectura para que los componentes individuales puedan fallar sin afectar a la disponibilidad del resto del sistema.

Es necesario evaluar constantemente la capacidad del sistema para sobrevivir a todo tipo de fallos. Hemos de poner a prueba nuestro sistema, desenchufar el SAI, cortar el suministro, desconectar un servidor, para ver si de verdad el software está preparados para desplegarlo en producción. Esta es una de las premisas de un sistema resilente con capacidad para sobreponerse a imprevistos para minimizar o eliminar su impacto y no perjudicar a nuestros clientes.

José Luis Martínez nos habla en su post "El ejército de simios de Netflix" de los 8 monos:
Imagen de Wikipedia
  • Chaos Monkey: una herramienta que inhabilitaba de forma aleatoria servidores de producción para garantizar que el servicio se mantiene y no hay impacto para el cliente.
  • Latency Monkey: induce retrasos artificiales en la capa de comunicación cliente-servidor para simular la degradación del servicio y mide si los servicios responden adecuadamente.
  • Conformity Monkey: encuentra servidores que no se adhieren a las mejores prácticas y los apaga.
  • Doctor Monkey: aprovecha los controles de estado que se ejecutan en cada servidor y supervisa otros signos externos de salud (por ejemplo, la carga de la CPU) para detectar estados no saludables.
  • Janitor Monkey: asegura que el entorno se está ejecutando libre de basura y desperdicio. Busca los recursos no utilizados y los descarta.
  • Security Monkey: encuentra violaciones de seguridad o vulnerabilidades y finaliza las instancias ofensivas. También revisa los certificados SSL y DRM.
  • 10-18 Monkey: detecta problemas de configuración y tiempo de ejecución en instancias que atienden a clientes en múltiples regiones geográficas, utilizando diferentes idiomas y conjuntos de caracteres.
  • Chaos Gorilla: es similar a Chaos Monkey, pero simula una interrupción de toda una zona de disponibilidad.
La Simian Army está disponible como Open Source en GitHub, en la descripción se puede leer: "Simian Army consiste en servicios (monos) en la nube para generar varios tipos de fallos, detectar condiciones anormales y probar nuestra capacidad para sobrevivir. El objetivo es mantener nuestra nube segura, protegida y altamente disponible".

Actualización de Netflix

"Todo el software tiene un ciclo de vida y llegó el momento de desarrollar las ideas centrales de Simian Army para satisfacer las necesidades cambiantes del entorno de Netflix. El primer paso más obvio fue separar los servicios para que pudieran evolucionar de forma independiente. Al separarlos, también permitió que cada uno utilizara diferentes tecnologías y modelos de implementación, por ejemplo, integrar la funcionalidad de Conformity Monkey directamente en Spinnaker proporciona a los equipos comentarios en la misma interfaz de usuario que realizan las implementaciones, lo que aumenta la visibilidad de las violaciones y permite la capacidad de mostrar acciones correctivas".
  • Chaos Monkey ahora es standalone
  • Janitor Monkey ha sido reemplazado por Swabbie
  • Conformity Monkey y los servicios de auditoria se han movido a Spinnaker

domingo, 15 de diciembre de 2019

¿Existe un mapa de metodologías y métodos?

Juan Palacio de Scrum Manager creó un mapa de metodologías que me parece interesantísimo y quiero compartir en este post, pone de relieve las dimensiones que son clave para entender las diferentes formas de afrontar un proyecto.

Desde los 80 se han desarrollado tantos modelos de procesos, marcos y prácticas de trabajo para mejorar la calidad y eficiencia en los proyectos de software, que resulta útil trascender las etiquetas y llegar a la base de los principios que subyacen, y las estrategias con las que los desarrollan; de forma que usando como coordenadas tres conceptos: “desarrollo, trabajo y conocimiento”, y dos modelos de gestión: “predictiva y evolutiva” se despeja y simplifica el aparente laberinto de modelos de procesos, marcos o prácticas de trabajo a los que nos referimos: CMM-SW, CMMI, PMBOK, DSDM, Crystal, ISO 15504, RUP, XP, Scrum, ITIL, ASD, PRINCE 2, Lean, Kanban, TDD, etc..

Las diferentes prácticas y metodologías responden a combinaciones de tres conceptos y dos patrones de gestión de proyectos.
Diagrama de conceptos de la gestión de proyectos - cortesía de Scrum Manager
Conceptos

1.- Desarrollo

Completo: La descripción de lo que se desea obtener está disponible al inicio del proyecto, es completa y detallada, sirve de base para estimar el plan del proyecto: tareas, recursos y agenda de trabajo. Durante la ejecución se gestiona su cumplimiento.

Incremental: La descripción de lo que se desea obtener no está disponible de forma completa y detallada al inicio: se complementa y evoluciona en paralelo al desarrollo, que genera el resultado de forma incremental y que se puede gestionar con dos tácticas diferentes:
  • Desarrollo incremental continuo: Empleando técnicas para lograr un flujo continuo de desarrollo de las funcionalidades o partes del producto, que se entregan de forma continua al cliente.
  • Desarrollo incremental iterativo: Empleando técnicas de tiempo prefijado o timeboxing para mantener la producción de incrementos del producto de forma cíclica y continua. Este es el marco de producción empleado al aplicar el marco estándar de Scrum, que define como sprint a cada iteración de desarrollo, al final de la cual se produce un incremento del producto.
2.- Trabajo

Secuencial (cascada): Divide el trabajo en fases, que comienzan al terminar la anterior. El ejemplo más habitual es el ciclo de cascada definido en Ingeniería del software con las fases de requisitos, análisis, diseño, codificación, pruebas e implementación.

Concurrente: Solapa en el tiempo las diferentes fases. Siguiendo con el ejemplo de ingeniería de software, la definición de requisitos, el análisis, la codificación y el despliegue del resultado se realiza y revisa de forma simultánea y continua.

3.- Conocimiento

¿Dónde se encuentra el principal conocimiento empleado, en la correcta ejecución del proceso o en el saber hacer de la persona que lo realiza?

Producción basada en procesos: El conocimiento o know-how, responsable de la calidad del resultado se encuentra en mayor medida en los procesos y la tecnología empleada: “La calidad del resultado depende de la calidad de los procesos empleados“.

Producción basada en personas: El conocimiento o know-how responsable de la calidad del resultado se encuentra en mayor medida en el “saber hacer” tácito de las personas que lo construyen.

Patrones de gestión del proyecto

Gestión predictiva

Modelo de gestión cuyo objetivo es ofrecer resultados predecibles: desarrollo del producto previsto, en el tiempo previsto, e invirtiendo los recursos previstos. Emplea una estrategia de desarrollo completo con prácticas de planificación tradicional. Los principales referentes en el desarrollo de conocimiento para este tipo de gestión son PMI e IPMA y los modelos de procesos CMMI, ISO 15504, SPICE, entre otros, que emplean ingeniería secuencial y producción basada en procesos.

Gestión evolutiva

Modelo de gestión cuyo objetivo es entregar lo antes posible un Mínimo Producto Viable, e incrementar su valor de forma continua. Emplea una estrategia de solapamiento de las fases de trabajo, y desarrollo incremental, que se puede obtener manteniendo un ritmo de iteraciones breves y cíclicas o un flujo de desarrollo constante. Puede llevarse a cabo con producción basada en procesos (ingeniería concurrente) o con producción basada en personas (Agilidad).

Es importante esta distinción porque sin ella se generan situaciones confusas que llegan a considerar Agilidad a la simple aplicación de las reglas estándar de Scrum (ciclo de incremento iterativo con roles y artefactos definidos), o al simple uso de técnicas de gestión visual Kanban para mantener un flujo continuo de tareas.

Extraído del guía de estudio de Scrum Manager

jueves, 12 de diciembre de 2019

¿SAFe® es más ágil que LeSS?

Por el título podéis imaginaros que me encanta la versión 5.0 de SAFe®... quizá no sea más ágil desde la perspectiva del vainilla Scrum que nos trae LeSS, pero desde luego si lo es desde la perspectiva de Business Agility.

Algunos me habéis oído decir que, aunque me encanta SAFe, llevo LeSS en mi corazón. Y lo que pasa es que para la realidad de las transformaciones ágiles que acompaño, LeSS es un marco que requiere una madurez a la que aún no ha llegado ninguna de esas compañías. En cambio SAFe propone un marco más complejo con muchas prácticas que resulta en el mejor punto de partida para las compañías tradicionales.
LeSS Overview Diagram

En la imagen de la izquierda podemos ver la razón por la que LeSS es un marco muy maduro: este se basa en 6 grupos de valores y principios, que pudiéramos denominar competencias, que envuelven a un conjunto de prácticas muy livianas. El mensaje por ende es que si entendemos e interiorizamos sus principios, podemos utilizar el modelado sistémico para diseñar prácticas nuevas, o adaptar prácticas existentes, a nuestras propia forma de ser y encontrar nuestra propia forma ágil de trabajar.

Con la versión 5.0 SAFe introduce el Overview en el que pone de relieve las 7 competencias que ha de desarrollar una empresa que quiera adquirir la habilidad de Business Agility. Recordemos que "Business Agility representa la capacidad de una organización para adaptarse rápidamente a los cambios del mercado, tanto interna como externamente, respondiendo de forma rápida y flexible a las demandas de los clientes". Con Business Agility nos alejamos del software y pensamos de manera más amplia en la construcción de soluciones de negocio, incluyan software o no.

Y lo interesante es que este Overview nos lleva a competencias que se adquieren con valores, principios y también con algunas prácticas, alejándose así de un Big Picture preeminentemente de prácticas y procesos... y eso acerca SAFe a LeSS en términos de Agilidad.
El nuevo Overview trata sobre las 7 competencias y precede al Big Picture con sus prácticas y procesos
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

domingo, 8 de diciembre de 2019

¿Cómo desde el liderazgo podemos ayudar a un equipo a ser de alto rendimiento?

Patrick Leoncioni en su libro "Las cinco disfunciones de un equipo" nos muestra los puntos críticos que un equipo ha de superar para convertirse en un equipo de alto rendimiento. En el artículo "¿Qué impide a un equipo ser de alto rendimiento?" de Aprendiendo Agile lo resumí.

Desde el punto de vista del liderazgo ¿cómo podemos ayudar a un equipo a superar estas disfunciones?

En primer lugar, el comportamiento del líder tiene que ser acorde al comportamiento que se espera del equipo, ha de liderar desde el ejemplo. A medida que los lideres escalan en la jerarquía, los empleados suelen cambiar su comportamiento hacía ellos, dejan de ser auténticos y de expresar el mejor pensamiento. Para no quedar aislados, los líderes deben de crear un entorno de confianza para que sus empleados y equipos puedan equivocarse, crecer y mejorar.

Las cinco disfunciones de
un equipo de Leoncioni
En segundo lugar, se pueden realizar actividades que ayuden a acelerar el cambio. Casi toda la información que muestro a continuación está extraída del libro de Patrick.

La primera de las disfunciones era la falta de confianza. Aquí lo que un líder puede hacer para empezar a crear un ambiente de confianza, y tal y como la entiende Patrick consiste en mostrar sus vulnerabilidades de manera genuina. Es muy importante que las vulnerabilidades que se enseñen sean reales ya que, de lo contrario, si el equipo entiende que se le ha engañado, habremos perdido su confianza como líderes.

Por otro lado, si algún miembro del equipo muestra alguna vulnerabilidad es imprescindible arroparle con su vulnerabilidad y mostrar que ésta no penaliza a quien la mostró, sino que ayuda a las interacciones que podamos tener.

Las herramientas que nos pueden ayudar en esta disfunción son aquellas que consigan que las personas se conozcan más, se sientan más cercanas unas a otras o se sientan valoradas. Algunas de las dinámicas que se podrían utilizar:
  • Historias personales (recomendadas por Patrick): Cada persona contestará a un conjunto de preguntas personales poco delicadas, por ejemplo: ¿Cuántos hijos tienes?, ¿cuáles son tus aficiones?, etc.
  • Mapas personales: Cada persona dibuja su mapa personal. Después en parejas se muestran los mapas personales y se hacen preguntas hasta entenderlos. Por último, cada persona presenta a su compañero partiendo del mapa personal, pero contando una historia.
  • Eficacia de equipo (recomendada por Patrick): Cada persona del equipo indica cuál es el mayor aporte de cada uno de sus compañeros al equipo.
La segunda disfunción es el temor al conflicto. El líder debe permitir que exista un conflicto sano entre los miembros del equipo. No debe interrumpir los debates por miedo a perjudicar el ambiente. Los líderes deben transmitir tranquilidad cuando aflora un conflicto y permitir que la solución ocurra naturalmente.

El objetivo es conseguir un conflicto sano donde cada miembro pueda expresar lo que considere necesario sin que por ello nadie se vaya con sentimientos desagradables. Así es posible realizar diferentes acciones dependiendo de la naturaleza del conflicto:
  • Los conflictos suelen tener una causa raíz, así, uno de los miembros del equipo o el líder puede utilizar la herramienta de coaching de los 5 porqués. Esto hará pensar al equipo en los motivos detonantes del conflicto y les permitirá tomar la mejor acción posible para resolverlo..
  • Comunicación asertiva, esta otra herramienta conseguirá que nos comuniquemos en base a datos objetivos y sentimientos que afecte exclusivamente a la persona que transmite la preocupación o el problema y se evitan ataques personales
La tercera disfunción es la falta de compromiso. El consenso y la necesidad de tener mucha información para la toma de decisiones son el mayor de los obstáculos para que un equipo pueda llegar a compromisos en tiempos razonables. El líder debe forzar al equipo a tomar decisiones tratando de evitar estas dos situaciones.

Algunas de las herramientas que tenemos a nuestro alcance para evitar estos problemas pueden ser:
  • Toma de decisiones por consentimiento. Esta técnica se utiliza en Sociocracia y consiste, brevemente, en presentar el problema y la solución que está encima de la mesa. Después el equipo vota si consiente o no esta solución. Si algún miembro no consiente debe expresar su preocupación y cómo se podría modificar la solución para que se sintiera cómodo. Una vez incluida la modificación se vuelve a votar. El proceso se repite hasta que se encuentre una solución suficientemente buena para que todos los miembros consientan.
  • Fechas límite (recomendado por Patrick). Los equipos deben poner fechas límite a las acciones. Si hubiera acciones intermedias, éstas también deben tener fechas límite. Con esta herramienta se busca tener un seguimiento de los resultados de las acciones y así poder realizar correcciones si fuera necesario.
  • Terapia de exposición a bajo riesgo (recomendado por Patrick). Un equipo debe poder tomar decisiones con falta de información. Esto puede hacerles sentir inseguros. Por ello, una manera de que vayan viendo que no son malos tomando este tipo de decisiones es hacerlo con situaciones donde en caso de fallar el impacto sea mínimo.
La cuarta disfunción es la evitación de responsabilidades. El líder debe favorecer que unos pidan responsabilidad a otros y evitar ser él la única fuente de responsabilidad. Si se convierte en la única fuente de responsabilidad las personas no dicen nada a los compañeros, porque para eso está el líder.

Las herramientas que nos presenta Patrick seguramente nos suenen a aquellos líderes que conozcamos Scrum:
  • Publicación de metas y estándares: recomienda que se muestre públicamente lo que el equipo necesita conseguir (en Scrum sería el objetivo del sprint) y cómo ha de comportarse cada uno para tener éxito (esto se puede asemejar a la asignación que el propio equipo hace de tareas)
  • Revisiones sencillas y regulares del avance: Los miembros del equipo deben comunicar regularmente entre sí sobre cómo están trabajando con sus compañeros hacia las metas establecidas (esto podría ser una variación de la daily en busca de un equipo de alto rendimiento).
  • Recompensas de equipo: creo que esto no requiere mucha explicación. Si las recompensas son individuales cada persona va a trabajar de manera individual y no le va a suponer ningún problema que otro compañero no trabaje adecuadamente. Sin embargo, si las recompensas son al equipo, no sólo vas a trabajar de manera más colaborativa, sino esto resalta que el mal trabajo de un compañero te afecta directamente y por tanto es posible que acabes exigiéndole responsabilidades. Otra cuestión aparte es si las recompensas son una herramienta adecuada o no, pueden ser un arma de doble filo.
La última disfunción es la falta de atención a resultados. A mi personalmente la actitud que ha de tener un líder para superar esta disfunción me resulta especialmente complicada. Según Patrick el líder debe valorar únicamente los resultados, de lo contrario da permisos a los miembros del equipo a hacer lo mismo.

Sin embargo, personalmente, entendiendo que los resultados son básicos y ese debe ser el objetivo del equipo, valoro mucho la mejora del equipo en busca de ese objetivo. Creo más en una cultura de mejora continua que de marcar el éxito únicamente por los resultados.

Patrick recomienda hacer públicos los resultados para tratar de que el equipo empuje en dicha dirección.

Desde la Agilidad y con nuestra cultura de transparencia entiendo que esto está resuelto. Sin embargo, si podemos ayudar no siendo flexibles en la consecución o no de los objetivos. Por ejemplo, en Scrum tenemos un conjunto de elementos que se deben obtener al final del sprint. Para considerar que esos elementos están conseguidos disponemos de una herramienta denominada "Definición de hecho" compuesta por un conjunto de condiciones objetivas. Por tanto, si somos rigurosos y poco flexibles a la hora de determinar si se cumple la "Definición de hecho" podremos ayudar al equipo a enfocarse a los resultados.

Un saludo, Alexander y Rubén :-)

domingo, 1 de diciembre de 2019

¿Cómo escribir historias técnicas de deuda técnica?

La deuda técnica ralentiza la productividad y genera
productos de escasa calidad - cortesía de Pixabay
Un producto no es un producto de calidad si no da solución a las necesidades del usuario o cliente, eso representa su valor, y tampoco es de calidad si la infraestructura tecnológica que lo soporta no es excelente, eso lo representa su integridad tecnológica.

Centrarse únicamente en construir funcionalidades de negocio, como las historias de usuario, puede funcionar a corto plazo, e incluso proporcionar una gratificación inmediata al mercado, pero a medio plazo la velocidad de entrega se ralentizará irremediablemente por una carga aplastante de la deuda técnica que se va adquiriendo.

Es por ello que para garantizar que se realicen las inversiones adecuadas dentro del presupuesto para el producto o proyecto, es necesario incluir historias técnicas de resolución de deuda técnica en la pila del producto.

A menudo el Propietario de Producto no comprende la necesidad y los beneficios de reducir la deuda técnica y no considera historias técnicas para ello en la pila del producto. Recordemos que el Propietario del Producto es parte del equipo ágil y este debe de asumir la responsabilidad de reducir la deuda técnica y analizar esta con los miembros del equipo de desarrollo y trabajar juntos para darle la prioridad adecuada en la pila del producto: su dolor es el dolor del equipo y viceversa.

Los desarrolladores conocen la deuda técnica y son conscientes de la importancia de resolver este problema desde el punto de vista técnico. Hay un técnica provocativa que ideó un equipo de desarrollo para ayudar al Propietario del Producto a tener en cuenta la deuda técnica; utiliza el siguiente el patrón para escribir historias técnicas de esta índole:

If we don't do this [action required]
It will cause this impact [loss of service]
And that will result in [reputational damage] and/or [monetary impact]

Si no hacemos [acción requerida]
Causará el impacto [pérdida de servicio]
Lo que resultará en [daño a la reputación] y/o [impacto monetario]

un ejemplo podría ser:
Si no hacemos por resolver la cobertura de pruebas
Causará el impacto de un incremento mensual del 10% en el número de incidencias
Lo que resultará en una reducción de productividad mensual acumulada de aproximadamente 5 horas

Los equipos viven la realidad tecnológica (herramientas, hardware, entornos, etc.) día a día, ellos saben qué les cuesta en esfuerzo o en tiempo cada vez que se encuentran con un elemento con deuda técnica. Es su responsabilidad analizarla, estimarla y hacerla visible de forma argumentada al Propietario del Producto y a otros interesados.

Hacer partícipe al cliente e interesados tiene dos beneficios; hacer que estos entiendan los problemas del software, y que participen en la solución apoyando la resolución de deuda técnica o proporcionando una perspectiva de negocio que puede cambiar las prioridades.

Gracias Sara por compartir este patrón :-)

miércoles, 27 de noviembre de 2019

¿Cómo tiñe la PI Planning la intención de realidad?

PI Planning en el Big Picture de SAFe®
Una de las frases de SAFe® y que se refiere a la PI Planning dice así:

No hay magia en SAFe...
excepto quizá en la PI Planning

Veamos pues cual es la magia de este evento core del marco.

Recordando los inputs y outputs de la PI Planning tenemos entre otros como input el program backlog, la pila de features que Product Management ha preparado, y como outputs los objetivos del equipo, las pilas iniciales de los equipos y el program board con las features colocadas en la iteración en la que el equipo estima terminarlas y las interdependencias detectadas resueltas.


La primera clave está en comprender que el program backlog representa la intención de Product Management y negocio, representa aquellas cosas que desde el punto de vista de negocio son las que aportan el máximo valor y están limitadas en tamaño a la capacidad del tren, por tanto representan las features deseables para construir y obtener al final de PI.

Cuando en PI Planning los equipos toman esas features, las desglosan en historias de usuario, resuelven dependencias que emerjen entre si y con equipos externos, estos están "cocinando" la intención para obtener factibilidad. Esa es la magia de la PI Planning, utiliza la complejidad del pensamiento focalizado de todos los individuos del tren como inteligencia colectiva para obtener un plan factible tiñendo así la intención, representada en el program backlog, de realidad.


Finalizada la PI Planning las pilas iniciales de los equipos y sus objetivos del PI no van a cuadrar al 100% con la intención, con las features del backlog, quizá un 80%... Habrá cosas que no es posible construir, puede que por razones tecnológicas o por capacidad para absorber dependencias, para otras habrán surgido ideas y soluciones mejores... lo importante es entender que la PI Planning hace que los equipos crean un plan de partida en el que crea cada individuo, un plan que sea factible y por tanto garantice el éxito.

Program backlog y program board y su maraña de dependencias
En la imagen de la derecha podemos ver un program backlog, el rotafolios a la izquierda, mostrando en azul las features que ha sido posible planificar; las verdes son aquellas que no se han podido incluir por alguna razón. En el tablero de la derecha se puede ver el program board con todas las dependencias identificadas y resueltas, están representadas por las cuerdas rojas. ¿Qué precio tiene un plan trimestral para 8 equipos que tiene todos los números de ser exitoso? ¿Que precio tiene el program board en el que se nos muestra las dependencias resueltas para ese trimestre? No habrá retrasos ni bloqueos, porque el plan lo han cocinado, cada uno desde su perspectiva, todos aquellos individuos que lo van a ejecutar.

Resaltar que el compromiso se establece con los objetivos que los propios equipos han establecido, y un objetivo es una cosa flexible. Un objetivo se puede alcanzar con un grupo de historias de usuario u con otro, con más o con menos, lo importante es que al final de PI el cliente reciba la mejor solución posible a su necesidad. El compromiso por objetivos nos hace ágiles, hace que las pilas de los equipos sean flexibles al igual que una pila de producto de un equipo de Scrum.

Con la PI Planning los equipos son dueños de sus planes y esa responsabilidad es uno de los beneficios más significativos del evento, cada individuo siente su responsabilidad en el resultado del tren, creándose así un ambiente de trabajo mejor en el que se impulsa la colaboración. Durante la PI Planning ocurre otro beneficio casi mágico, todos hacen hincapié en el equilibrio entre el trabajo y la vida, asegurándose de no planificar excediendo la capacidad y obtener un plan de partida excepcional.
Aunque no haya sido posible incluir todas las features el voto de confianza muestra a Business Owners entusiasmados
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

lunes, 25 de noviembre de 2019

¿Cuáles son las novedades de la versión 5.0 de SAFe®?

En octubre Scaled Agile anunció y puso a disposición del público su actualización a la versión 5.0. Se trata de una actualización significativa del marco que proporciona orientación sobre las siete competencias básicas que ayudan a una organización a convertirse en una empresa Lean y alcanzar la Agilidad Empresarial (Business Agility), el paradigma empresarial para las compañías que van a florecer en el despliegue de la quinta revolución tecnológica.

La novedades que nos trae esta nueva versión se pueden ver resaltadas en la imagen al final post y son las siguientes:
  • Business Agility: Agilidad Empresarial, el nuevo marco incluye la capacidad para poder competir y prosperar en la era digital respondiendo rápidamente a los cambios del mercado y a las oportunidades emergentes con soluciones empresariales innovadoras.
  • Measure and Grow: se focaliza en cómo medir el estado de Business Agility y cómo acelerar el crecimiento para mejorar los resultados económicos generales.
  • Organizational Agility: esta nueva competencia de Agilidad organizacional describe cómo los líderes Lean thinkers y los equipos ágiles optimizan sus procesos de negocio, desarrollan estrategias con compromisos claros y adaptan rápidamente la organización para capitalizar nuevas oportunidades.
  • Enterprise Solution Delivery: antes Business Solutions and Lean Systems Engineering; esta competencia describe cómo aplicar los principios y prácticas Lean-Agile a la especificación, desarrollo, implementación, operación y evolución de las aplicaciones de software, redes y sistemas ciberfísicos más grandes y sofisticados del mundo.
  • Agile Product Delivery: antes DevOps and Release on Demand; se ha convertido en la competencia Agile Product Delivery, que es un enfoque centrado en el cliente para definir, construir y liberar en un flujo continuo productos y servicios de valor para clientes y usuarios.
  • Continuous Learning Culture: esta nueva competencia de cultura de aprendizaje continuo describe un conjunto de valores y prácticas que alientan a las personas, y a la empresa en su conjunto, a aumentar continuamente el conocimiento, la competencia, el rendimiento y la innovación.
  • Agile Teams beyond Technology: se ha reestructurado esta competencia de Team and Technical Agility que describe las habilidades críticas, los principios y prácticas Lean-Agile que los equipos ágiles y los equipos de equipos ágiles (ARTs) utilizan para crear soluciones de alta calidad para sus clientes.
  • Portfolio Vision: la competencia de Lean Portfolio Management se ha reescrito como una capacidad organizada para alinear la estrategia con la ejecución, cumplir con los compromisos existentes de manera confiable y permitir una mejor innovación.
  • Customer Centricity: el nuevo marco incluye Design Thinking para centrarse en sus herramientas y prácticas para poner al cliente en el centro.
  • Essential Level: los niveles de equipo y programa (ART) se han unido en uno sólo que corresponde a la configuración essential.
  • Continuous Delivery Clarity: se muestra más claridad en el flujo de exploración continua, integración continua y despliegue continuo en la ejecución de las iteraciones.
Las novedades de la versión 5.0 sobre el Big Picture de SAFe®
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.