malvasia bianca

One more Christopher Alexander Nature of Order post, and then I’ll take a break. This is a counterpart to my earlier post about living code (I even repeat some of the examples): this time, I’m focusing on the agile processes that might produce that code. Again, thanks to the Agile Open California participants who helped me think about this.

Levels of Scale

Agile processes operate at many different temporal levels of scale: you might do a red/green/refactor cycle or swap roles within a pair every few minutes, change pairs every few hours, have a standup every day, an iteration every weak, and a release every quarter. (Of course, many teams don’t do all of these, especially the last!) This is, I think, one of the strengths of agile processes: many other processes don’t say anything about actions at the smaller temporal scales. (They do say something about still larger temporal scales, but that’s usually just bloat.)

Strong Centers

Stories. The Developer team, the Customer team. Iterations. The focus on getting (working!) code into production. The test suite.

Boundaries

Recall that Alexander’s preferred boundaries are those that are thick enough to be centers in their own right. With that in mind: iteration planning meetings; retrospectives; a scrum master; refactoring stages between implementation phases.

Alternating Repetition

Red / green / refactor; or, more generally, plan / do / reflect. Which are interesting examples, because they alternate between three phases instead of two; I don’t think that goes against the spirit of Alexander’s ideas, though. Note that, in both examples, one of those phases (refactor / reflect) is somewhat different in character from the others, in that it has (to me) more of a Boundary quality.

Positive Space

As in other less geometric contexts, I’m at a bit of a loss for good examples of this property.

Good Shape

Again, a geometric property that doesn’t translate well.

Local Symmetries

Perhaps having a consistent length for your iterations, or a consistent size for your stories? Or matching test code with product code?

Deep Interlock and Ambiguity

Agile’s emphasis on conversation over formal documents is a manifestation of this property: rather than having the Customer and Developer teams interact at arm’s length through formal specifications, they work out the meanings of stories through conversations, they collaborate on tests. Test-Driven Development is also an example: rather than having distinct and distant code and test phases, you do both together, with the two reinforcing each other.

Contrast

A test is either red or green. A story is either done or not done, not “95% done” or “done except for testing”. A feature is either in the scope of a story or out of scope. Certain decisions are owned by the Customers; others are owned by the Developers.

Gradients

I’m having a hard time putting my finger on this one. Teams evolve, the product evolves, surely I should be able to find a Gradient there? By design, agile is probably low in Gradients in some areas, e.g. knowledge is deliberately spread among team members as much as possible. Though knowledge will always be somewhat uneven; perhaps that actually leads to more of a Gradient than a siloed teams where people are actively discouraged from gaining knowledge in some areas? Hmm…

Roughness

The code always has to do what the customer wants, not what some abstract architecture would like it to do. Teams are constantly trying in their retrospectives to find areas to improve, to experiment; this comes along with an acknowledgement, even a happy acceptance that Roughness will always be present. Agile acknowledges, accepts, embraces risk. Agile encourages trying out ideas in code and timeboxing your work over endless whiteboard design sessions and overengineering. Of course, it also encourages refactoring, but even there I’ve heard people recommend refactoring mercifully rather than mercilessly: stop when you can see the end of your refactoring, and don’t actually carry out that last refactoring, leave a bit of roughness in the code as a seed.

And agile also embraces that most glorious source of Roughness in software development, the fact that software is written by people.

Echoes

Similar feedback processes occur at different scales: for example, you can do test-driven development at a level that forces you to add individual lines of code, but also at a level that drives entire features. The XP practice of Metaphor belongs here as well, I think.

The Void

I’m not sure any of the following examples quite hit on this property, but: The 40-Hour Week, the fact that you actually go home at the end of the day. Actively carving out space for reflection, whether in refactoring or retrospectives. Slack, the idea that a team can work better if it’s not completely scheduled. The 20% time / gold card notion that some teams adopt, giving developers extra space for experimentation and development.

Or perhaps the fact that agile typically doesn’t lead to kitchen sink software: the software does what it wants to do, what the team has actively chosen for it to do, and a lot is left on the table as a consequence of those choices.

Simplicity and Inner Calm

Do the simplest thing that could possibly work. Refactoring, actively seeking out the simplicity inherent in your code. Perhaps slack belongs here instead of (or as well as) The Void: a team with a bit of slack can remain calm in the face of circumstances that would shatter a team that’s scheduled to the breaking point.

Not-Separateness

The Whole Team, and its physical manifestation in the form of the team room: everybody’s in this together, both conceptually and physically. Collective ownership and avoiding silos. And “Responding to change over following a plan” fits into this bucket as well: not only are the team members not needlessly separated from each other, they’re not in a bubble separated from the rest of the environment.

Final Thoughts

Agile processes seem to me to do a quite good job of exhibiting several of these properties: Levels of Scale, Strong Centers, Boundaries, Alternating Repetition, Deep Interlock and Ambiguity, Contrast, Roughness, Simplicity and Inner Calm, and Not-Separateness all show up in profound ways. Though some of agile’s distinctive character comes from centers that it doesn’t emphasize: in particular, traditional silos (functional areas in development, or development versus test) are centers in their own right, but centers that are much less strong in agile methodologies than in other methodologies.

Perhaps Alexander gives ideas of how you could design a methodology which keeps those as centers: make sure to nourish them (Strong Centers), but don’t isolate them. If you can leave in thick Boundaries, have Deep Interlock and Ambiguity between them, while keeping Not-Separateness in mind, you’ll probably end up with a process that’s appropriately resilient, flexible, adaptable to unexpected circumstances.

I wish I’d written this blog post sooner after finishing The Process of Creating Life, because that’s really what’s most interesting about these properties of living structures: they’re not just a diagnostic tool, they’re a tool for growing living structures. (And, of course, agile processes as a whole are, among other things, a tool for growing living code!) If you want to introduce agile to an existing organization, if you want to expand agile from one team to many teams, then doing it via an iterative / organic process as Alexander outlines may well be a good idea.

I’d also like to see these ideas developed more on the Customer side of things, on the user-facing design of the product rather than the design of its code. Agile processes generally treat that part of the design as a black box, as magic: we allow the Customer to grow the product by adding to it gradually, providing frequent feedback, and in general giving the Customer as much flexibility as possible. But that’s all about enabling the Customer: the processes are completely agnostic about what the Customer does with that power.

And that’s not good enough. Take my current video game infatuation as an example: I’m all for video games that are developed quickly and are free from bugs. But given a choice between a game with a technically flawed implementation of a wonderful concept or a game that does everything right but has no soul, I’ll ignore the latter every time, while I’ll happily play the former as long as enough of the concept shines through. If Alexander’s ideas help us to figure out how to develop more games that are truly alive, that would be an achievement that would live down through the ages.

Something to think about. Which I will have ample opportunity to do: I doubt these ideas are leaving my brain any time soon, and I have a thousand more pages spread across two volumes to look forward to reading!