Ryan Ripley’s Post

There’s a repeating pattern I’ve noticed that I think continues to undermine the credibility of Scrum practitioners. The way Scrum, and by proxy some Scrum Masters, manoeuvre into positions where Scrum can't be blamed if anything goes wrong or organisations struggle. I see the pattern a lot and fair warning this is a bit of a parody but an attempt to cut to the heart of the paradox: Organisation: "We tried Scrum it’s not working." Scrum Master: "That’s because you weren’t really doing Scrum according to the Guide. What did you expect?" Organisation: "Ah, ok we see." So the org tightens up, follows the Guide to the letter but the struggles still materialise. Organisation: "We tried Scrum for real this time. Those problems... still there." Scrum Master: "Well yes, but Scrum is purposely incomplete, it doesn’t solve all your problems." It’s a circular defence. Heads we win, tails you lose. And from the outside, this looks like Scrum can never fail, only organizations do. That erodes trust. It makes hiring organizations sceptical of Scrum Masters, and it weakens our credibility in the wider market. Scrum can categorically fail to provide its value. And practitioners should be upfront and clear about the contexts where it provides limited or little value. But that’s not a weakness of you as a practitioner, it’s a reminder that your value goes far beyond any one framework. Scrum can get by being purposely incomplete. You can’t. The future isn’t clinging to a framework, it’s becoming the kind of practitioner who can deliver with or without it. That’s why I believe so many Scrum Masters should see the move toward Delivery Management not as abandoning Scrum, but as evolving and building on top of what you already have. Delivery Management is a catalyst to expand your toolkit, sharpen your adaptability, and become a trusted colleague organisations can rely on to guide them through complexity. Scrum gives you a solid foundation. But more growth will come from moving past rules and frameworks, into greater ownership of outcomes, driving impact, and guiding success. That’s a pathway Delivery Management opens up.

The circular debate of to scrum, or not to scrum continues! 🫠😂 Perhaps we should ask, “hows the team” before introducing frameworks that produce data, which are then made into metrics to gauage “performance” 🤷🏻♀️ 👀 Are there reoccurring themes within the team? Both positive and negatives? If so, what are they and why do they repeat? 👀Does the team understand the business goal? Has the broader strategy been offered? 👀What are the undercurrents not being spoken about and how is that effecting communication? 👀Has the team been encouraged to challenge ideas or hypothesis? “Doing Scrum well” is one thing, but it won’t get you anywhere if you don’t facilitate and serve, and develop trust within your team ✍🏻🙌🏻✍🏻❤️

💥 Polemic in Scrum: 1 Scrum Master per team vs. Scrum Mastery for everyone One of the hottest debates in Agile today is whether we need a dedicated Scrum Master per team, or whether Scrum Mastery should be shared by everyone. 👉 1 Scrum Master per Team: ✔️ Clear accountability ✔️ Focused coaching & change leadership ⚠️ Risk of dependency (“Scrum won’t happen unless SM does it”) 👉 Scrum Mastery for Everyone: ✔️ Agility becomes everyone’s responsibility ✔️ Encourages self-management ⚠️ Diffusion of responsibility (“if everyone is Scrum Master, no one is”) ⚖️ The polemic heart: • Traditionalists: “Scrum Master is a must-have accountability.” • Progressives: “True agility emerges when everyone practices Scrum Mastery.” • Corporate reality: “We often see it used as a cost-cutting excuse.” 🔑 My view: depth matters. Without dedicated Scrum Mastery expertise, agility risks becoming theater. But over time, the best teams absorb mastery as part of their DNA. 👉 What do you think? • One dedicated Scrum Master • Scrum Mastery for everyone • A hybrid approach Let’s discuss 👇

