• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

herramientas

Cómo formar equipos ágiles trabajando con Scrum

Conformar equipos ágiles cuando estamos trabajando con Scrum es un reto. ¿Cómo decidimos quien debe ir en cada equipo? ¿De que manera podemos extender Scrum a la organización y mantener la agilidad?

Hace unas semanas durante una charla para OnTech Innovation una de las asistentes me lanzaba esta pregunta en Twitter.

Jeronimo, por favor me indicas si existen técnicas de división de equipos, cuando ya se trabaja Scrum y Kanban? Escuchamos sobre la técnica (split and seed – split and grow) pero no encontramos casi información del tema. Gracias

— Monica Martinez H (@monicaromartine) September 26, 2019

Equipos auto-organizados. No equipos donde todo el mundo haga de todo.

Cuando usamos Scrum para lidiar con problemas complejos, podemos caer en dos tentaciones diametralmente opuestas: Distribuir el trabajo en trozos de acuerdo a los equipos que tenemos actualmente (Fron-end, Back-End, Data, etc…) e ir haciendo Sprints en el que el trabajo de unos recae en otros.

Otra opción es tener equipos donde todo el mundo haga de todo. En realidad, en Scrum no es ni lo primero, ni lo segundo, ni nada en medio de los dos.

Cuando Scrum fue descrito por primera vez en el New New Product Development Game, los investigadores Takeuchi, Nonaka y Ken-Ichi Mai observaron que los equipos de alto rendimiento que estudiaban tenían precisamente todos los perfiles que necesitaban para entregar algo terminado, funcionando y que el cliente valorara en un periodo muy corto de tiempo.

¿Como podemos conseguir identificar cuales son las skills necesarias para entregar un incremento de valor, terminado, en 30 días o menos? Es más fácil de lo que creemos. Sólo hay que preguntarle al equipo que trabaja en ese producto.

A pesar de que pueda parecer sorprendente, las personas que desarrollan un producto son las que más saben cómo organizarse para sacarlo adelante.

Para aquellos que temen que los techies se centren sólo en su área, esa es precisamente una de las problemáticas que resuelve Scrum.

Scrum proporciona los límites, la transparencia y la capacidad de inspección y adaptación para asegurar que la auto-organización funciona. Cuando un equipo de desarrollo tiene que entregar un incremento terminado en 30 días o menos, pone el foco en qué necesita para que eso ocurra.

Hace un año y medio, escribí un artículo sobre las diferencias entre distintos tipos de diseño de equipos.

En realidad nada ha cambiado mucho desde entonces, más allá de que sigue siendo difícil entender que para cambiar nuestra forma de entregar valor a los clientes, tenemos que cambiar la forma en que organizamos el trabajo.

Split and Seed y Seed and Grow.

Cuando nos planteamos escalar Scrum a distintos equipos de nuestra organización, se suele acudir a los métodos por los que Mónica pregunta en su Tweet: Split and Seed y Seed and Grow.

Seed and grow model in Scrum

Con este método, se toma un equipo pequeño que establece un núcleo o un core y se divide.

En el primer caso (Split and Seed), una vez que el equipo está establecido, se divide en dos equipos que se utilizan como base para hacer crecer otros equipos, a modo de mitosis de equipo.

En el segundo caso (Seed and Grow), se toman algunas personas de un equipo que ya está funcionando y se utilizan como semilla para hacer crecer otro equipo, a modo de esqueje.

Este método plantea dos problemas: ¿Quien decide como se mueven los miembros de un equipo a otro? ¿El Agile Coach, el Scrum Master, el Propio Equipo?.

El segundo problema es que podemos partir de un equipo de alto rendimiento para terminar con dos equipos mediocres o que no funcionen en absoluto.

El método del becario

Una alternativa, que Jeff Sutherland llama “El modelo del amigo del equipo”, es introducir a un nuevo miembro del equipo de desarrollo, que se encarga de empaparse de la cultura, forma de trabajo y experiencia del mismo con el objetivo de graduarse y formar su propio equipo más adelante.

Internship grow model in Scrum

Un equipo de desarrollo identifica uno o varios compañeros, que trabajaran con ellos durante un periodo de 4 a 6 sprints.

Su papel durante este tiempo será aprender y participar en las actividades del equipo sabiendo que su permanencia tiene una fecha de caducidad en el tiempo. Cuando pase ese tiempo, serán los encargados de ser el pilar fundador de un nuevo equipo.

