Un instrumento para ayudarte a mejorar como Scrum Master

 

Un Scrum Master adecuado puede manejar dos o tres equipos a la vez. Si está contento con limitar su función a la organización de reuniones, el cumplimiento de los plazos y la respuesta a los impedimentos que las personas informan explícitamente puede arreglárselas con la atención de medio tiempo a esta función. Es probable que el equipo aún supere la línea de base, las expectativas previas a Scrum en su organización y probablemente no sucederá nada catastrófico.

Pero si puedes imaginarte un equipo que se lo pasa en grande logrando algo que nadie antes creía posible, dentro de una organización transformada, considera ser un Scrum Master extraordinario.

Un Scrum Master Extraordinario puede liderar un equipo a la vez.

Recomendamos un Scrum Master dedicado por equipo de aproximadamente ocho personas o menos al comenzar.

Si no has descubierto todo el trabajo que hay que hacer, sintonízate con tu Product Owner, tu equipo, las prácticas de ingeniería de tu equipo y la organización en el entorno de tu equipo. Si bien no existe una receta única para todos, esta lista describe cosas típicas que muchos Scrum Masters pasan por alto, sobre todo quienes apenas están iniciando a caminar por el sendero de la agilidad.

Esta lista de chequeo es una adaptación, más que una simple traducción, del trabajo de Michael James (mj4scrum@gmail.com). He incluido algunos aspectos que me parecieron relevantes a la luz de los últimos cambios en la guía de Scrum y de mi propia experiencia usando la lista.

Para usar el instrumento

Diligencia la lista de chequeo, puedes seguir algunas de las recomendaciones en la página de Documentación de la herramienta. Luego haz clic en el botón “Todo preparado. Muéstrame las gráficas” que encontrarás en la parte superior derecha de la hoja de “Datos de Entrada”.

Como con otros instrumentos de este tipo, para usar la lista de chequeo correctamente, diligénciala con tu equipo o con otros Scrum Masters. Otra opción es llenar la lista individualmente y luego comparar el resultado con los miembros de tu equipo. Verás las diferencias y tendrás la oportunidad de debatirlas en equipo. Empieza a hablar sobre las diferencias, ¿por qué aparecieron? Así, ¡esta lista de chequeo puede ser el comienzo de un plan de mejoramiento! Eso sí, no pienses en juzgar tu desempeño como Scrum Master basado solo en esta lista de chequeo. Recuerda que lo importante es generar Valor, entregar lo que el negocio necesita más y mejorar el proceso continuamente.

Para limpiar los datos y volver a llenar la lista, simplemente haz clic en el botón “Limpiar Datos”.

Usa la herramienta y déjame saber en el foro de tus experiencias y de cómo podemos mejorarla.

Puedes descargar el instrumento aquí. 👇

Daily Scrum Kaizen

Advertencia: que ya no sea un lineamiento de la guía de Scrum, no quiere decir que no podamos seguir usando las “tres preguntas”.

Muchas veces, la respuesta o solución a cómo mejorar la realización o ejecución de un evento Scrum está fuera del evento: por ejemplo, para mejorar la Planning, tenemos que mejorar el refinamiento; para mejorar la Review, tenemos que mejorar la Daily Scrum; para mejorar la Retrospective, tenemos que mejorar la Planning del Sprint siguiente. Siempre he creído que lo mejor de la retrospectiva ocurre cuando esta termina y es la implementación de las acciones de mejora seleccionadas.

Y para mejorar la Daily Scrum mejoremos también la Sprint Planning.

Al definir un Objetivo del Sprint claro, específico, medible, alcanzable y significativo y, por supuesto, circunscrito al Sprint que comienza. Pero definir o establecer el Objetivo del Sprint no es suficiente. ¿Cómo lo vamos a alcanzar? ¿Qué artefacto vamos a usar para verificar que lo logramos? ¿Cuál técnica de validación? ¿Con qué personas lo vamos a hacer? Son algunas otras preguntas que tenemos que poner sobre la mesa y encontrar sus respectivas respuestas.

