¿Es buena idea que el Propietario del Producto sea alguien de negocio del cliente?

Propietario del Producto del cliente
Gracias Andrés :-)

El éxito de un proyecto o la construcción de un producto depende fuertemente de la figura del Propietario del Producto. Él es quien guía al equipo de desarrollo en la dirección adecuada basándose en el valor de negocio, lo hace a través de la pila de producto, es el máximo experto en el producto, tiene toda autoridad sobre el mismo y ha de ser una persona totalmente comprometida con los problemas y necesidades de los usuarios y clientes.

Bajo esta perspectiva un Propietario del Producto proviniente del cliente parece ser la mejor opción. Si el cliente tuviera una persona de negocio para el rol de Propietario del Producto que estuviera comprometida con las responsabilidades del rol, que pudiera dedicar el tiempo necesario y conociera tanto negocio como producto, sería sin duda la opción con la mayor probabilidad de éxito. Además tendría mucho sentido que el cliente asumiera la responsabilidad del valor generado, ya que, después de todo, es el promotor del producto.

Desde perspectiva de Scrum cliente y Propietario del Producto son roles fundamentalmente diferentes. El Propietario del Producto es un rol específico del core del marco de Scrum, es un rol comprometido o "cerdo", mientras que el cliente es un interesado, un rol involucrado o "gallina".

En este post quiero exponer cinco cuestiones que debemos de tener presentes cuando decidamos si es adecuado que el rol del Propietario del Producto lo cubra una persona del cliente:

1. La disponibilidad del candidato: las tareas de negocio que pueda tener la persona puede limitar su disponibilidad, un Propietario del Producto requiere entre un 30 y un 50% de su tiempo dedicado al equipo. Es importantísimo que el Propietario del Producto esté disponible para clarificar dudas y refinar el trabajo del equipo, un Propietario del Producto del cliente suele estar en otra ubicación con lo que la comunicación se pudiera ver mermada y esto ralentizaría el buen funcionamiento del marco de Scrum.
2. Entendimiento holístico del producto: Un Propietario del Producto de cliente suele formar parte de un área de negocio concreta, con lo que pudiera costarle salir de su nicho para ver y comprender el big picture y evitar dar más importancia de forma inconsciente a las necesidades que conoce más directamente.
3. Entendimiento de Scrum y Agilidad: un Propietario del Producto no solo necesita conocimiento sobre el producto/proyecto, sino también entendimiento y diversas habilidades en torno al proceso de Scrum. Un Propietario del Producto de cliente no alineado podría resultar en una relación jerárquica y tensa para con el equipo de desarrollo. En vez de colaborar, el Propietario del Producto podría actuar como jefe de proyecto y desde la posición del pagador que quiere sacar todo el jugo a su proveedor. En estos casos la reunión diaria se convierte en un reporte diario, la retrospectiva en un evento para presionar al equipo, la revisión en una critica del trabajo hecho por el equipo y la planificación en un "venga chicos, seguro que os cabe una historia de usuario mas". En estas situaciones el Propietario del Producto estaría a su vez bajo presión de los interesados, todo se volviera urgente y se anularía toda priorización de las historias.
4. Influencia en el comportamiento del equipo: un Propietario del Producto del cliente, que se muestra como cliente, puede inhibir al equipo en la retrospectiva. Si el equipo siente la presencia de un cliente crítico no actuará de forma natural y transparente, no sacará los verdaderos problemas a la luz, y sus éxitos serán más acciones de venta hacia el cliente que celebración y reconocimiento. Todo ello anularía la mejora continua y convertiría las retrospectivas en reuniones sin valor.
5. Verdadero poder de decisión y autoridad sobre el producto: una ventaja de un Propietario del Producto externo al cliente es que se le contrata para ese rol, de manera que se le empoderará dándole el poder de decisión requerido. Una persona interna del cliente, al ser parte de negocio, puede que no tenga ese poder de decisión.

¿Cómo contratar y desarrollar talento en empresas ágiles?

Evento "Agile en HR"

Me llamó la atención un meetup titulado "Agile en HR", en el que María Zambudio iba a presentar ideas para entender cómo la Agilidad puede dar respuesta a los retos de los profesionales de Recursos Humanos en un entorno de escalado Agile en de las empresas. Por supuesto acudí :-) En la descripción del evento se lee:

"Recursos Humanos es, normalmente, el primer punto de contacto que los nuevos colaboradores tienen con la empresa, de ahí su importancia en comenzar a adoptar y conocer los entornos ágiles. Pero la contribución de este nuevo paradigma va más allá, ya que supone un marco de relación nuevo con los colaboradores, que se adapta al entorno empresarial en el que nos encontramos, demandante de nuevas formas de atraer y retener el talento".

En Agilidad la clave está en la colaboración, y la unidad es el equipo, por tanto Recursos Humanos tiene un papel determinante al proveer a la empresa de perfiles de talento que sean fuertemente colaborativos y que sumen al ecosistema de equipos existentes. Recursos Humanos en una compañía ágil ha de ser employee-centric, donde su "cliente" es el empleado, donde los protagonistas en la contratación ágil son las personas y los empleados, donde el reclutador tiene un rol de líder al servicio. SAFe® propone seis puntos que empresas ágiles pueden incorporar para Recursos Humanos ágiles:

1. Incorporar el nuevo contrato de talento
2. Fomentar el compromiso continuo
3. Contratar por actitud y compatibilidad cultural
4. Cambiar a feedback de rendimiento iterativo
5. Quitar la variable del dinero de la mesa
6. Apoyar el aprendizaje y el desarrollo significativo

Como podemos ver la mentalidad de Recursos Humanos ágil es distinta a la tradicional, por ejemplo, las entrevistas han de ser más bien conversaciones con simetría, tanto de posición como de información. Ambos, reclutador y reclutado deben de estar al mismo nivel tratando de averiguar si el talento del reclutado encaja para aportar a la empresa y a los equipos que operan dentro de la misma. Un ejemplo que ilustra muy bien esta mentalidad es Zappos: todo colaborador recién contratado es premiado con 3000 dólares si en las primeras dos semanas se da cuenta de que no encaja y decide salir de la compañía... así Zappos se asegura de que sus empleados son aquellos que le conviene, colaboradores motivados y comprometidos a aportar valor a la empresa.

Matriz que muestra la evolución Recursos - Humanos - Agile

Otro aspecto diferencial son las salidas de la empresa, estas no deben de considerarse un adiós sino un hasta luego. En gran medida las personas que se van no lo hacen de las empresas, sino de las personas que han sido sus jefes. En una compañía ágil los "jefes" son líderes que se preocupan por el desarrollo y el entorno de sus empleados, por tanto si un colaborador se va es porque ya no aporta en el crecimiento de la empresa, o porque la empresa ya no aporta al desarrollo de la persona. En cualquier caso y en cualquier momento puede volver a producirse aporte de valor por cualquiera de las partes, por tanto la salidas son algo natural, igual que las entradas.

Aunque en Recursos Humanos ya desde hace más de una década hay tendencia de dar más importancia a "humanos" que a "recursos", la sorpresa que expresaba María en el meetup es que la Agilidad, que lo ha materializado tan fuertemente, haya salido de TI. Sorprende el hecho de que el tratar y hablar de personas, de seres humanos, haya emergido ¡¡¡de los freakys informáticos!!!

Personalmente pienso que tiene que ver con como las mentes de los profesionales de TI han sido encorsetadas por el taylorismo, la organización del trabajo basada en la división de las distintas tareas del proceso de producción en personas especialistas que mata toda creatividad y pensamiento abstracto. Los románticos pensamos que la Agilidad fue creada para crear un mundo mejor, los pragmáticos, entre ellos Jeff Sutherland, que es por pura supervivencia.

"Toda inversión en Recursos Humanos Lean-Agile

es una inversión en tu gente y en tu futuro"

Dean Leffingwell y Richard Knaster

Desde 2015 Recursos Humanos tiene su propio manifiesto recogido en el Manifesto for Agile HR Development.

---

Manifiesto Ágil para el Desarrollo de RRHH

Estamos descubriendo mejores formas de desarrollar una cultura de trabajo atractiva y al hacerlo ayudamos a otros a hacerlo. A través de este trabajo hemos llegado a valorar:

• Redes colaborativas sobre estructuras jerárquicas
• Transparencia sobre el secreto
• Adaptabilidad sobre prescriptibilidad
• Inspiración y participación sobre la gestión y la retención
• Motivación intrínseca sobre recompensas extrínsecas
• Ambición sobre la obligación

Seguimos los siguientes principios:

• Apoyar a las personas a participar, crecer, y a ser felices en su lugar de trabajo.
• Alentar a las personas a dar la bienvenida al cambio y a adaptarse cuando sea necesario.
• Ayudar a construir y apoyar redes empoderadas de equipos autoorganizados y colaborativos.
• Nutrir y apoyar la motivación y las capacidades de las personas y los equipos, y ayudarles a construir el entorno que necesitan, y confiar en ellos y en su trabajo.
• Facilitar y nutrir el crecimiento personal, para aprovechar las diferentes fortalezas y talentos de los empleados.

