Welcome to the Home of Scrum! ™

We spend a big part of our workday either participating in or facilitating workshops. As Scrum Masters, we facilitate the Sprint Events. We facilitate Scrum Team decisions and support collaboration within, between, and external to Scrum Teams. As Product Owners, we engage with our customers and conduct requirement workshops, gauge market interest - often with very diverse and varying stakeholders. As Developers, we drive technical excellence by collaborating and communicating with other developers - in workshops. And also as agile leaders workshops are an integral part of our workday trying to foster environments in which self-management and accountability can grow. In this blogpost we will dive into a practice you can use to kick off workshops. A practice to set the tone, to spark impulse, to invite for change and forward momentum: Using videos to kick-start a crucial conversation. By the end of your reading, you will have an idea of why showing a video to kick-start a conversation might be fruitful to your context. Besides that, you will have a pool of thought-provoking videos, ready to use in your next workshop. Using videos for sending educational content An obvious reason for using videos is that it is a brilliant way to transfer information. Not only does it help against zoom fatigue we also know that people learn best when they take in information via multiple modalities - through reading, drawing, listening - and viewing visual media. Using media illustrates a topic without having you draw, talk or gesture anything. Scrum.org's own educational video on Scrum is a good example of this. Short, concise, animated, and to the point – in this case, an overview of Scrum. {"preview_thumbnail":"/drupal/s3fs-public/styles/video_embed_wysiwyg_preview/public/video_thumbnails/gy1c4_YixCo.jpg?itok=ZJz78rcJ","video_url":"https://youtu.be/gy1c4_YixCo","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Using videos to set the stage Showing a video is not only about sending content. Showing a video at the start of the workshop also elegantly sets the stage. It sets the tone of the conversation. It introduces a topic without unnecessary opening blah-blah. You jump right into it and let the audience settle in. It gives you as a facilitator the opportunity to step back, watch the audience's reaction to the shown content and kick-start the conversation and reflection. Provide external ideas As an example: in my leadership and Scrum Master classes, I like to show videos of external and acknowledged leadership experts, such as David Marquet, a former US submarine commander, and Jürgen Klopp, champions league winner and charismatic football coach with FC Liverpool. {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/ivwKQqf4ixA.jpg?itok=KuMRmrYf","video_url":"https://youtu.be/ivwKQqf4ixA","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/pxh9O8MfNDQ.jpg?itok=aFNl8B6r","video_url":"https://youtu.be/pxh9O8MfNDQ","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} By letting these experts explain their leadership style, you may then ask the audience in the workshop to listen and compare their experience to the experience of the experts. These external, industry acknowledged perspectives provide structure and impulse for the participants to use and apply them to their own, internally observed behavior. It invites for deep reflection, serious conversation, and creative application of out-of-the-box thinking ("How would Jürgen tackle our situation?"). Invite for thinking outside the box By referring to these external expert voices it is also often easier for the participants to pinpoint and surface things that might be more sensitive to be addressed otherwise. Participants can externalize internal observations and talk about someone else first, then map the external situation back to them in a later step. By comparing the shown video to the participants' current context, it is then often easier to specify what they need more of or less of; what they want to start, stop or continue doing. Interested in some reflection questions to get your next conversation about leadership started? Consider the following: What does leadership mean for David Marquet / Jürgen Klopp? What did surprise you w.r.t their way of leading people? What is important for the leader in the video? Why? Why do people follow them? What do you think? Which of the depicted content is missing in our context? What would be beneficial to try in our context? How? You will be surprised how many different perspectives, interpretations, and details are observed by the audience – although all of them watched the same video! Provide a metaphor and visual language Videos do not need to be dead-serious to be used in professional workshops. On the contrary, videos can give a wonderful opportunity to blow off some steam, to have a good laugh – and nevertheless use the videos' insights for a good follow-up conversation and deep reflection. {"preview_thumbnail":"/drupal/s3fs-public/styles/video_embed_wysiwyg_preview/public/video_thumbnails/BKorP55Aqvg.jpg?itok=uAtaV1rf","video_url":"https://youtu.be/BKorP55Aqvg","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} You might have seen the Expert video already. Or know the "Peanutbutter Jelly Sandwich Challenge". {"preview_thumbnail":"/drupal/s3fs-public/styles/video_embed_wysiwyg_preview/public/video_thumbnails/cDA3_5982h8.jpg?itok=_d0BIn8O","video_url":"https://youtu.be/cDA3_5982h8","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} I love to use both videos to talk about a dead-serious challenge in agile project and product development initiatives: stakeholder management and agile requirement engineering – while not forgetting to laugh about the painful absurdities conventional requirement engineering techniques and behaviors may lead to. As an example: by showing those videos you may establish a metaphor for how agile requirement engineering should not work (over-specification by focusing on documentation: the peanut butter jelly sandwich :-)), preparing the space on how it could work (e.g. face-2-face conversation, collaboration, closed feedback loops and the like) Have fun Last but not least, videos are an elegant way to reconnect after a break, refocus on the topic, and not take it too seriously and have a good laugh and a lighter approach to the sometimes quite serious problems to tackle in a workshop. Some of my personal favorites for the lighter side to reconnect e.g. after a heavy meal are The phobia workshop {"preview_thumbnail":"/drupal/s3fs-public/styles/video_embed_wysiwyg_preview/public/video_thumbnails/koNwUeG-iKE.jpg?itok=d8b3NwN1","video_url":"https://youtu.be/koNwUeG-iKE","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Shit bad Scrum Masters say {"preview_thumbnail":"/drupal/s3fs-public/styles/video_embed_wysiwyg_preview/public/video_thumbnails/GGbsgs611MM.jpg?itok=HJa5iDUU","video_url":"https://youtu.be/GGbsgs611MM","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Timo Wopp on complexity (German) {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/u-H4-iP2Lfo.jpg?itok=4JVN5W4r","video_url":"https://www.youtube.com/watch?v=u-H4-iP2Lfo&t=135s","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} The impatient Product Owner (feat. Seinfeld) {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/BTTdHW8Z668.jpg?itok=NY3rsL92","video_url":"https://youtu.be/BTTdHW8Z668","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} More to watch Want more video ideas? Go get some on my blog here (The blog is in German, the referenced video sources are usually in English) 3 videos about leadership 3 videos about agile requirement engineering 3 videos about complexity/systems thinking 3 videos about flow An updated and curated list of (agile) videos at marckaufmann.com How about you? Which videos inspire you? Which videos do you use? Which of the videos above do you plan to use? In which context? Let me know by commenting below!

TL; DR: Three Wide-Spread Stakeholder Failures There are plenty of Scrum stakeholder failures. Given that Scrum is a framework with a precise and concise yet short “manual,” this effect should not surprise anyone. While the Scrum Guide makes numerous references to stakeholders in Scrum, stakeholders themselves are no official role (accountability), no matter their crucial contribution to a Scrum team’s overall success. Explore with me three widespread examples of how stakeholders fail their Scrum teams in three short video clips, totaling 6 minutes and 5 seconds. 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 31,000-plus other subscribers. 🎓 Join Stefan in one of his upcoming Professional Scrum training classes! Join more than 210 peers from May 27-29, 2021, for the Virtual Agile Camp Berlin 2021, a live virtual Barcamp using open space technology principles and practices. The Scrum Guide on Stakeholders Let’s refresh our memories regarding stakeholders according to the 2020 Scrum Guide. While stakeholders are not an official accountability, the Scrum Guide makes numerous references to stakeholders in Scrum: Page 4: The Scrum Team and its stakeholders are open about the work and the challenges. Page 5: The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. Page 6: The Product Owner is one person, not a committee. Page 6: The Product Owner may represent the needs of many stakeholders in the Product Backlog. Page 6: Those wanting to change the Product Backlog can do so by trying to convince the Product Owner. Page 7: The Scrum Master serves the Product Owner in several ways, including facilitating stakeholder collaboration as requested or needed. Page 7: The Scrum Master serves the organization in several ways, including helping employees and stakeholders understand and enact an empirical approach for complex work. Page 7: The Scrum Master serves the organization in several ways, including removing barriers between stakeholders and Scrum Teams. Page 8: The Scrum Team may also invite other people to attend Sprint Planning to provide advice. Page 8: [Sprint Planning: Why is this Sprint valuable?] The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. Page 9: The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. Page 9: During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. Page 10: The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Page 10: These [Artifact] commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders. Page 12: However, an Increment may be delivered to stakeholders prior to the end of the Sprint. Page 12: The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. Source: The Scrum Guide on stakeholders. (This aggregation is from the Scrum Guide 2020 Reordered.) Three Wide-Spread Stakeholder Failures Let me point at three Scrum stakeholder failures that have the potential to derail your organization’s attempt at achieving business agility with Scrum: Turning the Sprint Review into a Stakeholder Approval Instance In my experience, the Sprint Review acceptance gate by stakeholders is an anti-pattern typical for organizations that are still rooted in the industrial paradigm, exercising command & control. Some of the reasons for this anti-pattern are: A “my budget, my feature” attitude on the stakeholder side. The Scrum Team is seen as an internal agency, delivering requirements issued by the stakeholders. The organization probably follows a metered funding approach, for example, providing a budget for the Scrum Team’s development effort only for a short period. There is a general lack of trust in a Scrum Team’s ability to manage itself successfully. Middle managers might even fear becoming obsolete after a successful agile transformation and try to stay their ground. Generally, this example among stakeholder failures is a sign for an agile transformation that is not fully supported by all stakeholders. {"preview_thumbnail":"/drupal/s3fs-public/styles/video_embed_wysiwyg_preview/public/video_thumbnails/CSYSDED4C-U.jpg?itok=9YEgY0Yy","video_url":"https://youtu.be/CSYSDED4C-U","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Coders Code; They Don’t Talk to Customers Adhering to the inherited functional silos, Developers are supposed to deliver “code” and only code. They are not supposed to talk to customers or take over customer support duties to understand their problems first-hand. From my perspective, that is pure Taylorism at work, entirely output-oriented. The problem is, we are no longer assembling Model-Ts. But we go every day, where no one has ever gone before. In a complex environment, those closest to a problem are best suited to make the right decision to solve it. Hence, it becomes necessary that all Scrum team members talk directly with customers to understand their challenges better and avoid the misallocation of the Scrum team’s development time. (My rule of thumb: Coding is no more than 50 % of the whole effort of creating value for our customers. The best way to increase the productivity of a Scrum team is to avoid building unnecessary stuff. Now, guess how you can best address this issue? Right: Developers talk to customers.) {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/oGE0hlHbkrM.jpg?itok=K3X5eOpx","video_url":"https://youtu.be/oGE0hlHbkrM","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} There Is no Failure Culture A former client of mine, a large utility company, practiced at the time a no-failure approach to promotions: A failed project on your internal record meant you would not take the next step on the career ladder. As a result, everyone played safe, which resulted in short-term orientation as not-failing became more important than innovation. Consequently, the organization was increasingly struggling to attract new (tech) talent when software started eating the world. Suppose “good” failure is not celebrated as a critical part of the learning process, and incrementalism becomes the name of the game. In that case, the Innovator’s Dilemma, as coined by Clayton Christensen, becomes a more likely fate of the organization. When resilience is a worthwhile goal to achieve, think of Netflix’s chaos monkey, failure needs to be an option. And failure needs to be openly discussed—without repercussions—so everyone can learn from the case. And as it should be, leaders need to confess first. One approach could “failure nights,” or sharing your wrong decisions from the past openly. For example, see Bessemer Venture Partners’ “The Anti-Portfolio. Honoring the companies we missed.” {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/u0B3Svz7aaY.jpg?itok=kJAchfzG","video_url":"https://youtu.be/u0B3Svz7aaY","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} The Conclusion: Three Wide-Spread Stakeholder Failures While the Scrum Guide is not honoring the crucial contribution of stakeholders for the Scrum team’s success formally, it does acknowledge their importance on numerous occasions. Interestingly, despite the severe consequences of stakeholders failing their Scrum teams, stakeholders are often not a prime focus of Scrum Masters. (Probably, because the organization is reserving the job to “agile coaches?” That would be just another anti-patterns at the organizational level.) As a result of this neglect, these stakeholder failures may create teams of mercenaries that trade time to collect a paycheque at the end of the month, which paves the path to mediocrity, not to business agility. (After all, Scrum is a team sport, and no one is benching.) What Scrum stakeholder anti-patterns have you observed? Please share them with us in the comments. ✋ Do Not Miss Out and Learn about Stakeholder Anti-Patterns: Join the 9,000-plus Strong ‘Hands-on Agile’ Slack Team I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free. 📖 Stakeholder Failures — Related Posts 32 Scrum Stakeholder Anti-Patterns Three Wide-Spread Scrum Master Failures in 5:31 Minutes—Making Your Scrum Work Three Wide-Spread Product Owner Failures in 6:09 Minutes—Making Your Scrum Work #5—Making Your Scrum Work 27 Sprint Anti-Patterns Holding Back Scrum Teams A Sprint Review without Stakeholders — Making Your Scrum Work #3

Llevo mucho tiempo recibiendo preguntas sobre Scaled Agile Framework (SAFe para abreviar), y a digo de inicio que SAFe no me parece agilidad de negocio. No es que sea un grandisimo experto de SAFe, pero si me he documentado sobre el tema. Y creo que voy a intentar dar mi humilde opinión. Primera cosa que quiero dejar clara. Si tu organización usa SAFe, alguna cosa de valor ha encontrado en SAFe. Yo no soy quién para decir si van por el buen camino o no, eres una persona inteligente que conoces el contexto de tu organización y por tu mismo verás si van o no por el buen camino. Como puedes imaginar, esto despierta bastantes sentimientos diversos. Aquí empieza mi opinión. Si el trabajo que alguien hace se centra en SAFe, mi publicación parece atacar este marco. Puede parecer un ataque personal al marco. Me siento así cuando alguien lanza un ataque a Scrum o la agilidad de negocio, así que tengo un poco de experiencia aquí. Una cosa de la que me enorgullezco es tener una mente abierta y una mentalidad en crecimiento. Todas las personas que me dan comentarios constructivos críticos con mi ideas los invito a compartir sus experiencias, casos de estudio no solo conmigo, sino en un foro público donde pueden generar más buena voluntad hacia SAFe. La mayoría lo rechaza. No quieren explicar las bondades de SAFe. Para ser claros, no compartiría mis pensamientos si sintiera que no se basan en evidencias de primera mano. Claramente, no soy la única persona que se siente así. Existe un patrón claro de profesionales respetados, líderes de opinión, consultores, agile coaches, etc., que han probado este método y han decidido que no les funciona a ellos ni a sus clientes. Mis clientes son varios, van de grandes organizaciones a startups. Diría que las grandes organizaciones están intentando implementar SAFe. Algunos están más adelantados que otros. Todos ellos están luchando por evolucionar. Estoy con ellos diariamente, semanalmente y mensualmente tratando de ayudarlos a descubrir cómo hacer que estas ideas funcionen de SAFe funcionen. Pero al fin y al cabo, lo que realmente importa al final del dia es agregar enfoque centrado en el cliente, descubrimiento, aprendizaje y corrección del curso. Según lo que les enseñan sus instructores / consultores de SAFe, no pueden ver cómo se combinan estas ideas. Francamente, tampoco tengo buenas respuestas para ellos, ya que salir del marco es una herejía en la mayoría de los casos. Desde que soy consultor en agilidad de negocio he recibido un flujo constante de preguntas entrantes sobre cómo, exactamente, se supone que SAFe se maneja. La respuesta corta es, no tengo ni idea. Si esperas que venga un consultor de agilidad de negocio en modo D10S nuestro señor Lionel Andrés Messi Cuccitini no vas por el buen camino. La respuesta un poco más larga es que todos los principios que hemos construido en clientes, en capacitación y en nuestra manera de hacer consultoria no parecen existir en SAFe. El aprendizaje y la mejora continua, el enfoque en el cliente, la humildad, la colaboración interfuncional, la toma de decisiones basada en evidencias, la experimentación, el diseño y la corrección en curso, por nombrar algunos, están visiblemente ausentes en una conversación de SAFe. En cambio, las organizaciones que adoptan esta forma de trabajo se enfocan en estructuras de equipo rígidas, rituales y eventos estrictos. Además generan una distribución desigual de los requisitos de cambio de comportamiento dependiendo de qué tan rango se tiene en la organización. SAFe bajo mi punto de vista fomentar perfiles de decisión HIPPO (highest paid person’s opinion). En resumen, SAFe no es agilidad de negocio. Es otra cosa. Dado el intenso régimen de entrenamiento que los equipos deben atravesar para obtener la «certificación SAFe», no es de extrañar que se resistan al cambio. ¡Si pasas más tiempo en formación que entregando valor! Esos perfiles fueron capacitados para trabajar de una manera muy específica, una manera enfocada únicamente en la entrega predecible, no en el aprendizaje, no en la corrección del curso y ciertamente no en la agilidad bajo conceptos como inspeccionar y adaptar. Las actividades que hacen que los equipos sean verdaderamente ágiles requieren flexibilidad en la planificación. Requieren alineación con el éxito del cliente, no un conjunto predeterminado de características. Requieren un proceso de descubrimiento continuo que inevitablemente conduce a correcciones de rumbo no planificadas. Estas correcciones «descarrilarían» en un tren de liberación en poco tiempo. Las grandes organizaciones que buscan agilidad se dan cuenta de que la incertidumbre los acompaña. Luego se aferran a la familiaridad de los procesos en cascada porqué los concideran predecibles. SAFe da la ilusión de «adopción ágil» al tiempo que permite que los procesos de gestión familiares permanezcan intactos. En un mundo de cambios rápidos y continuos, patrones de consumo de los consumidores en evolución, inestabilidad geopolítica y avances tecnológicos exponenciales, esta forma de trabajar es insostenible. Esto último que se lo pregunten a un project manager tradicional en 2020. Si trabaja en una organización grande que ha adoptado o está en proceso de implementar SAFe, pregunta qué ha cambiado durante esta transición. ¿Estás más cerca de tus clientes? ¿Cuánto tiempo se tarda en saber si ha entregado algo de valor? Aún mejor, ¿cómo mides el «valor»? Pregunta qué tan fácil sería hacer pivotar una iniciativa basada en un nuevo descubrimiento o una nueva idea. Luego, compara esas respuestas con cómo eran las cosas antes de comenzar a usar términos como «planificación de salas grandes», «PI» y «ingeniero de release train». Escalar cualquier forma de trabajar en una gran organización es complicado y desigual. Intentar aplicar un proceso general a toda la empresa, un proceso que se centra estrictamente en la entrega en lugar del descubrimiento continuo y la corrección del rumbo, solo endurece las formas tradicionales de trabajo. SAFe es convincente porque parece ofrecer una receta única para la agilidad a escala. En realidad, premia la previsibilidad, la conformidad y el cumplimiento, al tiempo que brinda a los ejecutivos una cobertura para la pregunta: «¿Cómo nos volvemos más ágiles?» Puedes estar en desacuerdo conmigo, faltaría más. Este artículo es mi humilde opinión. ¿Cuáles son tus experiencias con SAFe?

Hey! What's good this week awesome people? As for me, I have been meeting people in physical space and have started facilitating and training in person again. Still in Australia at the moment though. I am really excited to facilitate and meet people in physical space again after being in virtual world for more than a year. Anyways, I experienced something interesting. Several people in the classes I facilitated and also several managers who are my acquaintances told me that the last two vlogs I uploaded got them thinking. They all told me they wish more people in the company can respect the Product Owner's decision and empower the Product Owner to be an entrepreneur. They see their Product Owner are not more than a proxy or a middle person for the stakeholders in the company. They wondered whether it is possible to come up with guidelines for stakeholders to empower the Product Owner. I wanted to help them because I also want to see more Product Owners who are the owners of the product hence the following vlog with 8 tips for the stakeholders. Let me know if you have any other tips for the stakeholders from your personal experience by leaving comments below so we can learn from one another and support each other. Enjoy the rest of your weekend folks. {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/H2gLVhJpLGQ.jpg?itok=uX1ktSTW","video_url":"https://www.youtube.com/watch?v=H2gLVhJpLGQ","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]}