Recordemos que en la Daily Scrum se inspecciona el progreso hacia el Objetivo del Sprint, entonces se hace necesario dejar de girar el evento en torno a cuáles tareas o actividades hemos realizado o dejado de hacer y enfocarnos más en cómo medir ese avance hacía el objetivo formulado. Además, el Objetivo del Sprint debe tener un vínculo muy íntimo con los elementos del Product Backlog que se van a desarrollar (alias “las historias de usuario”).

Las cosas así, por ejemplo, durante la reunión diaria, responder a la cuestión:

¿Está Terminada la historia de usuario actualmente en desarrollo?

Puede mejorar el rendimiento del equipo y su progresión hacía el Objetivo de la iteración. Incluso podemos complementar esa respuesta con la de esta otra pregunta:

¿Es posible que más personas participen en el desarrollo de esa historia? Sí, ¡pues manos a la obra! Es un poco de Swarming o Enjambre. En desarrollo de software, es posible; pero también lo es en otras actividades.

Otro giro que le podemos dar a la conversación en la Daily Scrum es acercarnos más a los criterios de aceptación de las historias de usuario en desarrollo. Estos criterios también son o deben precisos y medibles, pero más que nada, deben centrarse en el resultado, en el valor a entregar, y deben ser colaborativos, es decir, que inviten a la colaboración de todo el equipo y los interesados.

De esta manera, responder a cuestiones como:

¿Cuál es el estado de los criterios de aceptación de cada historia de usuario en desarrollo?

Es una forma de saber si nos estamos acercando a la meta de Sprint definida. Si el criterio de aceptación aun no ha sido abordado, estamos algo lejos. Si está en desarrollo, ya es un pequeño paso hacia la consecución de los resultados que queremos. Si finalmente está implementado o cumplido, entonces hemos dado un gran paso con miras al logro de ese propósito de la iteración.

Otra alternativa a las tres preguntas es simplemente hablar de “cómo vamos como equipo”, como personas.

¿Cuál es nuestro estado de ánimo? ¿Nuestro nivel de energía?

¡O simplemente aprovechemos esos quince minutos para tomarnos un café! Así sea virtual. Mientras escribo este artículo, seguimos en cuarentena por el virus, catorce meses después. Si estamos haciendo un “buen Scrum”, seguramente justo antes o justo después de la reunión, actualizaremos los radiadores de información a que haya lugar y cada miembro del equipo tendrá la oportunidad de coordinarse o sincronizarse con los demás a medida que avanza la mañana.

En la práctica, no es necesario responder a nada más.

¿Y los impedimentos, riesgos o problemas? Cambiemos un poco la postura sobre este asunto y reorientémonos precisamente hacia el trabajo colaborativo. A los miembros del equipo les podemos enseñar a “levantar la mano” cuando de problemas se trata en el momento en que estos ocurren, ¿por qué esperar a la cita diaria para mencionarlos? Es posible que falten muchas horas hasta la siguiente Daily Scrum y esto puede traer como resultado una baja en la productividad de algunas personas del equipo y, a su vez, que no se pueda conquistar la Meta pretendida.

Como ven, podemos seguir usando las tres preguntas, pero también podemos usar muchas otras tácticas y estrategias para mejorar no solo la Daily Scrum, sino cualquiera de los demás eventos. ¿Y tú, qué técnicas estás usando para mejorar tus reuniones diarias? Por favor, déjamelo saber en el foro.

Nuevo curso: Historias de Usuario - 10 de octubre

Las historias de usuario son un poderoso medio para fomentar la cooperación y la enseñanza de muchas cosas. Estas permiten crear un vínculo entre usuarios o consumidores y desarrolladores de productos o servicios. Y esta relación es el primer gran paso hacia la creación y pináculo de productos admirables, que influencien positivamente a las personas que los usen o consuman e incluso cambien para mejorar su estilo de vida.