---

¿Pero cómo empezar? Jeff Gothelf propone en su artículo "How HR Can Become Agile (and Why It Needs To)" dos actividades esenciales para que el equipo de Recursos Humanos ayude a que los esfuerzos ágiles de su empresa tengan éxito.

Ve y mira (Go and see)

Para entender qué cualidades se requieren para trabajar de forma ágil, el equipo de Recursos Humanos necesita visitar el lugar donde se hace el trabajo (gemba) y ver como los equipos ágiles colaboran y trabajan. Hablar con los miembros de estos equipos, entender lo que les gusta de esta forma de trabajar, lo que es frustrante y lo que buscan en sus colegas, no solo en su propia disciplina sino también en otros equipos con los que colaboran. Las habilidades duras y la aptitud son importantes, recordar que se pueden enseñar, las habilidades básicas cruciales que se necesitan para entornos ágiles son las blandas y la actitud: curiosidad, humildad y colaboración, que solo se pueden liderar, fomentar y modelar.

Retrospectivas de Recursos Humanos

Las restrospectivas son una práctica ágil muy valiosa que en marcos de escalado debe ampliarse a toda la organización, incluidas las disciplinas de soporte como lo es Recursos Humanos.

Las retrospectivas se pueden llevar a cabo solo con el equipo de Recursos Humanos, así como también con sus clientes internos. En la contratación, varios reclutadores pueden reunirse regularmente para revisar el lenguaje de solicitud de empleo que parece atraer a los mejores candidatos, o tratar preguntas que revelan la propensión de un candidato para un trabajo ágil y utilizar esta información compartida para optimizar su proceso. También se puede tratar el ciclo de contratación completo, que incluye revisiones de desempeño y salidas.

El punto está entender si el trabajo que está haciendo Recursos Humanos aporta valor a la empresa, y si no fuera así plantearse ¿qué podemos cambiar en el próximo ciclo para intentar mejorar eso?

Descargas / Downloads

La presentación Entornos Ágiles para "los de" Recursos Humanos de María.

Mis agradecimientos a María Zambudio por abrir nuevas perspectivas desde RRHH :-)

¿Cuáles son los aprendizajes de las primeras PI Plannings?

Plan de equipo en simulación previa

Llevo ya unas pocas PI Plannings a mi espalda y con ello un montón de aprendizajes. Previamente a la primera PI Planning formo a los roles principales, como lo son los Propietarios del Producto y los Scrum Masters, para prepararlos para el evento mediante una simulación de 2 iteraciones con todas los artefactos y prácticas que conlleva.

Después de la formación solemos introducir algunos ajustes y cambios, creyendo adaptar la práctica lo mejor posible a nuestra realidad. El aprendizaje principal lo resumiría en que SAFe® tiene prácticas de PI Planning muy maduras y experimentadas, y que todo lo que dejes fuera emerge por si solo de forma natural... aprendizajes fueron:

No pensar en los objetivos ampliados (stretch objectives): un plan a nivel de tren es muy complejo, hay dependencias y todo el entramado de planes requiere mecanismos para garantizar el éxito. Para que los equipos puedan garantizar la construcción de lo importante necesitan margen, necesitan no comprometerse con todo y saber qué dejar fuera en caso de no llegar con todo a final de PI. De forma natural, y por pura necesidad, acabamos introduciendo a lo largo de la primera PI Planning dos zonas para las historias de usuario, una para las comprometidas y otra para las no comprometidas.

Representar las dependencias sólo con post-its sin cuerdas: Una de las problemáticas que detectamos fue que los equipos no entendían la diferencia entre dependencia y riesgo. Decidimos representar las dependencias por códigos numéricos por pares apuntados en los post-its de ambas historias de usuario dependientes entre si. Esta forma de hacerlo invisibiliza las dependencias, ya que estas son la relación entre las historias, la dependencia es la cuerda. Sin cuerda una dependencia puede entenderse como un riesgo.

Scrum de Scrums: es importante mantener un ritmo sincronizado en todos los equipos, para ello SAFe propone puntos de situación cada hora. No lo hicimos así, y ocurrió que algunos equipos acabaron antes que los demás y se produjo una sensación de desconexión y caos, que hizo que los demás equipos corrieran y probablemente hayan tomado decisiones a la ligera.

