I’ve been practicing lower case agile on a few different teams for the better part of my professional career. However I wouldn’t say I’m an expert in Agile by any means. I’ve had to do agile because it is basically everywhere in software development land. I’ve latched on to some of its practices that have been useful in grounding my work.

I use practice here intentionally because that’s exactly what it has been for me: a small set of techniques I’ve learned from other practitioners, that help me manage the complexity of developing software, mostly while working in small groups. More often than not I’ve seen test driven, iterative development, and the pragmatics of YAGNI help make healthy work environments. Ideally these practices have been shared by other people that I’m working with, but sometimes I’ve just practiced them solo, especially in open source projects that have been about developing for other developers.

Honestly I don’t really like the word “agile” much because it implies a degree of speed and nimbleness which I really don’t have (or aspire to) as a software developer. Sometimes things come quickly to me, but most of the time I work in fits and starts, and often quite slowly. I try to tell myself that’s because I’m trying to take my time to get things right, but really it’s just because I’m plain slow.

But even when I’m working slowly I find it useful to think in terms of iterations, and continuously releasing improvements–and (most importantly) delivering value to people that use the software (more on this last point in a moment). I think software developers find it easiest to deliver that value to themselves (making their software development easier) but that’s not really what it’s all about.

Given all this I read Miriam Posner’s recent Agile and the Long Crisis of Software with interest (I’m a fan of her other work). In this piece she provides useful cultural and historical context for the document that is the Agile Manifesto, why it was written, how it was received, and most importantly what its attendant shortcomings (and abuses) have been. I won’t attempt to summarize all of her points here–really, go read it–but chief among the takeaways for me is that there were some real side effects as Agile shifted the focus away from managers and long term plans, towards developers who need to be empowered to make iterative improvements to The Project. In the repetition of sprints and work cycles, releases, and the accumulation of “user stories”, code and other artifacts, software developers can lose perspective on why they are doing what they are doing: why The Project exists and for who. In focusing on the various well scoped iterative tasks, agilists lose the ability to critically reflect on what they are doing, and to reshape what it is.

I have definitely seen this happen, especially on larger projects. If you are heads down crafting a specific piece of business logic, it can be difficult to see the forest for the trees. It takes discipline and practice to keep the forest in view. This is hard enough to do on your own, but once you are doing it in a group it gets harder to even see the same forest.

One thing that I think is often missing from discussions about what is (and is not) Agile, is the significance of points 1 and 3 in the Manifesto. People tend to focus on the parts that say that they don’t have to have a plan or documentation. Here are 1 and 3:

• Individuals and interactions over processes and tools
• Customer collaboration over contract negotiation

Admittedly, these have a very managementy ring to them, especially the terms “customer” and “contracts”. In some ways I guess they had to, because the Manifesto was written to convince management to unshackle professionals (not just developers) from various kinds of waterfall style death marches that were commonplace in software development. But a radical reading of these two points, and something I’ve seen working with people who’ve had exposure to Agile’s precursor Extreme Programming, is that they mean actually working with the users of software to design what it does. The users of the system are brought directly into the software development process.

I think very often in Agile this collaboration gets distilled into the Product Owner role, who represents the users of the software, and communicates these values to the software development team through various types of decisions that need to be made (scope, priorities, releases, etc). The best Product Owners that I’ve worked with have also been expert users of the software. They aren’t merely representing the abstract interests of others, with their SCRUM certification hanging on the wall, they are a user–they have a real interest in seeing the software improved, because it makes their life easier, or better in some way. They understand other users needs because they are one of them. Unfortunately I think Product Owners can be, as Posner says, “pulled in two directions: what’s best for the developers on the one hand, and what they’ve promised to deliver to management on the other”. Without some guard rails in place they can become alienated from what delivers true value to the users of the software, and get burned out in the process.

In hindsight, after going back to school for a bit, and reflecting on some of my professional experience (I’m old) I think the best of Agile for me has always been about the philosophy of Participatory Design. As Karlheinz Kautz has noted, not enough has been made of the connection between participatory design and agile practices (Kautz, 2010). In Participatory Design employees, customers, citizens (aka users) are directly involved in the design of systems. The work has an explicit political dimension that requires practices that structure participation in decision making around design, and what gets built, and what does not get built. Maybe I’m just looking for a silver lining here, and that this meaning of Agile has long since been diluted. But I still find meaning in those two points from the manifesto. Several of the “middle-aged white guys, dressed in khakis and dad jeans” who wrote the manifesto had previously worked for years developing software design patterns to help developers share and reuse solutions for particular recurring problems. They drew inspiration from the architect Christopher Alexander whose idea of Pattern Languages helped practitioners describe and share design solutions to particular everyday problems. These patterns were oriented around improving spaces for living. Maybe that value got lost along the way too. But it’s still important to me.

RIP Christopher Alexander (1936-2022)

References