Esta Certificación proporciona los fundamentos sobre las principales características de las historias de usuario como instrumentos de comunicación entre los miembros de equipo y los demás interesados en los proyectos de desarrollo de productos o servicios, sean de tecnología o de cualquier otra área del negocio.

Objetivos de Aprendizaje:

Al final del curso los participantes estarán en capacidad de:

• Entender los beneficios de usar historias de usuario en entornos inciertos y ambiguos.
• Desarrollar las habilidades necesarias para usar las historias de usuario como instrumentos de conversación entre las partes interesadas.
• Aplicar varias formas de escribir historias de usuario.
• Reconocer si una historia de usuario cumple con los atributos de toda buena historia de usuario.
• Emplear distintas técnicas de división de historias de usuario para que estas se puedan elaborar en períodos muy breves de tiempo, desde unas pocas horas, hasta muy pocos días.
• Usar las historias de usuario para comprender la proposición de valor del producto y de sus características desde el inicio del proyecto.
• Guiar a otras personas de sus equipos en el uso apropiado de historias de usuario en contextos complejos y adaptativos.
• Certificarse en User Stories Foundations Certificate (respaldando el conocimiento y la aplicación fundamental de las Historias de Usuario).

Público Objetivo:

Este curso y certificación es apropiado para cualquier persona interesada en usar las técnicas relacionadas con historias de usuario, que estén o vayan a participar en proyectos ágiles con marcos de trabajo como Scrum; también, para interesados en los proyectos que están en la cadena de valor de proporcionar características o requisitos a los equipos de desarrollo de productos o servicios.

● Gerentes de producto
● Dueños de Producto
● Mercadeo de productos
● Analistas del negocio
● Analistas funcionales
● Patrocinadores de los proyectos de desarrollo

También a las áreas de TI de la organización:
● Líderes técnicos
● Gerentes de Proyectos
● Desarrolladores
● Arquitectos de software
● Analistas de Prueba
● Diseñadores
● Scrum Masters
● Desarrolladores Scrum
● Consultores Comerciales,
● Consultores de Preventa de Proyectos
● Líderes Funcionales de Áreas Usuarias de Software o similares

Entre otras personas interesadas en mejorar las interacciones de manera efectiva con los demás miembros del equipo y de su empresa mediante el uso de historias de usuario.

Requisitos Previos:

Haber recibido entrenamiento o tener conocimientos o experiencia en al menos uno de estos temas:
● Scrum Master
● Product Owner
● Team Member

Opcional:
Leer el Manifiesto Ágil
Leer la guía de Scrum

Entrenamiento:

Tipo de Curso: Foundations. 

Código de la Certificación: USFC.

Examen de Certificación:

Formato: Opción Múltiple.
Preguntas: 40.
Lenguaje: Inglés/Español/.
Puntaje de aprobación: 32/40 o 80 %
Duración: 60 minutos máximo.
Libro Abierto: No.
Entrega: Este examen está disponible en formato en línea.
Supervisado: Será a discreción del Partner.

Información del próximo curso:

Duración: 9 horas

Modalidad: en línea (virtual)

Fechas y horarios:

Sesión 1:
martes 10 de octubre de 2023.  4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 2:
miércoles 11 de octubre de 2023. 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 3:
jueves 12 de octubre de 2023. 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Inversión:

U$195 precio temprano. *Hasta septiembre 12 de 2023.

U$245 precio regular.

Descuento de 10 % a grupos de tres o más personas. Escríbeme a contacto@luchosalazar.com si quieres acceder a este descuento.

QUIERO UN LUGAR EN EL CURSO

Atención: Incluye certificación User Stories Foundation Certificate

Escríbeme a contacto@luchosalazar.com para reservar tu cupo en un nuevo curso o para despejar cualquier duda que tengas.

¿Quieres este curso para tu empresa? Contáctame para más detalles.

 

Sobre multifuncionalidad y la creación de un incremento de producto

Image by Alexandr Ivanov from Pixabay 

Sobre multifuncionalidad y la creación de un incremento de producto