PI Planning en un solo día: es importantísimo cerrar bien, el resultado de la PI Planning ha de ser sólido, hay alrededor de 100 personas implicadas y hemos de garantizar obtener el plan mejor resuelto, el más factible, el que tenga las mayores probabilidades de éxito. SAFe marca dos días de planificación, pensamos que con uno solo sería suficiente y resultó que al final del mismo todos estaban muy cansados. Fue una jornada agotadora y al final de la misma los acuerdos y la toma de decisiones fueron rápidas y posiblemente a la ligera, y sabemos muy bien que las decisiones a la ligera son malas decisiones.

Se nota mucho en el ambiente porque todo el mundo quiere acabar y todo se acelera de una forma que no es coherente. En vez de que cada equipo expusiera su plan a toda la audiencia, invitamos a que todos visitaran los planes de los demás y solo echaran un vistazo a los tableros. El alineamiento del tren resultó ser mucho más pobre de lo esperado, nadie había reparado realmente en los objetivos de los demás equipos. Los Business Owners deberían haber puesto valor de negocio a los objetivos, y en vez de ello simplemente habían aceptado los planes. La conclusión fue que para cerrar bien es necesario estar frescos y presentes, si no cerramos bien lo haremos inevitablemente a lo largo del PI de forma mucho más costosa.

Saltarse la votación de confianza a mano alzada: en una primera PI Planning un Scrum Master mencionó que era mejor no hacer la votación ya que todos estaban cansados y no sería una votación muy realista. Tenía razón, así que no la hicimos. La votación de confianza es importante ya que trae a la luz asunciones ocultas, parece que todos hemos trabajado bien y estamos encantados, pero si hubiera algunas voces que tuvieran algo importarte que decir, y permanecen calladas, podemos poner en riesgo toda la PI Planning, ajenos a que hubiéramos podido evitarlo.

De tanto en tanto hacemos votaciones de confianza en las planificaciones de sprint para revelar al equipo la confianza que tiene en su plan. A veces alguien levanta solo 2 o 3 dedos, le invitamos a exponer sus preocupaciones y en la mayoría de los casos se trata de algún malentendido o una carencia de información que se resuelve en minutos. Lo importante es que esa persona, que no creía en el plan, después si cree, y por tanto su compromiso se ve reforzado.

Quiero resaltar que cada una de las PI Planning que he vivido ha sido un completo éxito y ha aportado aprendizajes muy valiosos. He participado en varias transformaciones ágiles donde cada una de estas planificaciones ha establecido conexión entre áreas y equipos, de forma que han acelerado notablemente el flujo interno. Su mayor aportación fue crear y reforzar la estructura de colaboración dentro de las compañías.

PI Planning con resultados espectaculares, la construcción de estructuras de colaboración organizacional

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

¿Cómo hacer una retrospectiva que haga emerger un camino de crecimiento para el equipo?

Para impulsar a los equipos, sea cual sea su naturaleza, y hacer team-building intencional, en lo que hay que poner el foco es en las relaciones entre las personas, luego trabajar el objetivo del mismo como equipo y diseñar los pasos para caminar en esa dirección. En Agilidad se trata de equipos como:

• Un equipo ágil, el que incluye Propietarios del Producto, Scrum Masters y desarrolladores
• Un equipo de Product Management, compuesto por los Propietarios del Producto y opcionalmente por los Product Managers
• Un equipo de Scrum Masters y/o coaches ágiles
• Un chapter, un equipo de especialistas en una disciplina y su Chapter Lead

Una forma de revelar el equipo a si mismo es que cada uno de los miembros haga una constelación en papel del equipo. Cada persona dibuja en una hoja de papel un circulo, que representa al equipo, y en el que después coloca los elementos y las relaciones entre estos elementos según la siguientes instrucciones:

Instrucciones constelación en papel

Las constelaciones de los miembros individuales se colocan en una pared y todos visitan las de los demás sin mediar palabra. Ocurrirán muchas cosas en las mentes de los miembros, ellos saben muy bien como es su equipo y descubrirán nueva información y asunciones equivocadas en las constelaciones de los demás.

Se hace una segunda ronda, ronda en la que probablemente todas las constelaciones hayan convergido. Estas se colocan en otra pared y esta vez los miembros pueden conversar sobre las diferencias, pero solo lo suficiente para dibujar una nueva constelación común y consensuada en una hoja de rotafolios. No todos tienen que estar totalmente de acuerdo con la constelación común, ahora si, deben de aceptarla y sentir que llegar a ella les hará mejorar como equipo.

