You're doing agile wrong

Agile fails in many companies not because the methodology is broken, but because teams passively accept non-value-adding activities—true agility requires actively resisting waste. When simple principles like collaboration, working software, and responding to change are honored, agile works brilliantly, but corporate adoption often devolves into superficial Scrum ceremonies, Jira tracking, and heavyweight frameworks like SAFe that crush its spirit. Because software is fully malleable and cheap to change, it needs far less upfront planning than physical construction; therefore, rigid estimation and fixed sprint commitments create harmful incentives. The best performance metric is simply working software delivered to the customer, and anything that interferes with that is a distraction. In the end, agile is not Scrum, sprints, or kanban boards—it is doing only what is valuable and refusing what is not, starting by re-reading the Agile Manifesto.

• ▶ 0:00 Tris introduces the channel No Boilerplate, known for fast technical videos, and sets the topic: why agile at your company sucks—a software development issue that isn't about writing code.
• ▶ 0:06 The video will examine problems with agile practices in the workplace, not coding itself, with recommendations to come later.
• ▶ 0:13 The short answer: "It's not enough to do only what is valuable. You must resist doing what is not." Agile fails when teams passively accept non-value-adding activities; true agility requires actively resisting waste.
• ▶ 0:21 The common way agile is understood in most companies "sucks" in practice, causing engineers to spend more than half their time in meetings instead of writing software.
• ▶ 0:49 Agile is actually great and "the only thing that works" when its simple principles—collaboration, working software, and responding to change—are honored.
• ▶ 1:32 Software is fundamentally different from physical construction: it is fully malleable and can handle huge changes in a day, so meticulous construction-style planning doesn't fit.
• ▶ 2:14 Because the cost of failing in software is nearly zero, the amount of planning required should also be nearly zero — the core difference in the industry.
• ▶ 2:30 Saying "we do Agile" often just means cherry-picking parts of Scrum and tracking work in Jira or Trello, which is a superficial, tool-based adoption.
• ▶ 2:53 Frameworks like SAFe are a "nightmare" that crush agile with heavyweight processes, directly contradicting the Agile Manifesto's focus on individuals over tools.
• ▶ 3:21 Agile isn't a rigid prescription—teams must figure out their own practice because every person and team is unique, so no single framework like Scrum can fit everything.
• ▶ 3:37 Tris shouts out the YouTube channel "Code to the Moon" by Ken, praising its clear explanations of Rust topics like Rc and Arc and the Helix editor.
• ▶ 4:05 Code to the Moon videos have great production quality and tight scripts, and Ken even uses an erratum pinned comment, showing journalistic integrity—so viewers should check it out.
• ▶ 4:27 Agile is genuinely good at iteratively building the right thing with the customer, but it fails at answering “When will it be done?” – a real problem for the people funding the work.
• ▶ 4:45 Scrum began as a lightweight wrapper around Extreme Programming to sneak Agile into deadline-driven orgs, but management fixated on ceremonies and an Agile-training industry turned it into a product engineers eventually hate.
• ▶ 5:10 Tris’s starting point is simple: don’t estimate. Instead, sprint at full capacity, measure actual output after two weeks, and ask whether upfront story estimates would have improved anything – then adds the hard rule at ▶ 5:48: if estimation takes longer than doing the work, you morally must not do it.
• ▶ 5:52 Software development feels like magic due to its speed, but insiders know it’s about expressing wishes in code that often come true—not building like physical infrastructure.
• ▶ 6:33 Sprints are merely ceremonies for management’s sake; the real goal is to resist ritual and deliver value by building something and showing it to the customer early.
• ▶ 7:00 Agile is not Scrum, sprints, stories, or kanban boards—it is simply doing what is valuable and not doing what is not.
• ▶ 7:12 Practices like prioritizing velocity and committing to fixed sprint scope create harmful incentives, especially when metrics don't align with building software users want.
• ▶ 7:28 The best performance metric is working software—not documentation, designs, or prototypes; anything that interferes with delivering working software is a distraction.
• ▶ 7:52 Re-read the Agile Manifesto, do what is valuable, and avoid what isn't.

• ▶ 0:00 Introduction and the Short Answer (0:00 - 0:24) - - Tris introduces the channel and gives the quick answer: resist non-value work.
• ▶ 0:24 Agile's Real Value and Why Software Differs (0:24 - 1:55) - - Drawing on “Less Is More Agile,” Tris explains that Agile works because software development is unlike construction.
• ▶ 1:55 The Core Difference and What Companies Do Wrong (1:55 - 3:23) - - Software’s near-zero cost of change is core to Agile, but companies often replace it with frameworks like SAFe.
• ▶ 3:23 Self-Directed Teams and a Shoutout (3:23 - 4:18) - - Teams must figure out their own Agile practice, and Tris recommends Code to the Moon.
• ▶ 4:18 Scrum's Origins and Why Not to Estimate (4:18 - 5:55) - - Tris discusses Scrum’s strengths and origins, criticizes the Agile-training industry, and argues against estimation.
• ▶ 5:55 Delivering Value, Not Ceremony (5:55 - 7:12) - - Software is deceptively fast to build, so treat sprints as ceremonies and focus on delivering real value.
• ▶ 7:12 Bad Incentives and Outro (7:12 - 8:26) - - Velocity and sprint scope create bad incentives; working software is the best metric, then Tris signs off.