O de las minicascadas en el Sprint y de cómo deshacernos de ellas

“Todos los patrones de conjuntos fijos son incapaces de adaptabilidad o flexibilidad. La verdad está fuera de todos los patrones fijos”. -Bruce Lee

De dónde venimos

Todos hablamos de que un equipo Scrum es un equipo multifuncional y autogestionado. En nuestro contexto, multifuncional significa que el equipo en pleno suma todas las habilidades y capacidades necesarias para producir un incremento de producto al final de cada iteración. En la práctica eso es más fácil decirlo que hacerlo posible. ¿Qué sucede cuando conformamos un equipo cuyos miembros, en el mejor de los casos, dominan solo una pequeña parte de ese espectro de multifuncionalidad necesaria para hacer el trabajo?

Estos escenarios son mucho más comunes de lo que creemos. Solo para mencionar uno de estos: pensemos en una empresa que viene trabajando con prácticas tradicionales de gestión en las últimas décadas y cuya área de Tecnología cuenta con proveedores externos: unos para desarrollar el software y otros para realizar las pruebas de este. Y tanto las personas de un proveedor como del otro no se hablan sino a través de procesos y herramientas, como un bug tracker o actas formales de entrega y recepción de partes del producto.

Es muy probable que en esos equipos prime la alta especialización: el así llamado desarrollador de front-end, el analista de requisitos, el desarrollador de back-end, el arquitecto del software, de un lado. El analista de pruebas funcionales, el de pruebas no funcionales, el automatizador de pruebas, lo que sería un gran avance, del otro lado. Seguramente cada uno de estos equipos incluya uno o más gestores de esto y de lo otro. Incluso la empresa para la cual trabajan, el cliente, cuente con sus propios roles y responsabilidades dentro de todo este intrincado ecosistema de trabajo.

Imaginemos ese escenario: aquí los unos y los otros son de organizaciones diferentes. Pensemos en que ahora esa empresa quiere hacer las cosas usando enfoques ágiles y lean y prácticas como Scrum e historias de usuario. Además, quiere aprovechar el conocimiento que tienen sus proveedores actuales y decide invitarlos a embarcarse en un viaje que los llevará por los caminos ignotos de la agilidad: una nueva forma de pensar y de hacer las cosas, nuevos comportamientos, conceptos y preceptos muy distintos a los que venían usando, “metodologías” con poca información sobre el cómo hacer las cosas. Nuevos roles. ¡Y un solo equipo!

Para dónde vamos

Image by Merhan Saeed from Pixabay 

Entonces esto de la autogestión y la multifuncionalidad no ocurre mágicamente por la intervención de un Scrum Master o de un agente de cambio con alguna etiqueta específica. Es fácil decir o proponer que el tamaño de los elementos del product backlog se encuentren en un rango, por ejemplo, entre 1/10 a 1/6 de la velocidad “conocida” del equipo. Pero una cosa es contar con un equipo cuyos jugadores dominen más de una especialidad, sino todas, a hacerlo en un equipo donde eso no ocurre ni ocurrirá durante algún tiempo. Adquirir habilidades T toma tiempo, aunque los beneficios son evidentes una vez que se consigue. Pues bien, una primera recomendación es reducir aún más el tamaño de las historias de usuario.

Es algo para tener en cuenta cuando se hace refinamiento o, simplemente, cuando se dividen elementos del product backlog en piezas más pequeñas. Eso es necesario porque el trabajo en el sprint será una minicascada: si se trata de desarrollo de software, por ejemplo, primero se realizará el trabajo de diseño y programación y luego se hará el trabajo de pruebas o de aseguramiento de la calidad. Incluso es posible que, en cada una de esas breves fases, haya etapas más pequeñas que se lleven a cabo de manera secuencial.