En ocasiones a estos equipos que admiten nuevos miembros se les llama “Equipos de bienvenida” o “Training Teams” y tienen una alta cultura de colaboración que puede ser expandida a nuevos miembros.

La decisión del número de Sprints que permanecen en el equipo es una decisión personal. Cuando están listos, pueden migrar al nuevo equipo.

La ventaja de este método es que asegura que no se rompe un equipo de alto rendimiento ya existente, tiene un impacto menor en el delivery actual y permite un crecimiento de acuerdo a las capacidades de contratación de la organización. Sin embargo, es un método extremadamente lento para aquellas organizaciones que quieren escalar Scrum rápidamente.

El observador

Otra opción, basada en el modelo anterior, es incorporar nuevos miembros como observadores. La principal diferencia es que mientras en el método del becario participan activamente de las labores, entrega y eventos del equipo, en este modelo sólamente actúan como observadores.

Observer Model

La principal ventaja de esta última opción es que la incorporación de un observador es mínimamente disruptiva.

Pueden continuar con se trabajo como hasta ahora sin tener que centrarse en enseñar a un nuevo miembro del equipo.

A pesar de todo, el efecto del observador puede ser disruptivo para equipos existentes. A nadie le gusta sentirse observado.

Puede tener consecuencias inesperadas cuando los nuevos miembros crean sus equipos e implementan lo que creen que han observado.

Lo más importante: Medir Siempre

Durante todo el proceso de escalado a equipos con Scrum, es importante medir el estado y la salud del equipo. El health check de Henrik Knieberg en Spotify puede ser un buen comienzo. La importancia de medir el estado de los equipos radica en que una manzana podrida en una cesta de fruta acabará rápidamente con todos los esfuerzos por mantenerla en buen estado.

Lamentablemente el crecimiento rápido en pocas ocasiones tiene buenos resultados. Si además se están adoptando prácticas que requieren de un alto grado de auto-organización, como Scrum, es necesario dejar que los equipos y la organización maduren a su propia velocidad.

Diagnóstico de Arquitectura de Software Basado en Experto

 La Arquitectura de Software es central en la estrategia de las organizaciones que basan su negocio en el uso intensivo de la tecnología. Sus atributos de desplegabilidad y testabilidad son fundamentales para una organización que se plantee la evolución hacia DevOps, son el foco de un diagnóstico de arquitectura de software. Por otro lado, el State of DevOps Report  2018 señala como fundamental la adaptación de la arquitectura para estandarizarla y ajustarla a las necesidades de negocio. 

 Cuales son los elementos de la arquitectura de software a mejorar y cómo priorizar los cambios es el objeto fundamental del Diagnóstico de Arquitectura de Software. En publicaciones anteriores hablé sobre el valor de arquitectura y su diagnóstico, así como la metodología basada en escenarios de uso. En esta entrada te introduciré al diagnóstico basado en experto. 

Casos de Aplicación del Diagnóstico basado en Experto

En el anterior artículo sobre diagnóstico con escenarios de uso, vimos como retornaba un gran valor a la organización en forma de activos tangibles y cambios culturales. Como inconveniente, tiene un coste elevado en términos de tiempo y dedicación de personas claves para la organización. Esto hace que la aproximación basada en escenarios no siempre sea la mejor. 

En algunos contextos, cultura de empresa o situaciones especiales, se prefiere limitar el número de personas implicadas sobre el proceso. Otro caso, es que se desee obtener una visión rápida e independiente sobre las características fundamentales de la arquitectura. En estos casos, una aproximación basada en el trabajo de un experto externo puede resultar más conveniente en su relación conste-resultados. Algunos ejemplos que me he encontrado en mi carrera profesional son: 

  •     La evaluación de los activos IT de una compañía para su posible adquisición o como socios de negocio (ej, Due Diligence).
  •     Procesos de acreditación de cumplimiento de estándares o normativas reguladoras (ej, RGPD, implementación de receta electrónica).
  •     Reorganización del área tecnológica de la compañía (Ley de Conway). 
  •     Valoración del estado para un nuevo ejecutivo a cargo del área de IT. 

En general, las metodologías basadas en escenario son ideales para conducir un diagnóstico interno. La incorporación de de un facilitador externo, ayuda a consolidar esta práctica en la organización. Por el contrario, si lo que se necesita es un resultado rápido realizado por un asesor externo, la aproximación basada en experto parece más adecuada.

