Scrum: Process, Methodology, Framework, or Something Else?

When did promoting new ideas become a bad thing in the Scrum community? 2008. That's when I suggested considering Scrum to be a partial implementation of Lean would enable you to use it better. Ken threw me off Yahoo Scrum Development Group saying I was promoting myself. I had not mentioned I taught Lean. I was merely trying to let folks know about it. 12 years later, the Scrum guide gives lip service to lean. Scrum's foundation is inconsistent with Lean. But trying to tell Scrum proponents this is a difficult one as Upton Sinclair mentioned - "it's hard to get a man to understand something when his salary depends upon his not understanding it." Tobias Mayer deleted my very related comments on this post. I do believe him when he said he didn't see the relationship. But not seeing a relationship doesn't mean it's not there. Learning new relationships is a good thing. Turning our back on them isn't. He never asked me about the relationship. The two most impactful insights I've seen in the Agile space are: 1. inherent simplicity 2. integrating how to coach into one's approach (not the light guidance Scrum proposes, but real coaching). Scrum has mostly protected those who follow it from these and other concepts by saying proponents of them are promoting themselves. See Not all Agile is equal http://bit.ly/4n5g5Sy Here's a promotion https://lnkd.in/dsJkKEw4 BTW: I was trying to explain why the way Scrum is defined will necessarily cause confusion. But that would undercut Scrum, so it is heresy.

This article gives a clear look at Scrum and SAFe. It shows their main differences, similarities, and how to use them in practice. Both frameworks are based on Lean and Agile principles. They focus on improving efficiency and teamwork. #Scrum #SAFe #Agile #ProjectManagement #Lean #ScrumMaster #AgileTransformation #SAFeAgile #TeamCollaboration #ContinuousImprovement #AgileCoaching #ScrumFramework #ScaledAgile #AgileMethodology #ProductivityTips https://lnkd.in/gJBUtvbq

Since around 2015, I have worked exclusively as a consultant for companies adopting agile methodologies. With one exception, all chose the SAFe framework over Scrum. In theory, Scrum is a far simpler concept than SAFe, and few organizations implemented SAFe fully, and even fewer truly understood it. At the management level, SAFe creates the illusion of control, albeit at the cost of excessive complexity. Scrum, by contrast, introduces the idea of the Product Owner as the “CEO of the product,” a principle I have rarely seen applied in practice. Traditional hierarchies have always persisted. SAFe implicitly acknowledges this by assigning the Product Owner a more limited role. Scrum also tends to overlook the importance of long-term planning, which SAFe addresses through Program Increment (PI) Planning, typically spanning four to five sprints. I have found these sessions particularly valuable—especially when treated as rolling PIs, updated after each sprint. Long-term planning becomes crucial in companies that develop hardware alongside software, where hardware development cycles are much longer and often less adaptable to agile practices. At the software developer level, however, the differences between SAFe and Scrum are less pronounced. As so often, the truth lies somewhere in between: in human-centered development environments, pragmatism prevails. Yet things are changing again. In recent months, we’ve gained the ability to conduct entire agile processes with swarms of AI agents (see, for instance, my article on Claude Flow at Heise). In this emerging environment, I have found that the Scrum approach, enhanced by AI-assisted, up-front PI Planning, delivers the best results. The evolution from traditional agile methods toward AI-supported collaboration marks a natural next step — one where the balance between structure and adaptability must once again be redefined. In this new context, agile principles remain relevant, but their successful application depends less on frameworks like SAFe or Scrum, and more on our ability to integrate intelligent systems with human judgment. Have fun, Rüdiger #aiagent #scrum #safe #ironic

You don't need much to make massive changes to your organization's ability to create value. I believe you need to know enough about how to think, combined with proven practices, to enable you to create improvements in your context. This is different from the popular Agile frameworks Scrum and SAFe, which take extreme approaches. Scrum takes a minimalist approach, prescribing certain practices (sprints, cross-functional teams, roles, etc.) while SAFe takes a maximalistic (and growing) approach, having a practice for everything. Ironically, both make things much harder than they should be. Scrum requires people to figure out things that are already known because they are trying to not be prescriptive in implementation details. They hypothesize that peoplel will figure things out. Ironically, although Scrum is based on empiricism and the idea of inspecting and adapting, it does not apply these thoughts to itself. SAFe goes to the other extreme and gives you a full set of practices and a supposed set of principles on which these practices are based. But, in fact, they miss key practices and don't explain how to contextualize practices to your needs. The results of Scrum and SAFe are explained away by adopting the attitude that product development is complex and we can't have a well-defined approach. But this is not true. A set of universal principles sometimes referred to as the "physics of flow" can be used to provide guidance. These are an integration of Flow, Lean, and the Theory of Constraints. These can be used to contextualize a few practices, as shown in the table. While I believe running a diagnostic is always useful, it is possible to get a quick start and then use an understanding of the physics of flow to keep improving. Quickstarts without this understanding tends to put you in boxes you can't get out of. #Amplio #AmplioLearningJournets provide universal principles, useful practices, and the means to use them in your context.