La segunda fase de la dinámica consiste en diseñar el camino de la constelación actual a la constelación que ha diseñado el equipo. En individual todos escriben en post-its cosas que creen que se deben de modificar, añadir, soltar y mantener en el equipo actual. Cada miembro menciona sus post-its de uno en uno, y en conversación y consenso, el equipo decide cuales se colocan en la siguiente matriz de cambio y continuidad:

Matriz de cambio y continuidad

Lo ideal es hacer la matriz sobre un tablero u hoja de rotafolio para dejarla, una vez finalizada la actividad, en una pared cercana a la zona de trabajo del equipo, de manera que irradie continuamente y los cambios ocurran de forma natural en el momento adecuado.

Al principio de las sucesivas retrospectivas corrientes, y mientras queden post-its, se repasa brevemente la matriz para quitar aquellos post-its que ya se hayan cumplido, o aquellos que el equipo considere que se han de desechar. Esta forma de retrospectiva inicia un puente entre lo que es el equipo actualmente con a donde decide llegar, actividad muy útil en equipos que no encuentran su camino de crecimiento.

¿Cómo soluciona Scrum las 5 disfunciones del equipo?

Pirámide de las 5 disfunciones - gracias Gertru

Recientemente asistí a un meetup del club de lectura Madriagil en el que hablamos sobre las "5 disfunciones de un equipo", libro en el que su autor, Patrick Lencioni, nos revela los cinco problemas que impiden que incluso los equipos más brillantes funcionen.

En este post pretendo hablar sobre como Scrum soluciona estas disfunciones. Las 5 disfunciones están estructuralmente conectadas, se muestran en una pirámide, como la de la imagen de la izquierda. Para que se pueda resolver una disfunción determinada, tiene que haberse resuelto la que está en su base.

El éxito de los equipos ganadores está en su funcionamiento óptimo, este dependerá del comportamiento, y recordemos que el comportamiento de miembros y equipos dependerá del entorno que les rodee, y ahí es donde como Scrum Masters tenemos nuestro cometido principal.

Las cinco disfunciones de
un equipo de Leoncioni

Empezando por la base de la pirámide las disfunciones son:

1. Falta de confianza: esta surge por el miedo o la falta de disposición a mostrarse vulnerables ante los demás miembros del equipo. Esto lleva a no abrirse a los demás y a no aceptar errores y debilidades, lo que a su vez impide la construcción de relaciones de confianza.

Como Scrum Masters hemos de crear y garantizar un entorno seguro para el equipo, un entorno donde no tengan miedo a equivocarse, donde equivocarse sea una oportunidad para aprender y por tanto para mejorar. Todos somos vulnerables, en este entorno seguro los miembros del equipo acaban descubriendo que compartir las debilidades y las dudas es enriquecedor, ya que en equipo se puede lograr respuestas a cuestiones insospechadas. En un entorno seguro el equipo comparte el compromiso y los objetivos, muestra hipertransparencia y se involucra plenamente en las retrospectivas.

2. Miedo al conflicto: la falta de confianza propicia la segunda disfunción, el deseo de mantener una armonía artificial que bloquea la aparición de conflictos productivos. En este caso los equipos son incapaces de entregarse a discusiones vivas y apasionadas sobre sus ideas, opiniones y perspectivas, y sus conversaciones son descafeinadas y sus comentarios cuidadosos.

Un buen Scrum Master alienta a la discusión de desacuerdos, a ser valientes y a tener coraje para exponer la opinión de cada cual, y así enriquecer las perspectivas de cada miembro y reforzar el objetivo común.

3. Falta de compromiso: la falta conflicto propicia la tercera disfunción, ya que sin exponer y debatir las verdaderas opiniones de forma abierta y apasionada pocas veces se produce claridad y consenso, lo que irremediablemente lleva a la falta de compromiso. En este caso puede ocurrir que los miembros del equipo fingan estar de acuerdo en las reuniones.

Trabajando la claridad en el equipo el Scrum Master lleva a que sus miembros se comprometan mutuamente entre si, así como con las partes interesadas externas, de forma que los miembros acepten de verdad las decisiones que toman, y que se comprometan con ellas, incluso con aquellas que votaron en contra.

4. Evitación de responsabilidades: con la falta de compromiso con un plan de acción se produce esta cuarta disfunción, los miembros de equipo no son capaces de responsabilizarse con su desempeño y su comportamiento. Hasta los miembros más proactivos y motivados suelen vacilar antes de llamar la atención a sus compañeros sobre acciones y conductas contraproducentes para el bien del equipo.