Las cosas así, no será posible cumplir la promesa de tener elementos del product backlog (alias las historias de usuario) terminados durante los primeros días del sprint. Esto, como sabemos, sube la presión y el estrés sobre el equipo y sobre los interesados y usuarios, representados por el Product Owner. Es un hecho: llegar a la mitad del sprint o más allá, independientemente de su duración, sin que ninguna historia de usuario alcance la Definición de Terminado, aumenta la ansiedad e inicia un ciclo nocivo de sucesos que derivan en resultados pobres, pero, sobre todo, en desmotivación y en una baja de energía en el equipo.

Estas son algunas recomendaciones de experimentos que he encontrado útiles para despejar esas nubes cenizas que arremeten contra el trabajo colaborativo:

·       Historias de usuario más pequeñas.

·       Menos historias de usuario.

·       Sprints de dos o de tres semanas. Siempre podemos disminuir la duración más adelante.

·       Un refinamiento que “mire” dos o, mejor, tres Sprints hacia adelante.

·       Manejo de expectativas con los usuarios e interesados, vía la Product Owner o el Scrum Master o alguna otra persona del equipo o muy cercana a este.

·       Ordenamiento por valor del product backlog, más que hacer priorización. Es decir, ordenar uno a uno, por valor e impacto para el negocio, para los usuarios o clientes, cada historia de usuario. Muchas veces la priorización se hace por grupos de elementos. El ordenamiento se hace de manera individual. Esto asegura que en cada sprint se entregue Valor, aunque este sea en pocas cantidades.

·       Foco en una historia a la vez y concentrarse en su finalización.

·       Promover la colaboración, el trabajo en equipo, la inteligencia colectiva.

Pero lo más importante y crítico es poner en marcha un plan de desarrollo de competencias que faculte a las personas para adquirir habilidades T en principio y, más adelante, habilidades Pi. Esto toma tiempo, requiere de una inversión considerable, pero es lo que va a permitir hacer las cosas de una manera diferente de una vez por todas y para siempre. Un plan que incluya:

·       Adquisición de nuevas prácticas y, si es necesario, de nuevas herramientas.

·       Trabajo en pares.

·       Usar el patrón Swarming o Enjambre. Esto es, todo el equipo, o casi todo, trabajando en una única historia de usuario a la vez. Más sobre este patrón en: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/.

·       Pasantías.

·       Acompañamiento y mentoría.

·       Autoestudio.

·       Potenciación de habilidades.

·       Práctica. Kata. Kata. Kata.

Los beneficios de desarrollar este plan no girarán solo en torno al aumento de la productividad del equipo, sino también a la entrega de mayor valor en cada iteración, al incremento de la calidad, a la mayor satisfacción y felicidad de usuarios o consumidores finales, y también contribuirán a energizar al equipo, a su bienestar, a menos estrés y a más motivación.

¿Qué te parecen estas ideas? Por favor, cuéntamelo en el foro.

---

*Crédito de la imagen de la sección "De dónde venimos": silhouettes by Gerd Altmann from Pixabay 

Team Canvas: un lienzo para promover identidad de equipo

 

Team Canvas. Fuente: http://theteamcanvas.com/use/

Team Canvas

Objetivo

Creado por Alex Ivanov y Mitya Voloshchuk, el Team Canvas es un marco de trabajo estratégico que ayuda a que los miembros del equipo estén en la misma página. Basado en la experiencia de sus creadores con equipos de startups y agencias creativas, está hecho para alinear equipos, aumentar la cohesión y el rendimiento y crear una cultura de equipo productiva, rápidamente.

El lienzo tiene dos versiones: una básica, conocida como el Lienzo Básico, y una extendida, conocida simplemente como el Lienzo.

Lo que sigue es la traducción de los lineamientos para el uso del lienzo extendido dados por sus propios autores en la página oficial: http://theteamcanvas.com/use/.

Team Canvas funciona en varios puntos de contacto:

•         crear un equipo;

•         aclarar los objetivos y abordar el desempeño general del equipo (por ejemplo, cuando se siente estancado como equipo o cuando necesita hacer muchas cosas);

•         crecimiento e incorporación de nuevos miembros del equipo;

•         sesiones de alineación general (recomendadas cada 2-3 meses).

