Guillem Hernandez Sola

Cuando queremos construir una buena base de conocimiento a partir de una historia de usuario, entonces necesitamos hablar sobre las personas, las necesidades de las partes interesadas, el contexto del uso del producto, el dominio comercial, las restricciones, la disponibilidad de datos, etc.

{"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/EhRJdjTNBk4.jpg?itok=eycq-7qW","video_url":"https://www.youtube.com/watch?v=EhRJdjTNBk4","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} La idea de este video es obtener algunas prácticas concretas de trabajo en línea, desarrollar algunas habilidades y reunirse nuevamente y compartir nuevos conocimientos y preguntas. Como saben, el mundo ha cambiado abruptamente. Profesores, docentes y trabajadores de todo el mundo están trasladando su trabajo en línea. Para algunos, es fácil, hemos estado ensayando para esto de facilitar en línea o trabajando con equipos distribuidos durante los últimos años. Para otros, es un cambio aterrador. En el video espero que os ayuda a ver cómo poder facilitar de manera remota.

Scrum está dirigido a un único Producto producido por un solo Equipo Scrum. Dos equipos, y a veces tres, pueden usar Scrum para desarrollar un solo producto. Pero a medida que se agregan más equipos, los equipos necesitan un poco más que Scrum para administrar sus dependencias entre equipos para garantizar que puedan ofrecer incrementos de productos que funcionen.

La realidad actual nos ha llevado a acelerar muchas decisiones. A veces esas decisiones no son las más deseadas. En estos 2 meses se han visto cosas que no lo asumíamos que eran posibles. Y aún mejor hay muchas más por llegar. Os voy a explicar la reinvención que hemos tenido para seguir dando valor. Todo empieza el 14 de Marzo de 2020. Ese día terminamos el último Professional Scrum Master presencial que hemos dado. En la típica escena donde recopilamos todo el material generado empiezo a hablar con uno de los asistentes. Los que habéis estado en una experiencia presencial, creamos del orden de 60 posters con el contenido del curso. En ese momento, estaba solo en CDMX y no tenia plan de dónde ir a pasar la noche. Con uno de los asistentes pactamos ir a tomar una cerveza. En esa cerveza hablamos de como había ido el curso, de cómo estaba diseñado para hacer un cambio de mentalidad de gestión tradicional a ágil. Además estuvimos hablando mucho de cómo se respaldaba en la experiencia presencial. De esa conversación se desprendió una frase que dije que no voy a olvidar. "No tengo ni idea, de cómo reproducir lo que has visto en forma virtual o remota. Tengo autorización de Scrum.org para realizar el curso pero aún no sé cómo lo voy y cómo la gente lo va a recibir". En esos días, CDMX no había entrado aún en cuarentena o confinamiento completo. Aún se podrían encontrar mascarillas o geles hidroalcoholicos. En cambio, cuando llamaba a Barcelona se había empezado a cerrar todo y a empezar un confinamiento completo. Inicio de una histeria colectiva. Un confinamiento completo implica no salir de casa. Reducir la movilidad y sobretodo no ir a la oficina. Pensando que me dedico a montar formaciones, acompañar equipos que normalmente están en oficinas y hacer consultoría de agilidad de negocio siendo externo en las organizaciones estaba totalmente vendido. No podía seguir con mi actividad. Como la gran mayoría de negocios, un confinamiento no te deja operar de manera habitual. Así que nos tuvimos que reinventar a virtual y remoto. De la noche a la mañana. Cómo la mayoría de mortales. Así que empezamos a pensar y plantearnos muchas cosas. Pensar es lo que nos hace más competitivos. Es lo que nos hace seres humanos. El mercado en el que estábamos ha cambiado por completo. Si queríamos seguir adelante nos teníamos que transformar. Tendríamos que empezar a hacer cosas que no pensábamos a inicios de año. Pues habiendo asumido esto, empezamos a experimentar. No teníamos nada que perder. Me empecé a involucrar de manera activa en muchos webinars y actividades online que encontraba. Fui a meetups de todo el mundo sobre facilitación online. Atendí workshops. Me involucré en la evolución de los cursos de Scrum.org a remoto. Empecé a empaparme de lo que la propia gente comentaba. A partir de ahí empecé a construir lo que tenia que ser el presente de mi actividad. Ese presente pasa por varios puntos y uno de los que más me preocupa es que la gente que se involucra con nosotros siga gozando del mismo valor que aportábamos con la experiencia presencial. Uno de los KPI que seguimos habitualmente es el número de personas que aprueban los assessments de nuestros cursos. Nos preocupa fuertemente que la experiencia online aporte el mismo valor que la presencial. Ahora mismo, comparando los datos que tenemos de los 2 últimos meses con los datos que tenemos de 2 últimos meses presenciales, vemos que nuestra tasa de éxito es mejor en el online que en el presencial. Más estudiantes superan los assessments en nuestros experiencias online. Personalmente pienso que la experiencia online es mucho más estructura y ordenada que la experiencia presencial. A parte de eso, se puede atender des de cualquier punto del mundo, des de tu propio escritorio. El futuro ha llegado muy rápido y nuestra entrega de valor se ha adaptado a los tiempos. Los tiempos pasan por acercarte a los estudiantes y clientes. A darles contenidos de valor, a guiarlos, a ayudarlos. A estar en tu escritorio, en tu casa más cerca de ti. Por eso hemos intensificado el sentido de comunidad. Porqué a la gente, la salva la gente. Y si no creamos comunidad, si no nos ayudamos entre nosotros, no vamos a evolucionar. Si no construyes tu sueño, alguien más te contratará para que lo ayudes a construir el suyo.

User Story Mapping permite a los gerentes de producto, desarrolladores y diseñadores poner un método detrás de la continua complejidad del diseño del producto y crear una experiencia de usuario (UX) increíble. La técnica fue introducida originalmente por Jeff Patton (Product Design Coach) como un cambio de pensar en las características a los usuarios y sus necesidades. El poder de contar historias es una excelente manera de asegurarse de que su equipo tenga una comprensión compartida de qué construir y por qué. Además, esta técnica proporciona una imagen mucho mejor visual que un Product Backlog En este video verás cómo realizar un User Story Mapping guiado. {"preview_thumbnail":"/drupal/s3fs-public/styles/video_embed_wysiwyg_preview/public/video_thumbnails/XnqvAWM4S1o.jpg?itok=G73NFW_z","video_url":"https://www.youtube.com/watch?v=XnqvAWM4S1o","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Pero hay una mejor manera de dar sentido a tu product backlog, priorizar lo que debe hacerse y mantener la visión del producto más amplia al frente y al centro. El mapeo de historias de usuario es un ejercicio simple y colaborativo que lo ayuda a definir el viaje de su usuario con su producto, dónde existen vacíos y qué podría ser. En otras palabras, es una forma de salir del purgatorio de priorización de funciones y, en cambio, mantener las necesidades de los usuarios y los casos de uso reales al frente y al centro. Estos mapas de historias muestran flujos de trabajo reales. En lugar de priorizar todas las historias de usuarios más pequeños, los mapas de historias permiten ver todo dentro del contexto de sus objetivos comerciales generales. Esta práctica te ayuda a facilitar este proceso

{"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/wKPIgLuSgww.jpg?itok=nZWneVdm","video_url":"https://www.youtube.com/watch?v=wKPIgLuSgww","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Contesté a la petición que me llegó: "Otro punto es que he invitado a algunas personas a participar de los webinar y no tienen conocimientos muy amplios de scrum podrías realizar un webinar de fundamentos y conceptos básicos para emparejar conocimiento." Ha sido un webinar de fundamentos y conceptos básicos de Scrum. Además lo traté en 1 bloque didáctico y en un 1 bloque dedicado a preguntas de los participantes. Después del webinar, los participantes recibirán el video del mismo y unos materiales digitales para empezar la transformación hacia la agilidad. Aquí está el material de descarga de la presentación Recordad que Scrum se basa en: El desarrollo incremental de los requisitos del proyecto / producto / servicio en iteraciones temporales cortos y fijos (iteraciones de menos de 30 días). La priorización de los requisitos por valor para el cliente y coste de desarrollo en cada iteración. El control empírico del proyecto / producto / servicio. Por un lado, al final de cada iteración se demuestra al cliente el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en función de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las inspecciones y las adaptaciones necesarias. La potenciación del equipo, que se compromete a entregar unos requisitos y para ello se le otorga la autoridad necesaria para organizar su trabajo de manera autoorganizada. La sistematización de la colaboración y la comunicación tanto entre el equipo y como con el cliente. También el alzamiento de los valores de Scrum. El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir resultados. Espero que sea de vuestro agrado y os haya ayudado el webinar de "Fundamentos y conceptos básicos de Scrum".

Tu organización quiere ser ágil. Lo entiendo. Pero cada vez que un líder empresarial me dice que quiere ser “ágil”, mi primera pregunta es: “¿Por qué? ¿Qué significa eso para usted? ¿Y cómo sabrá si está progresando? “¿Hacer agilidad o ser ágil? Las transformaciones ágiles reales son difíciles … realmente difíciles. Requieren fortaleza organizativa, opciones difíciles de priorización y confianza institucionalizada. Además un equipo de líderes que esté dispuesto a alentar constantemente los pequeños fracasos. Podemos decir que hay 3 fases de agilidad: Conocer la agilidad (Knowing Agile) Hacer agilidad (Doing Agile) Ser ágil (Being Agile) Knowing Agile proporciona información académica sobre agilidad empresarial y las prácticas ágiles. Se empieza con capacitación y educación de la organización. A menudo incluye cierto nivel de certificación o reconocimiento de que algunas capacitaciones se han completado. Por lo general, no incluye conocimientos prácticos o experiencia. Doing Agile es practicar rituales y ceremonias ágiles. Las reuniones de pie, las demostraciones y revisiones quincenales, la planificación del sprint, los tableros Kanban y los puntos de la historia. Todos estos elementos son indicaciones claras de “Doing Agile”. Pero simplemente realizar algunas prácticas que se reconocen como Agile no se traducen en un entorno de trabajo ágil, en equipos de alto rendimiento, en mejor calidad o en un tiempo de comercialización más rápido. Ser ágil (Being Agile) realmente funciona de manera diferente. Incluye una estructura de toma de decisiones drásticamente nueva, participación empresarial totalmente integrada, equipos persistentes autoorganizados y multidisciplinares. Además el enfoque es en el producto (no proyecto), usando DevOps y una cultura totalmente pensada en el aprendizaje continuo. En definitiva, significa convertir esos rituales en hábitos diarios que impulsan la acción de mejora continua. Esto es más que hacer agilidad, ser ágil es lo que es. Preparación Algunas de las prácticas que recomendamos antes del lanzamiento de un programa de transformación ágil incluyen: Cambiar a una estructura organizacional basada en el producto. Los productos gobiernan el mundo y el software se come al mundo. Es probable que el software active o abarque prácticamente todos los aspectos de su negocio, y eso es algo bueno. Incluso los productos y modelos comerciales más tradicionales se han visto alterados y digitalizados en las últimas dos décadas. Ya ni os cuento por la COVID-19. Piensa en cada equipo de producto su trabajo como líder sénior es potenciar, nutrir y hacer madurar a tu organización. Fondo de innovación. A menudo, además de los equipos de producto, las organizaciones necesitan financiar un laboratorio de innovación, un estudio de diseño o un equipo similar que pueda incubar ideas y características del producto. Algunas de las cuales se convertirán en nuevos productos y otras terminarán descartados. La clave es que se les dan los recursos y la libertad para ser creativos. Capacitar a todos en su organización en Agile, en serio, a todos. Se empieza con un curso simple de dos días, y ampliamos para que todos estén capacitados en la nueva metodología y las formas de trabajar dentro de los seis meses por lo menos. Desarrolle un plan de estudios basado en roles que permita una progresión gradual y un modelo de adopción a largo plazo. Implemente un nuevo conjunto de métricas mirando aterrizar los objetivos. Los resultados clave son las métricas de valor que deben rastrearse. Se derivan de sus temas / objetivos estratégicos y tienen resultados específicos con objetivos (números fijos) que se pueden medir. Implementación Una vez que se ha desarrollado la idea de transformación ágil, hay un conjunto de prácticas que facilitarán una implementación exitosa: Lanza nuevas funciones de productos con mayor frecuencia, a menudo más rápido de lo que te sientes cómodo. La entrega de ciclo corto es uno de los principios más importantes de Agile. No es mini cascada. Los lanzamientos trimestrales no son de ciclo corto. Cada dos semanas (o más frecuentemente) mínimo es la entrega de ciclo corto a la producción. En última instancia, fracasará rápidamente y fallaremos en pequeño. Abraza DevOps. Una inversión en herramientas e integraciones de DevOps proporciona la grasa que hace girar las ruedas. Las capacidades de DevOps y la integración continua / implementación continua (CI / CD) permiten a los equipos lanzar funciones de manera predeterminada y disciplinada, esto minimiza las fallas, automatiza las pruebas, satisface los requisitos de auditoría y predice posibles problemas con un plan de retroceso documentado. Expansión y mejora A medida que la transformación se expande y madura, deja de hacer agilidad, ser ágil es en lo que se transforma. Hay varias prácticas que pueden emplearse para ayudar a las organizaciones a mejorar: Confía en tus equipos. Direccionalmente, el liderazgo sénior establece los objetivos estratégicos, pero los equipos autoorganizados y autoempoderados (liderados por Products Owners autónomos y autorizados) determinarán los mejores enfoques, arquitecturas técnicas y todo el “cómo” a desarrollar, probar y lanzar. Esto significa que no hay más comités directivos. Los problemas se resuelven en el nivel más bajo posible (nivel de equipo). Practica la transparencia. Esto se aplica a todo en lo que trabaja el equipo. La transparencia debe ser un mantra para todos los equipos ágiles, así como para su liderazgo. Todos los entregables son trabajos en progreso, por lo tanto, deben estar abiertos para inspección en todo momento. La clave es que los Product Owners establezcan expectativas con el liderazgo superior sobre la naturaleza de esos entregables y cómo se entregan. La mejor medida de progreso es el incremento de trabajo disponible para los usuarios. Gestionar los indicadores de progreso de manera diferente. Dejamos de administrar por informes de estado y eliminamos los mandatos basados ​​en fechas. Podemos seleccionar objetivos de lanzamiento de productos e hitos, pero no serán de alcance fijo; serán de naturaleza más temática sin características específicas completamente definidas. Los radiadores de información son increíblemente importantes. La transparencia es un principio básico ágil y, como tal, debe integrarse en cada transformación. Para aquellos que son habitualmente ágiles, ver errores rápidamente es una prueba de que estás aprendiendo, mejorando constantemente y acercándote a tus clientes. Aquellos que piensan en una mentalidad ágil ponen la confianza y la transparencia por encima de todo en su cultura. Entonces, mírate en el espejo y pregúntate si eres realmente ágil, o si simplemente estás haciendo postureo. Porqué puede ser que no te valga solo hacer agilidad, ser ágil es lo que tienes que ser. Foto Kelly Sikkema en Unsplash

No sé sobre el resto de ustedes, pero personalmente siempre promociono Professional Scrum cuando hablo, enseño, entreno, asesoro, etc.

En la reunión del Manifiesto Ágil en 2001, se escribió un conjunto de 4 valores respaldados por una docena de principios. Esto era el inicio de lo que es Agile. Hubo 3 expertos en Scrum presentes y los 4 fundadores de eXtreme Programming. Estos fueron los únicos dos procesos ampliamente implementados en el mundo real. Están relacionados porque los fundadores de ambos procesos se comunicaban en los grupos de noticias de Internet a medida que se formaban y reutilizaban ideas el uno del otro ya en 1994. Los otros expertos en la reunión, habían escrito libros y documentos sobre procesos de desarrollo más adaptables y flexibles para reemplazar el Rational Unified Process de IBM que era dominante en ese momento en software, pero demasiado pesado. Entonces Scrum y XP son los padres de Agile, y Agile no es un marco o una implementación operativa. Es un concepto abstracto no operativo. La implementación operativa de Agile en más del 80% de los equipos de hoy es una variante de Scrum. Los equipos más hábiles implementan prácticas XP dentro del Scrum. Una práctica de XP extremadamente importante implementada en los primeros equipos Scrum es la integración continua varias veces al día y el despliegue a producción al menos una vez por sprint, si no varias veces al día. Además, el movimiento DevOps ha evolucionado para promover esta práctica que formaba parte de los equipos originales de Scrum y XP. Más del 50% de los equipos "ágiles" no pueden entregar al final de un sprint y llegan tarde, por encima del presupuesto del proyecto, con clientes insatisfechos según los datos del Standish Group en cientos de miles de proyectos. Así que ten cuidado con el falso Agile y los falsos mesías de la agilidad. Espero haberte explicado la diferencia entre Scrum y Agile.

Este video refleja como un estudiante del Professional Scrum Master de Scrum.org es capaz de usar Scrum fuera de un contexto de software.