Como Scrum Master hemos de trabajar los acuerdos y directrices de actuación del equipo. Estas nacen, se consensuan y se explicitan en las retrospectivas, así cada miembro se corresponsabiliza de cumplirlas. Por otra parte los interesados, la presión entre compañeros (peer pressure) y la revisión de los resultados del sprint también generan responsabilidad.

5. Falta de atención a los resultados: la falta de toma de responsabilidades propicia que necesidades individuales como el ego, el estatus personal, el desarrollo de la carrera personal, el reconocimiento o las necesidades del departamento se sitúen por encima de las metas colectivas del equipo, y por tanto del éxito del mismo.

A través de la mejora continua el equipo ganador evoluciona a través de un objetivo común, los resultados del producto se revisan empíricamente al final de cada sprint y cada release, y los resultados de mejoras en la forma de trabajar con cada una de las retrospectivas.

Y ahí estuvimos, debatiendo sobre el libro y mucho más temas relacionados y no relacionados :)

En el meetup también vimos el test que creó Patrick Lencioni y que publica en su libro, que sirve como herramienta de diagnóstico para un equipo, y que por cortesía de CREZCOLAB está disponible en formaro pdf aquí.

¿Qué técnica de retrospectiva es apropiada para tomar feedback del equipo y mejorar su eficiencia?

"Te Boat" del kit de retrospectivas de Spotify Labs - Thanks to
Martin Österberg, Behnosh Esni, Sara Rabiee & Zuza Majkowska

Si queremos trabajar la eficiencia de un equipo podemos utilizar la dinámica de retrospectiva conocida como "el barco" o "el velero". Trata de representar al equipo como un barco tomando rumbo a una isla con rocas dificultando el camino, la dinámica se basa en un análisis DAFO (Debilidades, Amenazas, Fortalezas y Oportunidades).

El barco es una metáfora del equipo, la isla y las rocas representan influencias externas, y el sol es la zona para los agradecimientos.

• Debilidades: el ancla representa las debilidades internas del equipo, lo que lo frena, lo que lo limita y bloquea.
• Amenazas: las rocas y tiburones entre el barco y la isla representan las amenazas, impedimentos o riesgos externos al equipo que pueden complicar el camino del mismo.
• Fortalezas: Las velas representan las fortalezas del equipo, lo que lo hace fuerte, aquellas cosas que lo hacen avanzar.
• Oportunidades: La isla a lo lejos representa el objetivo a alcanzar, el objetivo del sprint, una release, el estado ideal, donde el equipo es bien visto y el cliente está encantado con el trabajo.
• Agradecimientos: No podía faltar el sol, una zona para que los miembros puedan dejar agradecimientos por cosas concretas a sus compañeros.

Dinámica de la retrospectiva

Resultado de una retrospectiva hecha con la técnica del barco

Todos los asistentes identifican por individual elementos de las cinco zonas del tablero y los escriben en post-its. Usualmente el Scrum Master cronometra 5 minutos para esta actividad. Les suelo decir a los asistentes que no tienen que esforzarse para sacar elementos, los importantes están ahí en nuestra cabeza. Esforzarse suele ser buscar lo que no está.

Habiendo escrito todos sus elementos, los asistentes se levantan uno a uno y colocan sus post-its en el tablero. Con cada post-it dan una breve explicación, y si hubiera elementos anteriores similares o iguales, los colocan agrupados junto a estos. Puede que en este punto se produzca algún debate sobre el grupo de elementos, es el momento de ventilar, de celebrar éxitos y llorar fracasos.

Cuando tengamos todos los elementos colocados y agrupados, identificamos cuáles son los prioritarios para buscar acciones de mejora, podemos hacerlo mediante una votación con tres palitos o puntitos por asistente, y que cada cual distribuya como considere.

Finalmente hacemos un brainstorming de ideas para sacar acciones de mejoras siempre enfocadas a llevarnos a nuestro destino, llegar la isla, a lo que hayamos definido como nuestro objetivo. Podemos apoyarnos en las siguientes preguntas para encontrar acciones:

• ¿Como podemos usar nuestras fortalezas para maximizar oportunidades?
• ¿Como podemos aplicar nuestras fortalezas para superar amenazas actuales o potenciales?
• ¿Como podemos reforzar nuestras oportunidades para superar nuestras debilidades?
• ¿Como podemos minimizar nuestras debilidades y evitar las amenazas?