Integración de miembros del equipo

Antes de usar el lienzo, asegúrese de que todos los miembros del equipo se unan para hacerlo. Es posible que desee tomar la iniciativa y sugerir la herramienta a su equipo. Aquí hay algunas de formas de presentar el lienzo:

Caso: Comenzando un equipo

¡Hola, chicos! Dado que estamos formando el equipo ahora, me gustaría proponer hacer una sesión sobre cómo crear la estructura de nuestro equipo y conocernos. Cada uno de nosotros podría haber tenido una de esas experiencias previas con equipos cuando las cosas no salieron tan bien. Entonces, ¿por qué no invertimos algo de tiempo para asegurarnos de que estamos alineados y listos para comenzar?

Caso: Ajuste de equipo

¡Hola, chicos! Nuestro trabajo ha sido un poco confuso últimamente, y pensé que podríamos dedicar un tiempo a aclarar las cosas y ponernos en la misma página. Existe una buena herramienta llamada Team Canvas, que puede ayudarnos a alinearnos y estructurarnos un poco más como equipo. ¿Qué dicen si lo usamos para una sesión de alineación?

Caso: Incorporación de un nuevo miembro

Como saben, somos un equipo pequeño y conseguir una nueva persona a bordo es una gran decisión. Queremos asegurarnos de que todos estamos de acuerdo en las cosas fundamentales y de que trabajaremos muy bien juntos. ¿Qué dicen si llevamos a cabo una sesión con esta herramienta, The Team Canvas, asegurándonos de que estamos alineados con nuestra visión y valores fundamentales, y tenemos una coincidencia?

________________________________________

Ejecutando la sesión

Duración: 90-120 minutos

Participantes: 2-8

Facilitación: líder de equipo o facilitador externo

Materiales:

•         Team Canvas recreado en una pizarra o en una hoja de papel lo suficientemente grande (por ejemplo, papel de rotafolio o A0 / A1).

Nota del traductor: esta pizarra puede ser virtual. Al final los dejo con el enlace a una plantilla en español que uso en Mural para facilitar sesiones de Team Canvas.

•         Bloques de notas adhesivas, una para cada participante, de diferentes colores

•         Sharpies o bolígrafos para escribir en adhesivos

•         Un dispositivo con función de temporizador

Ejecutando la sesión

Presente el Lienzo de Equipo como una herramienta para alinear a los miembros del equipo y mejorar la comprensión de los objetivos, roles y valores de su equipo.

Repase cada paso con el equipo, asegurándose de hacer las preguntas para cada segmento. Anime a las personas a que escriban sus respuestas en adhesivos y hablen de ellas con el equipo. Hay campos en los que todo el equipo debe estar de acuerdo: 1. Personas y roles; 2. Objetivos; 4. Propósito; 5. Valores; 9. Reglas y cultura. El resto de los campos se pueden rellenar individualmente, sin necesidad de un acuerdo particular.

________________________________________

1. Personas y roles [5 minutos]

Pida a las personas que pongan sus nombres en adhesivos, así como sus roles. Si una persona tiene varios roles, use post-its separados.

Preguntas:

•         ¿Cuáles son nuestros nombres?

•         ¿Cuáles son los roles que tenemos en el equipo?

•         ¿Cómo se nos llama como equipo?

Ejemplos:

•         Max: CEO; Marie: Diseño y programación

•         Nombre del equipo: BoldCar

________________________________________

2. Objetivos comunes [10 minutos]

Pídale al equipo que se ponga de acuerdo sobre objetivos comunes.

Preguntas:

•         ¿Qué es lo que realmente quieren lograr ustedes como grupo? ¿Cuál es nuestro objetivo clave que sea factible, medible y de duración determinada?

Ejemplos:

•         Convertirnos en la empresa líder de car sharing en nuestra región para 2017.

•         Crear una empresa de 100 millones en el área de Internet de las cosas para el otoño de 2016.

________________________________________

3. Objetivos personales [5 minutos]

Pregunte a los miembros del equipo sobre sus metas individuales para el proyecto.