Herrameintas para el diagnóstico de arquitecturas de software

Proceso de Diagnóstico 

El asesor realiza el diagnóstico recabando la información disponible por la organización sobre la arquitectura y con reuniones limitadas a un conjunto muy reducido de expertos en negocio y tecnología. El propio patrocinador del estudio y un arquitecto suele ser suficiente.

A diferencia de la aproximación colaborativa planteada por la estrategia de escenarios, los atributos de la arquitectura no emergen como consecuencia del debate, sino que son identificados por el asesor y confirmados por la organización. En este sentido, distintos trabajos ponen de manifiesto que es más productivo, cuando se dispone de un stakeholder con dedicación limitada, afrontar el proceso con una dinámica de refinamiento. 

En este proceso, el asesor presenta su visión sobre los requerimientos funcionales y atributos cualitativos de la arquitectura para que el representante de la organización confirme su apreciación o plantee correcciones. Este proceso, suele ofrecer mejores resultados que la alternativa por la que el propio stakeholder los elabora. 

No obstante, el analista no puede limitarse a recabar la opinión de los representantes de la organización. En el diagnóstico experto es fundamental que el asesor contraste esta información con el análisis de los artefactos reales del sistema: código funcional y test, registro de incidencias, plataforma de despliegue, operaciones en producción, métricas, etc. Ésta es la auténtica verdad sobre el sistema, no la idealizada por sus creadores. 

El código no miente. Ahí está la verdad sobre la arquitectura

 En este contexto es especialmente importante la figura del promotor del diagnóstico, quien debe plantear un objetivo claro para el análisis,  con preguntas/dudas específicas a las que dar respuesta. Además, debe disponer de suficiente nivel ejecutivo en la organización para garantizar la disponibilidad de los expertos y el acceso a los recursos del sistema a evaluar. 

Por su parte, el analista debe disponer de una sólida experiencia en la tecnología y el negocio de la organización para poder llevar a cabo su labor de forma, principalmente, autónoma. La confianza del promotor en su nivel de conocimientos es clave para afrontar el proceso y que las conclusiones sean asumidas y extendidas a toda la organización.

Iteraciones y Alcance:

El proceso se basa en una o varias iteraciones en las que el asesor genera y refina con los expertos asignado. Su visión del contexto del negocio, la vista de la arquitectura, las decisiones arquitectónicas claves para el negocio y la realidad de su implementación. Todo ello, lleva a una enumeración de riesgos y fortalezas que constituirán la base del informe final para el patrocinador del estudio. 

La ausencia de una documentación mínima razonable, previa al inicio de los trabajos, puede desviar el foco. Hacer que la dedicación se desvíe hacia su elaboración, limitando las conclusiones ejecutivas del trabajo. En un primer contacto, debemos evaluar esta situación y revisar el alcance del proyecto con el promotor. Debemos asegurar que podemos afrontar el objetivo principal o bien, deben realizarse labores previas de preparación. 

El diagnóstico basado en conocimiento experto tiene un alcance más limitado que el elaborado con la técnica de escenarios de uso. Debido a la falta de contexto cualificado sobre el negocio y el sistema, las conclusiones están basadas en el juicio del asesor. Por ello, el foco debe reducirse a los grandes aspectos estructurales de la arquitectura de software. 

Así, el informe final puede resultar más superficial que los generados mediante trabajo colaborativo. No obstante, en contextos en los que se desea obtener un referencia independiente, cualificada y rápida para tomar una decisión ejecutiva, esta aproximación puede resultar la más efectiva. 

Conclusiones:

En esta ocasión, te he presentado el diagnóstico de Arquitectura de Software basado en experto externo, como contraste a la metodología basadas en Escenarios de Uso, ventajas e inconvenientes. Hemos visto el papel que juega el patrocinador del diagnóstico y la calificación del experto. También, hemos tratado la importancia de contrastar la visión de los desarrolladores con la realidad reflejada en el código. 

En mi próxima entrada sobre Arquitectura de Software, quiero analizar algunas herramientas para modelar las distintas visiones de la arquitectura. Como dice mi compañera Laura Jiménez, “los desarrolladores estáis todo el día dibujando cajitas”. Bueno, pues veremos esas “cajitas”. 

¿Qué es la Facilitación Gráfica?

Esto va mas allá de la visión que tienen muchas personas de que se trata de hacer dibujitos con notas para toda la sala o grupo. Vamos a romper algunos mitos como pasa con Scrum o Kanban, en torno a esto de la facilitación gráfica.

