On Agile

In 2001, seventeen software developers met at a resort in Utah, United States, to discuss various lightweight development methods. The document they created during that retreat became known as the Manifesto for Agile Software Development. It was a collective effort to unify methodologies and push back against the heavyweight, micromanaged, and overly regulated approaches commonly referred to as Waterfall.

The Manifesto contains 12 principles, but only four 'values' are widely remembered:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

These principles set the tone for Agile, branding it as a new, more efficient, and progressive approach compared to the “old way.” Unfortunately, in practice, the principles turned out to be too vague to apply directly to software development. Even after more than 20 years, people still debate what Agile truly is — a philosophy, methodology, framework, or set of values? Countless books have been written to clarify it, and thousands have been certified as Agile practitioners and Scrum Masters to teach others how to “do Agile” correctly. And if Agile doesn’t work for you, you ain't doing it right, for sure.

Yet, despite years of widespread use, there’s no clear evidence that Agile truly works. It became the default simply because Waterfall — the “plan-everything-then-build-everything” approach — only works when you know exactly what to build in advance. In startups, where you’re creating something new, that’s rarely possible. Also, in single-product organizations, developers can’t sit idle while waiting for product managers and designers to create all the specifications.

Rolling Downhill on a Kanban Board

Two years later, in 2003, Mary and Tom Poppendieck published the now-classic book Lean Software Development: An Agile Toolkit. It was the first attempt to adapt methods used in Japanese Toyota plants to software development. Judging by the fact that most developers worldwide now drag tickets across Kanban boards, that attempt was successful. But was it really, and for whom?

It’s unclear why Mary and Tom thought it would work for software. Toyota used Kanban boards to produce identical cars from identical physical parts. An assembly line might have 300 to 500 stations, each with workers performing one specific, clearly defined operation. Once the car leaves the factory, it’s no longer the assembly line workers’ responsibility; they just move on to the next one.

The assembly line is transactional, with each completed car as the final product, and many operations are independent of one another. For example, the team painting the car doesn’t need to worry about the station installing the audio system, and the tire installation doesn’t depend on the quality of the seat installation.

None of this is true for software development. It’s not transactional because new code is built on top of existing code, layer by layer, constantly evolving. Poor decisions made by previous developers affect everything you can and cannot do easily with the codebase. Software development is more like building an ever-growing skyscraper or cultivating a tree.

Code Ownership vs. Ticket Mentality

When a car leaves the factory, repair shops handle broken lights or squeaky wheels — not the assembly line workers. Similarly, once a ticket reaches its “Definition of Done,” it disappears into the void. You’ll be lucky if your Kanban board tool has decent search functionality to help you find that ticket later. It will be much harder for your successors. But even if they do find it, how can they tell if the information is still relevant or hasn’t been overwritten by another ticket?

With a Kanban board, developers have little direct incentive to care beyond their immediate tasks. Found a bug after deployment? Great, that’s just another ticket — a new way to show productivity to the manager. Missed a requirement? Another task or maybe user story with story points attached. Developers who churn out low-quality code quickly often win in Agile, while their teammates are left to fix bugs and refactor code later at their own expense. The link between bugs and hasty delivery is largely overlooked.

“If it’s not in Jira, it never happened.” This ticket mentality does not incentivise code quality or long-term thinking. It prioritises velocity and burndown charts, which are rarely satisfactory. Non-technical people cannot gauge code quality or overall codebase degradation until it’s too late. As a result, costly rewrites are still common in the industry.

Technical leaders often speak about code ownership, but what they’re really trying to address is widespread ignorance. Many developers don’t look beyond poorly written user stories and don’t face the consequences of their mistakes unless it’s a critical issue for a major user. They’re paid to fix their own errors without truly learning from them. On the other hand, capable developers are forced to cut corners during the typical end-of-sprint rush, which often leads to growing frustration and burnout.

This is how Agile, along with its main visual embodiment — the Kanban board — have failed software development. Agile attempted to merge heuristics with programming and it was a failure. That’s why we created Swinlanes, introducing a systematic approach to software product management for the first time.