Preguntas:

• ¿Cuáles son nuestras metas personales individuales para este proyecto?

• ¿Hay agendas personales que queremos abrir?

Ejemplos:

• Tener más confianza en el desarrollo de iOS [Marie]

________________________________________

4. Propósito [10 minutos]

Pídale al equipo que vaya un paso más allá de su objetivo común y pregúnteles por qué hacen lo que hacen.

Preguntas:

•         ¿Por qué estamos haciendo lo que estamos haciendo en primer lugar?

•         ¿Qué es algo más importante que nos impulsa a perseguir nuestro objetivo común?

Ejemplos:

•         Crear un impacto positivo en la vida de las personas a través de la innovación social.

•         Hacer la vida de las personas más fácil y sin estrés a través de la innovación en Internet de las cosas.

________________________________________

Team Canvas Básico. Fuente: http://theteamcanvas.com/use/

5. Valores [10 minutos]

Pregunte al equipo cuáles son los valores fundamentales, los principios más importantes, que quieren compartir dentro del equipo. El equipo debe estar de acuerdo con los valores, para que todos acepten el conjunto final.

Preguntas:

•         ¿Qué representamos?

•         ¿Qué son los principios rectores?

•         ¿Cuáles son nuestros valores comunes que queremos que sean el núcleo de nuestro equipo?

Ejemplos:

•         Confianza

•         Creatividad

•         Calidad

•         Transparencia

•         Entendimiento mutuo

•         Igualdad

•         Respeto

________________________________________

6. Fortalezas y ventajas [15 minutos]

Pídale al equipo que comparta las piezas clave de habilidades (tanto duras como blandas) y los activos disponibles dentro del equipo. No descarte las cosas "insignificantes". Puede encontrar que el equipo tiene capacidad para las artes marciales, correr maratones o persuadir a la gente. Anime a las personas a compartir algo sobre sí mismas, así como también observe las cualidades importantes que ven en sus compañeros de equipo.

Preguntas:

•         ¿Cuáles son las habilidades que tenemos en el equipo que nos ayudarán a lograr nuestras metas?

•         ¿Cuáles son las habilidades interpersonales / blandas que tenemos?

•         ¿En qué somos buenos, individualmente y como equipo?

Ejemplos:

•         Codificación (iOS / Python / etc.)

•         Diseño

•         Ser devoto y motivado

•         Ser visionario

•         Energía

•         Ventas y presentación

________________________________________

7. Debilidades y áreas de desarrollo [15 minutos]

Pídale al equipo que comparta las debilidades clave y las áreas de mejora que ven en sí mismos, así como los obstáculos que enfrentan como equipo. Haga hincapié en informar lo que las personas pueden encontrar en sí mismas, en lugar de discutir las debilidades de los demás.

Preguntas:

•         ¿Cuáles son las debilidades que tenemos, individualmente y como equipo?

•         ¿Qué deben saber nuestros compañeros de equipo sobre nosotros?

•         ¿Cuáles son algunos de los obstáculos que vemos por delante que es probable que enfrentemos?

Ejemplos:

•         Se distrae fácilmente [Marie]

•         Puede ser arrogante [Max]

•         Falta de comunicación estructurada [general], etc.

________________________________________

8. Necesidades y expectativas [10 minutos]

Pídale al equipo que exprese las necesidades que tienen para tener éxito. Piense en esto como un seguimiento de las dos secciones anteriores: una vez que los miembros del equipo expresaron sus fortalezas y debilidades, deberían poder expresar las necesidades que tienen para amplificar las fortalezas y estar en su mejor momento a pesar de las debilidades.

Preguntas:

•         ¿Qué necesita cada miembro del equipo para tener éxito?

•         ¿Cómo podría el equipo ayudar a cada miembro con sus necesidades?

Ejemplos:

•         Un poco de «tiempo para mí»

•         Actualizaciones de estado semanales más claras

•         Ayuda y coaching

•         Confianza

•         Divertida