Aunque mi base es artística y te pueda explicar algunos temas con mayor profundidad, no es necesario tener conocimientos de este tipo para utilizarlo. No necesitas saber dibujar bien para aprender facilitación gráfica. Si sabes dibujar círculos, cuadrados y flechas, tienes todo lo que necesitas.

Una buena base

Su mismo nombre te explica lo que es. Una ayuda visual para entender o comprender un concepto más allá de una definición. Para el ser humano es otra herramienta más a nuestra disposición para mejorar la comunicación entre grupos de personas.

Hace unos meses te contaba un punto interesante sobre los radiadores de información y lo necesarios que son en muchos sitios en nuestro día a día. La facilitación gráfica es como se llama al proceso de crearlos. Aunque está asociado más al facilitador que lo esquematiza en directo en una sesión o evento, hay mas roles que la usan.

Una buena base sobre ello puede conseguir que seamos capaces de comunicaros con mayor fluidez y menos esfuerzo.

En lo que te puede ayudar

Una de las preguntas más repetidas es ¿Para qué sirve?. Seguro que has asistido a algún evento o una reunión de un grupo de gente en el que alguien facilitaba. Puedes imaginarte la misma situación sin esa persona y hacerte algunas preguntas:

  • ¿Habríamos entendido todos lo mismo sin hacerlo visible?
  • ¿Habríamos estado pendientes de lo que se hacía en todo momento?
  • ¿Habríamos debatido acerca de a que nos referimos con uno u otro concepto?

Cuando hay facilitación gráfica, todo esto ocurre en mayor o menor medida. Además de la ayuda a la memoria que nos proporciona algo visual.

referencias gráficas - facilitación gráfica

Aprender haciendo…

Me alegra muchísimo anunciar que abrimos puertas a un taller de iniciación para los interesados en facilitación gráfica. Podrás leer algo más de información sobre el taller en sí en su página y buscar fechas disponibles en nuestro calendario.

Queremos ofrecer formación de calidad, por ello, saldrás del taller con el material básico para facilitar gráficamente y tu propio cuaderno de referencias. También hablaremos de prácticas y herramientas que van a ayudarte a mejorar al ritmo que lo necesites. Y todo va acompañado de ejercicios muy prácticos para afianzar todo lo que vayamos viendo.

Me gustaría animarte contándote, que los primeros en hacer el taller han sido mis compañeros Alberto, Nacho y Jero. Podéis leer parte de su feedback en la página del taller. Hace un par de semanas del taller y si habéis coincidido con ellos en estos días, habréis visto que se lanzan a hacer flipcharts con mucha soltura.

El uso de radiadores de información

Hace unos meses tuve la suerte de poder asistir a un curso de facilitación gráfica con grandes profesionales del sector como son Israel Alcázar, Juliana Betancur y Pablo Tortorella. Un taller en el que se normaliza el uso de los radiadores de información.

En ningún momento te planteas que empresas y equipos no los usen después de experimentar todos sus beneficios en cursos como este.

Hay muchos tipos de radiadores de información, pero los que cumplen su cometido son los que gráficamente permiten que de un vistazo una persona ya tenga información valiosa.

Finalidad tangible

Algo que nos enseñan en primero de Diseño Gráfico y que terminas aprendiendo por la práctica es que no hay una señal sin una finalidad. Si una señal gráfica no tiene una misión que cumplir y es capaz de hacerlo, no sirve para nada más que para meter ruido.

En cualquier sitio al que vayas, fíjate en los iconos. En las puertas de los vagones de metro, las señalización de las calles, los aseos en un centro comercial…etc. Siempre vas a buscar el típico muñequito si quieres ir al baño. Pero a veces ser original cuesta que la experiencia de usuario no sea tan sencilla:

Gráfico aseos

Se que has visto la imagen y luego has pensado que es sencillo de entender. Ahora imagina que es la primera vez que visitas este sitio. No has visto esto hasta que “urgentemente” necesitas llegar al aseo lo más rápido posible. Seguro que no te hace gracia pararte a pensar. Y este ejemplo es de los fáciles.

¿Necesidad?

Esto es lo que debería impulsarnos a crear un radiador de información. Cuando empiezo en algún equipo, siempre quieren tener cuanto antes su tablón de Kanban. Uno en el que poder ir moviendo las tareas que consideran deben verse. Pero no están pensando en su utilidad más allá de hacer visible el trabajo. Por eso es importante trabajar antes con todo el equipo para que entiendan todos sus beneficios.

