The Church of Agile is being corrupted from within by institutional forces that have refused or been unable to adapt to the radical humanity embodied in its collaborative, self-organizing, cross-functional teams. A hollowed-out husk of Scrum concealing taskmasters of Waterfall is the Trojan Horse of this betrayal.\n\nWith Waterfall methods masquerading as Scrum \u2014 call it Scrumfall \u2014 businesses are reasserting top-down micromanagement, fortifying silos, fettering flexibility, and commoditizing software engineers as mere cogs cranking out code. This sham of true Scrum is undoing not only the promised product benefits of Agile, but also its human-centric principles, which emphasize trust, collaboration, respect, connection, and sustainable work environments.\n\nAgile wasn\u2019t supposed to be this way.\n\nThe broken promise of Agile\n\nThe Agile Manifesto is short, sweet \u2026 and revolutionary:\n\n\u201cUncle\u201d Bob Martin \u2014 one of the manifesto\u2019s primary instigators and signatories, and author of Clean Code: A Handbook of Agile Software Craftsmanship \u2014 is reported to have characterized the manifesto as \u201ca set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work.\u201d\n\nAgile is supposed to be centered on people, not processes \u2014 on people collaborating closely to solve problems together in a culture of autonomy and mutual respect, a sustainable culture that values the health, growth, and satisfaction of every individual.\n\nThere is a faith embedded in the manifesto that this approach to software engineering is both necessary and superior to older models, such as Waterfall. Necessary because of the inherent complexity and indeterminacy of software engineering. Superior because it leverages the full collaborative might of everyone\u2019s intelligence. But this is secondary to Agile\u2019s most fundamental idea: We value people.\n\nIt\u2019s a rare employer today who doesn\u2019t pay lip service to that idea. \u201cWe value our people.\u201d But many businesses instead prioritize controlling their commodity human resources. This now being unacceptable to say out loud \u2014 in software engineering circles as in much of modern America \u2014 many companies have dressed it up in Scrum\u2019s clothing, claiming Agile ideology while reasserting Waterfall\u2019s hierarchical micromanagement.\n\nA sham of true Scrum\n\nThe misapplication of story points is the vector by which this sham of Scrum is delivered.\n\nScrum story points were originally intended to represent the relative complexity of stories. They are an approximation of an abstraction of relative expected effort, one made in advance of actually engaging the engineering. They are not an estimate of time, and they are not a legitimate basis for setting a deadline.\n\nAnd yet this is precisely how many businesses use story points, tying them to timelines to pull shiny estimates out of their ... well, let\u2019s say hats. They then expect their human assets to adapt to the plan rather than the plan adapting to the people and the emerging lessons of implementation.\n\nThen they push their people to crank out code, staying on schedule to deliver stories on time. If it turns out that a story estimated at 4 hours will actually take 16, well, time to pound some Red Bulls, then hustle and grind to balance the fantasy math that zeroes out the value of humanity.\n\nDoes that sound like a methodology that puts \u201cindividuals and interactions\u201d over \u201cprocesses and tools\u201d? One that puts \u201ccustomer collaboration\u201d over \u201ccontract negotiation\u201d? Is it \u201cresponding to change\u201d rather than \u201cfollowing a plan\u201d?\n\nObviously not. These are stories as mini-Waterfalls, each one treating the engineer as a cog in their employer\u2019s machine. Stories as fully specified orders for chunks of code, with no understanding of the craft, creativity, and critical thinking required to solve such complex problems.\n\nWaterfall by any other name is still obsolete\n\nThese mini-Waterfalls masquerading as Scrum reflect a top-down, linear approach that doesn\u2019t give software engineers the autonomy, access, and authority to drive the implementation of what the product team requests.\n\nThere\u2019s no room for actual conversations and genuine collaboration. No room for better ideas to emerge, or for anyone to change their mind.\n\nScrumfall relies, in other words, on the product team (made up of human beings) providing a complete and perfect specification before development begins. And it relies on the development team (also humans) planning out a complete and perfect implementation before a single line of code is written.\n\nNot even Dr. Winston W. Royce, who wrote the seminal paper on what we now call Waterfall, believed this was possible. \u201cI believe in this concept,\u201d he wrote, \u201cbut the implementation described above is risky and invites failure.\u201d\n\nWhen the inevitable imperfections of specification and implementation later emerge, Royce wrote, \u201cThe required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated.\u201d\n\nNo wonder we needed a different approach.\n\nCan Scrumfall ever work? Sure, in the most trivial of cases. Need a standard login page? We can specify, estimate, and execute on that in a timely manner without a lot of ongoing collaboration.\n\nBut for all the truly interesting, valuable, even revolutionary challenges in software engineering \u2014 the work that is complex and non-deterministic \u2014 we need human beings, collaborating in meaningful ways to craft better solutions together.\n\nThe butterfly effect breeds bugs\n\nCollaboration introduces inevitable uncertainty into the process. (And the invading Waterfall taskmasters hidden in Scrum\u2019s Trojan Horse absolutely hate uncertainty.) However, uncertainty is not a bug but a feature of Agile, which recognizes that better solutions can only emerge if the process embraces the unknown and protects the prerogative of people to change their minds.\n\nThe entire field of software engineering is so young, only slightly more than 50 years old, and changing so fast. Compare that to civil engineering\u2019s millennia of advancements, refinements, and standardizations. So much of what we do is new, an exploration of the unknown.\n\nSoftware is also orders of magnitude more complex. Though raw counts of lines of code are only a crude measure of complexity, consider that even a simple iPhone app typically has 40,000 lines of code, with more substantial software typically topping millions of lines of code. Google\u2019s codebase is estimated to contain 2 billion lines of code, comparable to the human genome\u2019s 3.3 billion.\n\nWhen you consider all the interactions among these lines of code, you\u2019re entering chaos theory territory, making software highly sensitive to butterfly effects: to wildly unintended consequences.\n\nIn short, we\u2019re dealing with an inherently non-deterministic process. Separating, isolating, and confining people is never going to solve away the uncertainty. Enforcing adherence to arbitrary deadlines and rigid plans will not conjure deterministic outcomes.\n\nInstead, these chains of mini Waterfalls create chaos, crappy code, and, ironically, cost overruns and missed deadlines. Long-term success is sacrificed to Scrumfall\u2019s short-term imperative to meet arbitrary measurements. It\u2019s also a sure path to burning out engineers, who will soon leave for other opportunities with more satisfaction and sustainability, less hustle and grind.\n\nThe fall of Scrumfall unlocks the true power of Agile\n\nAgile remains a very good idea that places the value of people over that of processes. Its radical restructuring of the software development life cycle will continue to transform our field and produce superior solutions.\n\nBut to unlock the true power of Agile, we have to fully accept the non-deterministic complexity of the meaningful problems we solve. There is so much we don\u2019t know at the start of a new project, and Agile says that\u2019s perfectly OK. Smart people collaborating in a human-centric culture can find their own way to a good solution. You just have to trust them with the flexibility to solve things as they think best.\n\nThere will be wrong turns along the way. People will change their minds or see a better solution. Some stories will take longer to complete than you expect. (And some may take less.) You may have to alter your timeline, rethink your MVP, or reprioritize your features.\n\nAgile holds that none of this is broken, none of it is a mistake, and none of it is wasted. It\u2019s what smart people do when they\u2019re solving complex problems. Rather than attempting to restrain all this uncertainty, Agile welcomes it as the very essence of creation.\n\nThere\u2019s a balance to be kept, of course. Agile can't be developer anarchy that never leads to a completed product. Properly implemented Scrum (or Kanban) keep the team aligned with what\u2019s needed and what will reasonably lead to the desired outcome within finite time and budget.\n\nBut we have to stop degrading the power of Agile by obsessively measuring vanity units of work rather than the value of what\u2019s delivered.\n\nTo realize the true potential of Agile, we have to recommit to its core principles and live them in everything we do by banishing the persistent taskmasters of Waterfall hiding inside Scrumfall.