Overcommitting Scrum Teams: Speed or Illusion? Recently, I observed a Scrum Team being assigned 120%+ of their capacity every sprint. The intent was to satisfy urgent client demands, but the result was the opposite of agility: best practices were ignored, velocity lost meaning, and morale declined. On the surface, this might look like urgency. In reality, it undermines agility and creates bigger risks: • 📉 Velocity data loses meaning when commitments are unrealistic. • 🛠️ Quality drops as shortcuts replace good practices. • 🔥 Burnout and attrition risks increase. • 🤝 Trust with the client erodes when promises are missed. Agility is not about doing more in less time — it’s about delivering the highest value sustainably. ✅ Recommendations for Product Owners: • Respect the team’s actual capacity and velocity. • Prioritize ruthlessly — focus on value, not volume. • Use forecasting to set realistic expectations with stakeholders. ✅ Recommendations for Delivery Managers: • Support sustainable pace instead of short-term overloading. • Back your Scrum Masters in upholding agile principles. • Be transparent with clients — speed without quality is just delay in disguise. 💡 A team that works at a sustainable pace delivers trust, quality, and long-term value. Overloading may look like progress, but it’s really just setting the team — and the client relationship — up for failure.

🚫 Scrum Anti-Patterns to Watch Out For (Especially While Scaling!) 🚫 When companies scale from a single Scrum team to frameworks like SAFe, LeSS, or Nexus, the real challenge isn’t the framework — it’s the bad habits we carry forward 🙈 Here are some common mistakes that silently kill agility 👇 🧱 Scrumfall Mindset : Mixing Scrum ceremonies with waterfall thinking = 🚨 Planning like agile, executing like waterfall. 🎩 Command & Control Leaders : Telling teams what and how to do it ➡️ Kills innovation, ownership, and agility 🤖 📅 Meetings > Outcomes : Daily Stand-ups become status meetings ✅ PI Planning becomes a calendar event 📆 and Retros become a checkbox ✅ 🚪“Too Many Cooks” : Multiple Product Owners or Scrum Masters = RACI confusion 🤯 One product, one owner please! 🐌 Heavy Governance in the Name of ‘Scaling’ : More layers = slower flow ⛓️. Scaling should enable speed — not bureaucracy ⚙️ 🔌Disconnect from User Value : Teams get busy delivering features... but forget about real customer outcomes ❤️ 🛠️ Framework-Specific Pitfalls 🛠️ ✅ SAFe: Too much top-down control? Decentralize decision-making! ✅ LeSS: Struggling with coordination? Focus on feature teams, not component silos! ✅ Nexus: Integration hell? Strengthen the Nexus Integration Team! 🚀 The Bottom Line Scaling Scrum isn’t about adding more rules—it’s about removing barriers to agility. Are you scaling effectively, or just scaling problems? 🔥 Pro Tip: Scaling frameworks are powerful only when we protect the core Scrum values — Focus, Openness, Respect, Courage & Commitment 💛 👉 “Don’t scale chaos. Scale agility.” 💬 Curious to know — Which anti-pattern do you see the most while scaling Scrum? Comment below 👇👇 #Scrum #Agile #SAFe #LeSS #Nexus #AgileTransformation #DevOps #ProductManagement #Leadership #AgileCoaching #ScrumMaster #ProductOwner #AgileTeams #ScalingAgile #AgileMindset #ContinuousImprovement #Sprint #TechLeadership #SoftwareDevelopment #LeanAgile #AgileFramework #BusinessAgility #Teamwork #AgileDelivery #DigitalTransformation #ITLeadership #AgileCulture #ScrumAntiPatterns #AgileFailures #TechTrends

Project managers aspiring to be Scrum Masters must view the Team Performance domain differently. In Scrum, it’s less about directing teams and more about fostering a self-managing, collaborative group with shared ownership. Challenges in Transition: - Command-and-Control Leadership: This traditional approach can impede the development of self-managing teams essential in Scrum. - Fixed Role Mindsets: Adherence to rigid project roles can limit the cross-functional collaboration needed in Scrum Teams. Leveraging Your Skills: - Vision Communication: Articulate clear vision and objectives to align team members and support the Product Owner. - Empowering Team Dynamics: Use your experience in fostering trust and collaboration to build a high-performing Scrum Team. - Interpersonal Skills: Apply critical thinking and interpersonal skills to guide the team in the Scrum environment. Transition Steps for Project Managers: - Promote Shared Ownership: Encourage collective ownership over individual contributions. - Cultivate a Self-Managing Team: Develop a team culture of trust, collaboration, and empowered decision-making. - Adapt Leadership Style: Shift from directive to supportive, mentoring, and facilitating roles, recognizing each member’s unique contributions. Conclusion: Transitioning to a Scrum Master requires redefining team management approaches, nurturing a high-performing, self-managing team that embraces Scrum values. Your project management experience, coupled with a new mindset, can drive this transformation. Next Steps: Reflect on your current team management practices and adapt them to enhance a Scrum Team’s performance. Interested in more? Watch out for upcoming posts. Don't want to miss any of these posts? You can have them weekly in your mailbox via https://lnkd.in/eVakPKBC Join us on a journey of transformation and agile leadership in Scrum. #Scrum #Simplification #BoostYourScrum #AgileProjectManager