Trabajando con Post-its - equipo

¿Qué necesita el equipo?¿La empresa requiere recibir información de los equipos? ¿De qué forma? ¿Necesita actualizarse? ¿Cómo o quién actualiza esa información? Son algunas de las preguntas que hay que hacerse antes de lanzarse a convertir la información en algo gráfico.

Radiadores de información a la moda

Siempre que veo tableros o información visual en empresas a las que vamos intento interpretar la información que muestran. Pero en realidad alguien ajeno a la empresa tampoco tiene por qué entender todo lo que muestra.

Cuando aprendes Scrum y lees mucho sobre Historias de Usuario, hay una regla en la que se especifica que el lenguaje en la tarjeta debe ser de negocio y no técnico. Pero esto provoca muchos dolores de cabeza por lo que he visto. Scrum no exige la existencia de Historias de usuario. En consecuencia muchos tableros terminan con Historias de usuario que los técnicos no entienden y subtareas tan técnicas que parecen maleficios al ojo del Product Owner.

Usabilidad ante todo

¿Qué quiero conseguir?¿Que utilidad tiene esto para mi equipo y mi empresa? ¿Quién es el lector de este radiador de información?.Una herramienta que decidimos utilizar para hacer transparentes nuestros logros y dificultades no debe convertirse en una carga de trabajo más. Si es útil, no cuesta mantenerlo.

Si estás pensando añadir radiadores de información en tu día a día:

  • Procura que tenga una finalidad antes de hacerlo.
  • No añadas información en exceso, mantén la facilidad de lectura y comprensión. Usa siempre la regla de menos es más.
  • Empieza con algo básico y ve añadiendo más información si lo requiere.
  • Colócalo en un lugar accesible y fácil de visualizar.
  • No todo tienen que ser iconos (dibujos) utiliza texto si así está más claro.
  • Haz partícipes a las personas que vayan a utilizarlo. De esta forma su mantenimiento y actualización será cosa de todos.

En próximos artículos enseñaré algunos ejemplos de radiadores de información y os contaré algo en lo que estamos trabajando. ¿Os gustaría ver algo en concreto?

 

Taller Retrospectiva, aprendiendo a mejorarlas

Siempre he entendido la retrospectiva como el evento más importante para cualquier equipo que quiera mejorar. En Scrum, todos los eventos que se describen son necesarios, tienen un por qué y un para qué muy definidos. En Lean Kanban ocurre exactamente lo mismo con sus siete cadencias. En cualquier práctica ágil en la que se trabaje por equipos, la retrospectiva sigue siendo el foco central de la evolución de estos.

· Individuos e interacciones sobre procesos y herramientas.
· A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Agile Manifesto

No considero que hacer bien una retrospectiva sea algo fácil. Al fin y al cabo, estamos hablando de personas, de sus capacidades, conocimientos y emociones. En este evento también tratamos las herramientas, los procesos y la calidad, pero me gustaría centrarme en la primera parte.

Aprender practicando

Una de las cosas que tengo más clara desde que trabajo en Jerónimo Palacios & Associates es que la mejor forma de aprender es haciendo. La práctica hace al maestro, pero aunque hayas estudiado mucho sobre algo, hasta que no experimentas con ello, no lo aprendes de verdad. Creo que es una de esas cosas que se aprenden por trabajar en una empresa como esta. Todos nosotros lo tenemos ya muy interiorizado y siempre proponemos hacer más dinámicas todas nuestras formaciones.

La segunda clave que aprendes gracias a como trabajamos en la empresa es saber adaptarse. Creo que nunca había adaptado el contenido de un taller o una conferencia en un tiempo tan corto como lo he podido hacer aquí. Y el taller de retrospectivas fue destacable por ello. Incluso durante el propio taller fuimos adaptando partes.

Existen muchos tipos de retrospectiva: de iteración, de final de proyecto, de escalado de producto…etc. También un sinfín de dinámicas para retrospectivas que pueden hacer que cada una de ellas sea original, diferente, entretenida. Pero una retrospectiva no tiene ese fin, debe ser útil, así que lo primero será plantear un objetivo. ¿Qué quieres conseguir?

Una retrospectiva en tiempo record

