Buenas y “malas” historias de usuario

Los criterios INVEST* no son los únicos que hacen a una historia de usuario una “buena” historia de usuario. Pero son un buen comienzo. Además, decir o pensar que una historia de usuario es buena o mala quizás no sea la mejor idea. En cualquier caso, lo más importante es si la historia está preparada o no para implementarse o desarrollarse. Si no lo está, entonces hace falta conversación, ojalá cara a cara, para ponerla a punto: conversación entre los usuarios o interesados clave y un dueño de producto o gerente de producto; y también, conversación entre estos y el equipo de personas que finalmente hará el trabajo de implementación de esas historias.

Nota mental: en realidad, lo más más importante de la historia de usuario es que genere Valor, en cualquiera de sus modos, por ejemplo: más ingresos, mayor felicidad a los usuarios o consumidores, menores gastos, mejora en la marca organizacional, más clientes, mayor aprendizaje, entre muchas otras formas de valor.

Y como son un buen comienzo, veamos algunos ejemplos de cómo se cumplen o no esos criterios en las historias de usuario. Usaremos la forma Connextra para escribir las historias de usuario, pero recordemos que hay muchísimas formas, cuando no infinitas, de representar las historias. Los ejemplos corresponden a una plataforma de compra y venta en línea de productos y en algunos de ellos obviaré la parte del “para” qué se quiere la historia, solo con la intención de concentrarnos en lo fundamental.

Independiente

En la medida de lo posible, las historias se pueden implementar en cualquier orden.

La historia del Comprador no se podrá implementar hasta tanto no estén establecidas todas las condiciones de venta que el Vendedor requiera. Y esta historia solo es verificable en cuanto a instituir y preservar las condiciones de venta, pero no en cuanto a hacerlas cumplir por el comprador. Las cosas así, es posible eliminar la dependencia, dividiendo las historias de usuario usando como criterio las distintas condiciones de venta del producto, desde el punto de vista del Vendedor, además de combinar el establecimiento de los términos de venta con algunas condiciones para hacerlos cumplir en cada historia.

Negociable

Se deja abierta la forma de lograr el objetivo, sin sugerencia de implementación.

La historia de usuario original no deja ningún margen al diálogo en cuanto a las posibilidades de implementación de las formas de pago, es la indicada y nada más. En cambio, la historia derivada abre las posibilidades y permitirá que se tomen las mejores decisiones para su confección mediante conversaciones sucesivas.

Valiosa para el usuario

Algo que el usuario realmente pueda usar, no solo una tarea técnica.

Hasta tanto las imágenes del producto puedan usarse, no tienen ningún valor y, por consiguiente, la historia de usuario en sí carece de trascendencia, de peso (alias de valor). No proporciona ningún beneficio. El impacto de su contraparte, sin embargo, es a todas luces evidente. El valor de la historia salta a la vista.

Estimable

No se requiere investigación, bien entendida.

¿Cuántos informes son? ¿Cuáles? ¿Con qué información o datos? ¿En qué momento se producirán? Estas y algunas otras cuestiones sin respuesta aparente no permitirán que la historia de usuario pueda estimarse en complejidad o tamaño, mucho menos en tiempo. La historia contigua, en cambio, goza de mayor precisión: es una única lista, un informe solo de productos entregados; estas condiciones reducen las posibilidades y aumentan los detalles necesarios para realizar una predicción más o menos confiable sobre cuándo podrá estar terminada.

Pequeña

Se puede pasar del concepto a estar preparada para su lanzamiento en un par de semanas y preferiblemente dentro de un par de días.

Como con el caso de la historia no estimable, no conocemos la cantidad ni la calidad de los informes a los que se refiere esta historia. El informe resumido por categoría de producto, por su parte, es algo mucho más acotado: es uno solo, su carácter de “resumido” ya deja entrever que los datos que incluirá son pocos. Tiene visos de ser una historia que se pueda implementar en dos o tres días de una iteración.

Comprobable

Es posible medir algo específico para verificar que la historia está terminada.

¿Qué significa “rápidas”? ¿45 segundos? ¿27? ¿Un milisegundo? No hay forma de verificarlo, no será posible probar los términos de esta historia, ni siquiera con los mejores robots de prueba existentes hoy. En general, “rápido” es una expresión ambigua, imprecisa. Si decimos “2 segundos”, la ambigüedad desaparece de inmediato. Unos pocos casos de prueba nos permitirán comprobar la completitud de la historia.

 

¿Quieres saber más sobre historias de usuario?

En octubre estaré facilitando un curso donde te contaré de mis experiencias en este y otros asuntos sobre lo esencial de las historias de usuario. Encuentras más información en:

https://luchosalazar.com/portfolio/nuevo-curso-historias-de-usuario/

¡Te espero!

 

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.