Agile

Big Spec Up Front failed. Not because the people who practiced it were careless — many of them were meticulous. It failed because of something structural: the act of implementation always reveals things that specification missed. Users cannot fully articulate what they want before they see it. Complexity defeats even complete knowledge. External requirements shift before the system ships. Agile was the response. Short loops. Working software over comprehensive documentation. Iterate toward understanding instead of specifying toward it. ...

There’s a recurring debate in agile circles about why teams miss deadlines. The usual suspects: bad estimates, too many columns in Jira, missing WIP limits, the wrong metrics. The fixes that follow are predictable. Reconfigure the board. Add a Cycle Time chart. Apply Little’s Law. Run a retrospective about why the sprint went sideways — again. These interventions aren’t wrong. But they’re downstream of the actual problem. The Board Shows What Refinement Produced A Scrum board is a mirror. It reflects the quality of the decisions made before the sprint started. If those decisions were vague, the board will look chaotic — not because of how the columns are arranged, but because the work itself was never properly understood. ...

In the current era of AI-driven development, the pressure to deliver “faster” has never been higher. With the advent of sophisticated coding agents, the first instinct for many project leads is to parallelize: split the work, run frontend and backend tracks simultaneously, and maximize output. However, this rush to parallelize often comes with a hidden cost that many organizations fail to account for. By optimizing for simultaneous output, we are inadvertently sacrificing the very Agility we claim to pursue. ...

Test-Driven Development has always been slightly misunderstood — even by people who practice it. The name doesn’t help. “Test-Driven” sounds like it’s primarily about tests. Coverage metrics. Regression safety. The QA team’s peace of mind. But anyone who has worked seriously with TDD, or spent time with practitioners like Emily Bache, knows that tests are almost a side effect. The real output is understanding. TDD, done well, is a method for thinking your way through a problem one small step at a time. You don’t start with a complete picture of the solution. You start with the smallest possible question: what is the simplest behavior this code should exhibit? You write a test for that. You make it pass. And in the process of making it pass, you learn something — about the problem, about your assumptions, about the design that is quietly trying to emerge. ...