The Common Sense of Agile & Scrum – Part 10: Done Means Done How many times have you heard it? “It’s done — just needs testing.” “It’s done — we’ll deploy it next sprint.” “It’s done — but QA haven’t signed off yet.” If “done” means anything other than usable, shippable, and valuable, then it’s not done — it’s half-done. Here’s the truth: The Definition of Done isn’t a checklist — it’s a contract for quality. It’s how a team commits to consistency, transparency, and trust. Without it, velocity is an illusion and predictability is a myth. Common sense says: • “Done” without testing is just “coded.” • “Done” without review is just “assumed.” • “Done” without delivery is just “deferred.” Agility thrives on clarity. When “done” means different things to different people, you lose control of the outcome. When “done” means done-done, you build confidence — not confusion. Define it. Honour it. Because in Agile, Done is the difference between progress and pretending. #Agile #Scrum #DefinitionOfDone #Quality #DeliveryExcellence #ContinuousImprovement #Leadership #ProjectManagement #BusinessAgility

There is no single part of Scrum that is bad. It's the inseparableness of and strict adherence to all the parts of Scrum that is bad. By definition, you can't separate any parts of Scrum, as in use a subset of Scrum linked with common sense, and still call it Scrum. Not being able to call it Scrum doesn't phase me in the least, but the very notion that you can't is totalitarian and suffocating. Thus, stand-ups are not wrong or bad. Like, are you trying to tell me that if we huddle for five minutes to shore up some work to be done, and someone even dares to say "stand-up" as a noun, that we're failing? Yeah, that's just as totalitarian and suffocating as the other extreme, and it doesn't reflect an agile mindset. Stand-ups are lame and suffocating when they occur at precisely the same time every day and have an exact format and agenda, and you're expected to state things as a predefined bullet list, and your "master" tells you to be more enthusiastic when you speak. You are in a totalitarian state, not an agile software development practice. That, my friends, is bad, and I've lived it with multiple teams from my first experience with Scrum after 20 years of software practice that was already quite agile (when I had a say). I recognized the weaponization of Scrum the morning of the second day that I ever experienced Scrum. It was when I had to *report* that I wasn't able to accomplish to five things I was informed I needed to accomplish the previous day, and disappointment was expressed by the "Scrum Master" who didn't have a clue about agility or software development in general, having previously deployed Lotus Notes utilities very liberally known as "applications." Now, scale that. Enough said. Figure: Not nearly complex enough to sufficiently represent Scrum.

Yes. "Stand-ups are lame and suffocating when they occur at precisely the same time every day and have an exact format and agenda, and you're expected to state things as a predefined bullet list, and your "master" tells you to be more enthusiastic when you speak. You are in a totalitarian state, not an agile software development practice."

What is the "Definition of Done" in Scrum? 🚀 In the world of Agile and Scrum, "Done" isn't just a feeling – it's a formal agreement! The Definition of Done (DoD) is a shared understanding within the Scrum Team about the quality standards and criteria that a Product Backlog Item (PBI) must meet to be considered complete. Think of it as a checklist that ensures: Quality: The increment meets established quality standards. Transparency: Everyone knows exactly what "done" means. Readiness: The increment is potentially releasable. Without a clear DoD, "done" can mean different things to different people, leading to misunderstandings, rework, and delays. It's crucial for fostering collaboration and delivering valuable increments consistently. What does "Done" mean to your team? Share your thoughts below! #Scrum #Agile #DefinitionOfDone #ProductManagement #SoftwareDevelopment #Teamwork

I often see here discussions debating which framework is better: “Scrum is better than Waterfall.” “Scrumban is the perfect blend of Kanban and Scrum.” “SAFe is too rigid.” “Waterfall still works better for us.” “Scrum is dead.” “Agile isn’t Agile anymore.” (My commend would be that Agile is not a framework) The truth? ->Every framework can work. Every framework can fail! Processes and methodologies are valuable, but they don’t create value on their own. ! People do! A framework should serve the team, not the other way around. It should fit the team’s context, culture, and needs. As a leader, your priority isn’t to pick the “right” framework, it’s to support your people, help them grow, and create conditions where they can thrive. The framework is just a tool, not the destination. Remember: Roads change. Terrains shift (in IT it can look like earthquake that change the path while you are on sometimes). What matters is that you and your team know where you're headed, and that you're adapting along the way.

“Agile means no documentation.” 👀 We’ve all heard it — and it’s one of the biggest misconceptions in Agile. In this week’s episode, Lance Dacy breaks down what the Agile Manifesto really says about documentation and why visibility and transparency are non-negotiables for successful teams. Good documentation isn’t bureaucracy — it’s how trust is built, decisions are made, and teams continuously improve. Watch now to learn how purposeful documentation and visualization can transform your Agile process. 🎥 Watch the episode: https://lnkd.in/gJrXGu6F #Agile #Scrum #AgileLeadership #ScrumMaster #AgileCoaching #AgileTransformation #ContinuousImprovement