"Do we still need Scrum Masters?" Today, I spoke with a group of Scrum Masters who wanted to know: What's next for Scrum Masters? To find a good answer, I went back in time, and we discussed: Where did the Scrum accountabilities come from in the first place? The Product Owner role is based on the concept of a chief engineer, who is the overall responsible designer of an airplane. Jeff Sutherland was inspired by the chief engineer role at Toyota (the shusa). Toyota created this role when Tatsuo Hasegawa joined the company after WWII. He was an aircraft engineer before that. After the war, Toyota hired 200 aircraft engineers for this purpose. Aircraft designers had a unique approach to design. They worked with trade-off curves. These curves captured knowledge about the characteristics of materials and processes used. The engineers were inspired by Wilbur and Orville Wright. Their journals and letters contain a great deal of data and curves resulting from their experiments. The Wright brothers learned this method from Otto Lilienthal, who learned it from his professor, Franz Reuleaux. Thus, the concept of a Product Owner has a long tradition. Scrum masters need to teach this forgotten knowledge. The Scrum Master role was inspired by Taiichi Ohno, who was responsible for production at Toyota. If you go back in time, you will discover the TWI (Training Within Industry) program. This famous series of trainings helped the United States produce enough airplanes, cars, vans, and ships during WWII to combat Nazi Germany and Japan. The program consisted of several training sessions aimed at preparing people for their jobs, improving job relations, and enhancing work processes. The TWI program was later revived in Japan. Ohno was a TWI trainer, too. Channing Rice Dooley, the mastermind behind the TWI program, was also responsible for training craftsmen for the army during WWI. Dooley was part of a vibrant global scientific management community. At the end of the 19th century, factories began to grow in size. Entrepreneurs, engineers, and accountants discussed how to organize larger companies. The scientific management community had good ideas. Thus, Scrum Masters stand in the tradition of scientific management. They are organizers, middle managers, trainers, and creators of real teams. Do we still need good products and services? Do we still need organizers? I think so. The names may change. But the concept of a Scrum Master will endure.

Jan Fischbach joined us for our workshop day today.   Thank you for your time, expertise and energy 💯   Your input sparked a productive discussion about how we adapt to changing work environments and market needs as Scrum Masters.   One of the main takeaways is probably that Scrum is only one step in an evolutionary process.   As Scrum Masters, we learn to be flexible. We redesign workflows to increase deliverability, promote the use of empirical research and develop effective teams. But more than that, we become catalysts for change.   Scrum may be a framework, but the values it nurtures - collaboration, transparency and adaptability - are timeless. These values will only become more important as our work environments evolve.

The thing is, the more I go, the more I realize how important it is that the scrum masters themselves are well educated in lean and agile. A scrummaster that has never done a value stream mapping for her team can hardly be spoken of as scrummaster, can she. A lot of scrummasters out there think they have got it, they have understood PDCA and can facilitate the scrum ceremonies. What I like about #SAFe is the enrichment of the SM role with a treasure of lean and agile techniques to really provide them with tools to improve their teams. So, in a sense, Scrum is not enough, but its spirit must be carried on, though scrum in itself hardly gives the hardcore tools for the job. These in turn can be found more easily in the body of knowledge gathered in SAFe. It’s a lifelong job to do it well. But boy, what impact can a scrummaster have, if they are well educated and know where they go…