•         Estabilidad

________________________________________

9. Reglas y actividades [10 minutos]

Pídale al equipo que acuerde reglas y actividades comunes. Piense en esto como el resultado de las secciones anteriores: un conjunto concreto de reglas y actividades que desean implementar.

Preguntas:

•         ¿Cuáles son las reglas que queremos introducir después de hacer esta sesión?

•         ¿Cómo nos comunicamos y mantenemos a todos actualizados?

•         ¿Cómo tomamos decisiones?

•         ¿Cómo ejecutamos y evaluamos lo que hacemos?

Ejemplos:

•         Mantener la confidencialidad de las cosas dentro del grupo

•         Actualizaciones de estado semanales

•         Comunicación a través de Slack + Skype para llamadas

•         Cenas juntos cada dos semanas (Max como organizador)

•         Jornada laboral: de 9 a 10, las reuniones comienzan a las 10

•         Mantener la jornada laboral a 8 horas, excepto cuando sea necesario acortarla un poco hacia más

________________________________________

Finalizar [5 minutos]

Al cerrar el taller El lienzo del equipo, pida a los miembros del equipo que cuenten una de las ideas más importantes que obtuvieron durante el taller.

________________________________________

Estrategia

Al utilizar Team Canvas completo, es bueno tener en cuenta que consta de 4 partes:

1.    Qué es el equipo: roles y objetivos (tanto comunes como personales)

2.    Por qué el equipo hace lo que hace: propósito y valores

3.    Quiénes son los miembros del equipo: sus fortalezas, debilidades y necesidades

4.    Cómo el equipo va a lograr lo que necesita lograr: reglas y actividades

Como facilitador de la sesión, es posible que a menudo se le pregunte algo como esto: "¿Cómo se supone que debemos responder a esta pregunta? ¿Qué es lo que espera que digamos aquí?”, Etc. Es importante comprender que The Team Canvas crea contexto para el equipo, en lugar de contenido, y por lo tanto todas las respuestas son válidas. Responda amablemente a estas preguntas: '¿Cómo respondería si lo supiera? ¿Cuál crees que debería ser la respuesta?

Sería una buena idea aparcar las conversaciones que parecen llevar demasiado tiempo al equipo y organizar reuniones por separado para abordar estos problemas.

Recomendamos repetir las sesiones de Team Canvas de vez en cuando, especialmente cuando se unen nuevos miembros del equipo.

________________________________________

 

Notas del Traductor:

Los tiempos propuestos para cada parte del lienzo son los bloques de tiempo sugeridos por los autores. En entornos virtuales y remotos, donde además haya poca experiencia en el uso de tableros y otras herramientas virtuales como Mural, Miro, Meet, Teams y Zoom, entre otras, estos bloques de tiempo pueden ser mayores. Sugiero duplicarlos.

La experiencia también me ha mostrado que, si el equipo apenas está iniciando su proceso de formación y muchos o quizás ninguno de sus miembros se conocen con los demás, el taller puede tardar un poco más.

Como lo había mencionado, el tablero que se use para crear el lienzo puede ser virtual. Los dejo aquí con un enlace a una plantilla en español que uso para facilitar sesiones de Team Canvas.

Enlace a plantilla de Team Canvas en Mural.

Por comodidad, el lienzo tiene un outline que permite navegar a través del tablero por cada una de las secciones del lienzo. Además, el tablero completo incluye una zona de divergencia para que el equipo genere ideas a discreción antes de registrarlas en cada sector del lienzo de manera definitiva.

Esta es una ilustración del lienzo que encontrarán en el tablero.

Desde aquí también puedes acceder a la plantilla en Mural:

Plantilla Team Canvas por Gazafatonario

Abre para crear un tablero a partir de esta plantilla en tu espacio de trabajo. Powered by MURAL

O puedes descargar la plantilla aquí para usarla desde donde lo necesites:

Por favor, déjame saber en el foro o contactándome directamente de tu experiencia usando esta plantilla y de cómo podemos mejorarla.