Scrum is Hard and Disruptive 11 - Scrum is Harder than Waterfall

Ryan and Todd look back at a 2006 post by Ken Schwaber, which covers 15 ways Scrum is both hard and disruptive.
The eleventh statement from Ken:
"Iterative, incremental development is much harder than waterfall development; everything that was hard in waterfall engineering practices now has to be done every iteration, which is incredibly hard. It is not impossible, but has to be worked toward over time."
Iterative and incremental development in Scrum is more challenging than traditional waterfall development, requiring constant attention to engineering practices and frequent iterations.
Extensive upfront design and architecture planning in waterfall development is believed to reduce future risks. However, software development often leads to outdated designs as customer needs and market conditions change over time.
Scrum emphasizes quick decision-making on basic architecture, like frameworks and databases, while building the product incrementally. It demands disciplined, professional attention to ongoing architectural and design decisions in response to evolving customer demands.
The Scrum approach challenges traditional development models like waterfall, where work often expands to fill the allotted time, leading to over-engineered solutions. Scrum requires a shift in mindset, focusing more on doing and building features rather than extensive planning and discussion.
Adopting Scrum effectively requires gradual, sustained effort to improve engineering practices and architecture. Teams and organizations need to develop this skill set over time, including a solid understanding of their definition of "done" to reflect the maturity of their Scrum implementation.
👉 Follow our journey through all 15 insights in Ken Schwaber's white paper, revealing the enduring relevance of Scrum principles.
💬 Share your perspectives in the comments and remember to like and subscribe for more in-depth Scrum discussions. 🔔
🔗 Here is the original white paper: www.verheulcon...
🔗 Join Ryan & Todd's Scrum.org courses: buytickets.at/...
Explore more:
📖 "Unlocking Business Agility with Evidence-Based Management: Satisfy Customers and Improve Organizational Effectiveness" on Amazon -- amzn.to/4690qJy
📖 "Fixing Your Scrum: Practical Solutions to Common Scrum Problems" on Amazon -- amzn.to/46dAQTC
✅ Subscribe to this channel for Agile, Scrum, and Kanban insights: www.youtube.co...
🌐 Connect with Agile for Humans:
📘 Website - agileforhumans...
🐦 Twitter - / agileforhumans
🔗 LinkedIn - / agile-for-humans-llc
🔍 The Evidence-Based Company - theevidencebas...
📧 Email - [e-mail]
Join this channel to get access to the perks and exclusive videos:
/ @agileforhumans
#agile #scrum #ebm #agileforhumans #scrummaster #scrumtraining #leadership #management #leadershipdevelopment

[@SkywalkerWroc]

I 100% disagree. This whole notion is such a surface-level understanding. Delivering a successful waterfall project is MUCH, MUCH harder than delivering a successful Scrum project. So of course that waterfall is harder!!! How there could be any doubt?! I think that what you try to argue is that the *introduction* to the Scrum *process* is harder to learn than the introduction to the waterfall process. But on that topic, I would say: introduction to the Agile process is harder than the introduction to the Scrum process. And similarly, delivering a successful Scrum project is harder than delivering a successful *Agile* project. Re: DoD - I think that the personal opinion of the people on the project doesn't matter. Ultimately, what matters is if stakeholders & end-users are happy with the outcomes and the value generated, rather than if every single person working on the project is happy with every single piece of process (heck: I would argue that it's impossible to 100% satisfy every person on the team). Having a perfect DoD was never the goal.

[@checla]

Hi. I see things differently, and please, allow me some clarification. Scrum is not a process. And yes, it's harder because it's an instrument for navigating through complex problems, while Waterfall is not suitable for it. Yes, Scrum is harder because teams are required to be cross-functional, self-managing, and adapt continuously. Yes, Scrum is harder because, unlike waterfall, you have no handovers, and phases are not necessarily in sequence. Yes, Scrum it's harder because the product needs to react to changes from the customer, the market or whatever meaningful source of information/feedback is needed. Ultimately, a waterfall project has almost no chance to satisfy the customer/user if requests of change are done often. Yes, Scrum it's harder because you need to have the commitment to and for a continuous collaboration also from the user/customer. Is Waterfall easy to implement? Not at all. However, as an instrument or process is just easier than Scrum.