The Assembly Line of Agile Development
This is more of an observation rather than an attempt to reach any definitive conclusion. It’s just something I’ve noticed over the past decade or so in the web development landscape.
The Agile Manifesto consists of values and principles agreed upon by a group of 17 software practitioners in 2001.
First, let’s revisit the core values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In many ways, much of the modern development landscape seems to align with these core values. Good job, team—end of post….
…..Wait, let’s take a quick look at the Twelve Principles of Agile Software, listed on page 2:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I would say this is where we start to see some cracks developing. One takeaway I have from this is that the entire ‘working together’ aspect seems to have gone AWOL.
Business people and developers
Development team…face-to-face conversation
Emerge from self-organizing teams
Over the years, while working on many projects for a variety of clients, I’ve seen how many of the core principles from the Agile Manifesto have been gradually put through their own production line, resulting in something more akin to Homer’s car—somewhat un-agile.

Back in the late ’00s, I was regularly part of multi-disciplinary teams delivering software—designers, developers, consultants, project managers. Often, these roles blended together, such as in the case of responsive design, which was often delivered by developers rather than designers. I would even run workshops directly with users. I really wanted to deliver the software for users as I knew directly what they were trying to achieve. It seemed to work well.
However, something seemed to change in the early to mid-2010s: Agile at Scale. Suddenly, Kanban boards were being gamified, with points, velocity, fixed sprints, quality assurance, and go-live schedules. And then there was…Jira (shudder). On some projects, QA was only concerned with how closely the web page matched the visuals (with Figma and Sketch trying their damnedest to drag us back to Photoshop slicing). I would regularly spend hours explaining why the line breaks were different on a phone than on the 1920px layout. I thought we had moved on, I was wrong.
Increasingly, I was no longer involved in any discussions about core user goals, or even exposed to them. It was all about delivering layouts based on designs. I might get a glimpse of a KPI, but only if it involved applying a Google Tag Manager trigger. My job became moving a ticket along a board from the Sprint 𝑥 column to the QA column. Further, because development wasn’t involved in the early discussions, accessibility and performance were often dropped entirely (or moved to Sprint 𝑥-1). So much for continuous attention to technical excellence and good design enhancing agility.
Now, there is certainly some cyclicism (and quite possibly cynicism) here. Some members of the design community did not like losing control over the final look, and I get that. Project managers were pushed and pushed on delivery, and I understand that. Clients wanted a clearer idea of cost and fixed deliverables, and I get that too. There was always likely to be some pushback, but it is disheartening nonetheless.
I also have a feeling that the rise of the Front-end Engineer, React, and Developer Experience (DX) played both a role in and a response to the development and re-siloing of software development. More powerful design tools, such as Figma and Sketch, allowed for seemingly production-ready pages to be presented directly to clients, bypassing the hot mess that is working software. Covid probably had quite an impact as well.
It’s important to caveat this by saying that not every project followed this trend. Many of the best (and successful) projects I worked on included developers in the entire process or at least bringing us along for the journey, allowing us to contribute to the project as a whole and even contribute to solutions that enabled users to achieve their goals. But this became increasingly rare.
Obviously, as the years go by, these values and principles should evolve. Face-to-face conversation, for example, is something that can and should now be done digitally. The same applies to how we engage with users.
Many of the dragons we fought early on resulted in better, cheaper, more robust, faster, responsive and more accessible software. It feels like we are unlearning important lessons.
Taps the sign:
- Jira is not Kanban
- Figma is not the web
- DX isn’t UX
- Client sign-off is not the finished product
In an age where AI is barreling towards us, it is important to revisit these core values and principles, as they can help us navigate the rapid changes ahead. Rather than transforming the production line into a fully automated one, we should remember that individuals and interactions, continuous improvement, and responding to change remain valuable guiding principles—even as we approach 25 years since they were first manifested.
















