Nos propusieron hacer un taller de retrospectivas y nos pareció fantástico. Hasta que nos pusimos a pensar sobre lo que queríamos conseguir. Decidimos llevar la importancia de la práctica a la parte del taller. Para ello necesitábamos que hubiera un número de personas máximo y unos requisitos para el espacio que íbamos a usar. A lo largo de la semana previa, esto cambió tres veces y tuvimos que replantearlo todo para que funcionase como queríamos. Creo que fue lo más difícil de todo, plantear de forma práctica y experimental nuestra idea.

Una vez aclarado, nos quedamos con lo que queríamos que los asistentes se llevaran. Y es una parte muy importante que cuesta mucho aprender de otra manera: Experiencias.

Agenda Path - taller de retrospectivas

Mi compañero tuvo una idea genial así que para poder hacer los grupos decidimos crear una empresa imaginaria y realizar una retrospectiva de empresa. Así nació LA Corporation. Originalidades aparte, Alberto preparó un storytelling brutal. Todos los asistentes se convertían en empleados de la empresa y participaban en esta retrospectiva anual. El objetivo era mejorar las retrospectivas que se hacen en los diferentes equipos de la empresa.

En el taller entraron 36 personas, que era nuestro máximo. Así que organizamos el trabajo por equipos para poder hacerlo más participativo y también más rápido a la hora de seleccionar temas.

Tras preparar equipos de seis, facilitamos una pequeña dinámica para que los miembros del equipo se conocieran un poco e hicieran equipo. La idea principal era que se tratasen una serie de casos concretos por equipo. Cada equipo debía preparar un solo caso de retrospectiva complicada que quisiera que toda la empresa tratara. Para ello debatían y rellenaban una ficha con la propuesta que después votarían entre todos los equipos. Después se compartía para que otros equipos pudieran también dar su visión y aportar sus experiencias.

El resultado del taller

Tras debatir entre todos los asistentes los dos casos y las propuestas de cada equipo, se generaron una serie de conversaciones que abrían un debate tras otro. En el cierre del taller destacamos los “puntos estrella” a la hora de organizar una retrospectiva y resumimos los puntos más importantes:

  • Timebox – controlarlo para conseguir que la experiencia sea efectiva y no se haga pesada.
  • Objetivo – la clave antes de organizar la retrospectiva. Sin un objetivo no es más que una reunión de personas que trabajan juntas.
  • Revisión del progreso – la base de la mejora continua, comprobar qué propusimos anteriormente y si nos ha servido o hay que hacer algo distinto.
  • Generar experimentos – sin ellos no podremos saber si algo que queremos cambiar nos funcionará.

Debido al espacio, tuvimos que adaptar algunas partes del taller que exigían movilidad. El resultado fue muy bueno, ya que pudimos tratar los dos casos más votados. Primero entre tres equipos cada caso. Después, puesta en común donde surgieron muchas más opciones que pudieron dar pistas al resto de asistentes.

Casos retrospectiva - taller de retrospectivas

Personas y relaciones

Curiosamente, los casos más votados tienen que ver con personas y relaciones. Estamos hablando de entornos complejos. Si además son equipos de personas con perfiles muy distintos, empezamos a hablar también de un entorno complicado. Para entender bien esta parte de los sistemas complejos, la matriz de Stacey siempre ayuda:

Experiencias ricas para todos

Seguimos aprendiendo, siempre. Experimentar es lo mejor que podemos hacer para aprender más rápido y mejor. Pero no hay que olvidar que el entorno debe ser seguro. En el caso de las retrospectivas, es muy importante no olvidar que es el evento más complejo y complicado. Conseguir buenos resultados cuando se trata de cambiar mentalidades, hablar de sentimientos, tratar emociones… Es una de las cosas más difíciles que he experimentado en equipos.

Nuestro experimento nos ha hecho aprender a acotar el contexto sobre el que vamos a hacer un taller. Algo que nos resultó muy complicado fue no saber el aforo ni las expectativas de un tema tan amplio. En futuras ocasiones deberíamos ser nosotros quienes pusiéramos los límites y se informase a los asistentes antes de inscribirse. Para que de esta forma que puedan tener más claro a dónde van y a qué van.

Este tipo de talleres, nos ayudan a empatizar, a ver la otra cara de la moneda y otras formas de pensar, son una parte muy bonita del aprendizaje. ¡Gracias por el feedback a los que pudisteis asistir! Es la mejor forma que tenemos de seguir mejorando.

Taller de Retrospectivas - Alberto y Laura

  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad