Exploration Through Example

[UPDATE: I put this post under a new title because the old one broke too many URL-shortening apps.]

I am continuing to try to come up with an odd name for what I consider the roots of Agile. I’m doing that because I believe Agile is being dumbed down, commodified, and is losing its spirit. I’m picking an odd name because people are less likely to assume they already know what an odd name means. They have to ask. You have to have a conversation.

An odd name also lets me indulge my no-doubt-annoying fondness for the exaggerated, obscure, and marginal. Hence the name I’ve picked: “Artisanal Retro-Futurism ⊗ Team-Scale Anarcho-Syndicalism”. (Read the ⊗ as “crossed with” or “cross”.)

There are two halves to the story: an attitude toward technology and an attitude toward the social. To form the Agile attitude, those two attitudes are crossed (hybridized) like lions or tigers are crossed to form ligers. Or perhaps a better analogy would be crosses between chicken and game birds, since those species are less closely related than lions and tigers—just as technology and the social are often (wrongly) considered wildly different things.

Technology

Within technology, artisanal is supposed to connote:

• Higher quality and a focus on a more demanding customer.

• A product that’s an unusual variation on a more typical product, typically one that’s not suitable for mass production. (For example, an artisanal apple might not ship as well as common varieties.) To me, “artisanal” therefore suggests our extreme focus on the product director.

• A craftsmanlike approach to process. That process is sometimes, but not exclusively, “old fashioned” or manual. We are like this artisanal cheese maker:

  But [Wajswol] gladly lets technology lend a hand. Twice a day, in the “milking parlor,” a computerized lactation carousel that handles 60 sheep at once—the only one in the U.S. for sheep, Wajswol claims—milks 300 ewes per hour. In the cheese room, vats of milk are heated to the precise temperatures required to activate specific strains of bacteria to produce just the right texture of curd.

  “Machinery helps you pay attention to what’s important,” Wajswol says. “In cheese making, there are a couple of things you need to focus on. If you can eliminate the nonsense—the mundane, nonskilled steps, like feeding the animals or warming milk correctly—you can spend more time focusing on the texture of the curd and making sure the product comes out good.”

But artisanal is too broad of a term. It needs to qualify something else. What?

At a workshop once, Pete McBreen said “The Agile methods are methods created by people who like to program.” While that’s not entirely true, I bet it’s more true of them than it is of any previous gaggle of methodologists. And their oddity even goes a step further: a surprising number of the authors of the Agile Manifesto had programmed in Smalltalk. They were technology enthusiasts, and that enthusiasm—a “gosh wow!” enthusiasm for continuous integration tools, refactoring tools, programming languages, testing tools, and the like—has been a continuous part of the growth of Agile. It’s been a touch disreputable, though—many use the Agile Manifesto’s “individuals and interactions over processes and tools” as a weapon—so I’ve chosen the artistic style called retro-futurism to call renewed attention to it.

I am using retro-futurism in one of its senses:

[a] vision of the future as seen through the eyes of the past, often a utopian society characterized by high technology (relative to the base time), unusual or exaggerated artistic, architectural and fashion styles, and an abundance of consumer goods; its spirit of optimism […] is a contrast with cyberpunk […]

(Quote from ibid.)

Another way of looking at the style is as a response to the oft-heard complaint, “It’s the future now. Where’s my flying car?” In the physical world, “garage engineering” was supposed to mean hand-made—artisanal—rocket packs. Instead, it means the Improvised Explosive Device. In the software world, though, we have flying cars. Garage-scale organizations (open source, small companies) have brought us products that still evoke that old sense of wonder.

So. The technology half of the cross casts attention on giddy enthusiasm for both our products and how we build them.

The Social

Agile’s early emphasis on self-organizing teams caused some to brand it anarchic. Soothing those fears has led, in too many cases, to team processes that are externally imposed and therefore ossified. To counter that trend, I want to embrace the anarchic strain in Agile. (What should be done to sooth fears, I believe, is nothing more than producing working software at frequent intervals. So long as a team delivers that which satisfies, I don’t care if an integral part of their process is capering naked in the light of the full moon.)

At the same time, I want to recenter emphasis on the team. Too much of modern-day Agile depends on someone else to make it succeed. Typically that’s upper management, whether via servant leadership, outright command-and-control management, or something in between. While we can’t ignore the world outside the team, I think it better to take the attitude that, while it can make Agile fail, it cannot make it succeed. Agile lives and dies by the team.

Casting about for something odd that would combine “anarchy” and “team”, I came upon anarcho-syndicalism. Anarcho-syndicalism was an economic/political movement from around 100 years ago. The anarcho-syndicalists had laborers as their constituency. Their goal was to end the oppressive power—and very existence—of both the State and large-scale corporations by countering them with self-organizing trades un-ions.¹ Anarcho-syndicalism’s concentration on the self-organization and solidarity of the people whose hands make the product is reminiscent of Agile at its best.

I was also taken by anarcho-syndicalism’s emphasis on direct action. Others believed that the route to better working conditions lay in, say, electing representatives who would speak for the workers, but the anarcho-syndicalists rejected that. In that, I hear echoes of my attitude that teams should not wait for Daddymanagement to fix their problems.

Having chosen an outlandish reference—anarcho-syndicalism? a type of omigod socialism??—I needed to add a softening qualifier. Ending the State? Fighting the Corporation? Doing away with wage slavery?—none of these are part of the programme. We’re just trying to develop good software in a pleasant way that makes sense. Therefore: the qualifier team-scale is intended to remind that our message is to the workers of a team, not workers of the world.

So. The social half of the cross casts attention on perfecting the team. Or, rather, on the team perfecting itself.

Summary

To the extent that Agile has lost its way, a slogan that reminds us of the original path will help. To the extent that Agile as a movement now favors bland conformity over scrappiness and outrageous ideas, an outrageous slogan can help us get back to where we once belonged.

[UPDATE: I have no idea why WordPress has closed comments on this post. Best to put them on the original.]

¹ Wondering why I wrote “un-ions”? If I remove the dash, WordPress posting fails. Political commentary?

Here’s a draft of a sticker for Artisanal Retro-Futurism ⊗ Team-Scale Anarcho-Syndicalism:

And here’s my unpacking:

• The sticker will be 3×5 inches, the size of the index cards often used in Agile. That connects with the “old-fashioned tools and techniques” part of “artisanal”.

• The background is the anarcho-syndicalist flag, with the colors reversed as a reminder that we’re talking about team-scale anarcho-syndicalism, not the original.

• The crude brushwork might remind one of an anarchist hastily spray-painting a symbol or slogan on a wall.

• The word “artisanal” is often associated with foodstuffs. Like artisanal cheeses. Therefore, “artisanal” is represented by a cheese wheel.

• The rotating wheel space station has been a staple of science fiction and futurism for over a century. As such, it is a nice symbol for retro-futurism. Although a jet pack, rocket ship, flying car, or some humongous building with elevated walkways would be more recognizably retro-futurist, the shape of the space station echoes the cheese wheel and so ties “artisanal” and “retro-futurism” together.

I desperately need someone to take this concept to four-color art I can have printed as stickers. I could also use someone to produce a “camera-ready” image that I can use to produce posters like the ones I’ve already made. If you can do that, contact me.

I am continuing to try to come up with an odd name for what I consider the roots of Agile. I’m doing that because I believe Agile is being dumbed down, commodified, and is losing its spirit. I’m picking an odd name because people are less likely to assume they already know what an odd name means. They have to ask. You have to have a conversation.

An odd name also lets me indulge my no-doubt-annoying fondness for the exaggerated, obscure, and marginal. Hence the name I’ve picked: “Artisanal Retro-Futurism ⊗ Team-Scale Anarcho-Syndicalism”. (Read the ⊗ as “crossed with” or “cross”.)

There are two halves to the story: an attitude toward technology and an attitude toward the social. To form the Agile attitude, those two attitudes are crossed (hybridized) like lions or tigers are crossed to form ligers. Or perhaps a better analogy would be crosses between chicken and game birds, since those species are less closely related than lions and tigers—just as technology and the social are often (wrongly) considered wildly different things.

Technology

Within technology, artisanal is supposed to connote:

• Higher quality and a focus on a more demanding customer.

• A product that’s an unusual variation on a more typical product, typically one that’s not suitable for mass production. (For example, an artisanal apple might not ship as well as common varieties.) To me, “artisanal” therefore suggests our extreme focus on the product director.

• A craftsmanlike approach to process. That process is sometimes, but not exclusively, “old fashioned” or manual. We are like this artisanal cheese maker:

  But [Wajswol] gladly lets technology lend a hand. Twice a day, in the “milking parlor,” a computerized lactation carousel that handles 60 sheep at once—the only one in the U.S. for sheep, Wajswol claims—milks 300 ewes per hour. In the cheese room, vats of milk are heated to the precise temperatures required to activate specific strains of bacteria to produce just the right texture of curd.

  “Machinery helps you pay attention to what’s important,” Wajswol says. “In cheese making, there are a couple of things you need to focus on. If you can eliminate the nonsense—the mundane, nonskilled steps, like feeding the animals or warming milk correctly—you can spend more time focusing on the texture of the curd and making sure the product comes out good.”

But artisanal is too broad of a term. It needs to qualify something else. What?

At a workshop once, Pete McBreen said “The Agile methods are methods created by people who like to program.” While that’s not entirely true, I bet it’s more true of them than it is of any previous gaggle of methodologists. And their oddity even goes a step further: a surprising number of the authors of the Agile Manifesto had programmed in Smalltalk. They were technology enthusiasts, and that enthusiasm—a “gosh wow!” enthusiasm for continuous integration tools, refactoring tools, programming languages, testing tools, and the like—has been a continuous part of the growth of Agile. It’s been a touch disreputable, though—many use the Agile Manifesto’s “individuals and interactions over processes and tools” as a weapon—so I’ve chosen the artistic style called retro-futurism to call renewed attention to it.

I am using retro-futurism in one of its senses:

[a] vision of the future as seen through the eyes of the past, often a utopian society characterized by high technology (relative to the base time), unusual or exaggerated artistic, architectural and fashion styles, and an abundance of consumer goods; its spirit of optimism […] is a contrast with cyberpunk […]

(Quote from ibid.)

Another way of looking at the style is as a response to the oft-heard complaint, “It’s the future now. Where’s my flying car?” In the physical world, “garage engineering” was supposed to mean hand-made—artisanal—rocket packs. Instead, it means the Improvised Explosive Device. In the software world, though, we have flying cars. Garage-scale organizations (open source, small companies) have brought us products that still evoke that old sense of wonder.

So. The technology half of the cross casts attention on giddy enthusiasm for both our products and how we build them.

The Social

Agile’s early emphasis on self-organizing teams caused some to brand it anarchic. Soothing those fears has led, in too many cases, to team processes that are externally imposed and therefore ossified. To counter that trend, I want to embrace the anarchic strain in Agile. (What should be done to sooth fears, I believe, is nothing more than producing working software at frequent intervals. So long as a team delivers that which satisfies, I don’t care if an integral part of their process is capering naked in the light of the full moon.)

At the same time, I want to recenter emphasis on the team. Too much of modern-day Agile depends on someone else to make it succeed. Typically that’s upper management, whether via servant leadership, outright command-and-control management, or something in between. While we can’t ignore the world outside the team, I think it better to take the attitude that, while it can make Agile fail, it cannot make it succeed. Agile lives and dies by the team.

Casting about for something odd that would combine “anarchy” and “team”, I came upon anarcho-syndicalism. Anarcho-syndicalism was an economic/political movement from around 100 years ago. The anarcho-syndicalists had laborers as their constituency. Their goal was to end the oppressive power—and very existence—of both the State and large-scale corporations by countering them with self-organizing trades un-ions.¹ Anarcho-syndicalism’s concentration on the self-organization and solidarity of the people whose hands make the product is reminiscent of Agile at its best.

I was also taken by anarcho-syndicalism’s emphasis on direct action. Others believed that the route to better working conditions lay in, say, electing representatives who would speak for the workers, but the anarcho-syndicalists rejected that. In that, I hear echoes of my attitude that teams should not wait for Daddymanagement to fix their problems.

Having chosen an outlandish reference—anarcho-syndicalism? a type of omigod socialism??—I needed to add a softening qualifier. Ending the State? Fighting the Corporation? Doing away with wage slavery?—none of these are part of the programme. We’re just trying to develop good software in a pleasant way that makes sense. Therefore: the qualifier team-scale is intended to remind that our message is to the workers of a team, not workers of the world.

So. The social half of the cross casts attention on perfecting the team. Or, rather, on the team perfecting itself.

Summary

To the extent that Agile has lost its way, a slogan that reminds us of the original path will help. To the extent that Agile as a movement now favors bland conformity over scrappiness and outrageous ideas, an outrageous slogan can help us get back to where we once belonged.

¹ Wondering why I wrote “un-ions”? If I remove the dash, WordPress posting fails. Political commentary?

At MountainWest RubyConf, I gave a 30-minute talk in which I used TDD to implement double-clicking on a table cell to pop open a file chooser, collect a pathname, and put it in the cell. It was recorded. Here’s a page with a selection of video formats. In order to read the code, I recommend the big version.

There are a few problems. The sound goes crackly for a while in the beginning, I messed up my resolution so that long code lines are cut off in the first bit, and I’m not used to being recorded, so I used a laser pointer to point at the code. That was fine for the audience, but leaves you having to hunt for what I’m pointing at.

The video shows not just the flow of TDDing a GUI, but also shoulda, assert{2.0}, and my idiosyncratic wrapper around FlexMock.

The presentation is based on chapter 19 in my RubyCocoa.

The offer of a signed copy of the design sketch is no longer valid.

This is the Age of Enterprise Adoption of Agile. More and more of my email includes sentences like: “Currently, most of our software development follows the
traditional waterfall approach, but we are quickly shifting over to
more accelerated agile approaches like Scrum.”

In many of these places, adoption results in people saying things like “at least my job doesn’t suck as much as it used to”. (That’s an exact or near-exact quote.) Like James Shore, I find that both sad and infuriating. So naturally I’m off to Fix It All, ASAP.

First step: research

It seems to me that what gets lost in enterprise-wide adoption is (1) a clear picture of what project life will be like when everything’s working as it should be, (2) anything like a gut feel for the values that help teams make the right decisions under pressure, and (3) an emphasis on nitty-gritty technical or semi-technical skills (as opposed to quasi-formalised social skills like standups). But I could be wrong.

So let me ask a question to those of you who’ve been involved in an enterprise-wide or otherwise top-down shift to Agile. What do you wish someone had told you at the beginning of the adoption? (Suppose you could go back in time to then: what would you tell yourself?)

Me being me, I hope your message is about actions you could have taken (”you should practice X”, “you should take care to go slow at first“, “drop by Sophie’s desk every day and tell her what’s up”), but you’re the expert on what you needed to hear.

Either reply as a comment to this post or via email to marick@exampler.com. I’ll keep all mail confidential.

If I get enough information, I’ll post a summary.

If this research has already been done, let me know. Not so interested in doing reresearch.

At MountainWest RubyConf, I gave a lightning talk about Micro-scale Retro-Futurist Anarcho-Syndicalism. Perhaps only for completists, as it’s hard to fit a comprehensive discussion of a world-historical movement into five minutes.

There’s an interview with me at InfoQ. It covers micro-scale retro-futurist anarcho-syndicalism and my hypothesis that we could chisel value away from automating business-facing examples and add it to cheaper activities.

A message from Richard P. Gabriel:

Folks:

Writing papers is fun, but we don’t get to stretch our wings too often. Here is an opportunity to write something in a totally different style:

Submit an essay to Onward! Essays
Deadline: 20 April 2009

An Onward! essay is a thoughtful reflection upon software-related technology. Its goal is to help the reader to share a new insight, engage with an argument, or wrestle with a dilemma.

A successful essay is a clear and compelling piece of writing that explores a topic important to the software community. The subject area should be interpreted broadly, including the relationship of software to human endeavors, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. An essay can be an exploration of its topic, its impact, or the circumstances of its creation; it can present a personal view of what is, explore a terrain, or lead the reader in an act of discovery; it can be a philosophical digression or a deep analysis. It can describe a personal journey, perhaps that by which the author reached an understanding of such a topic.

I’m the assistant program chair (Simon Peyton-Jones is the chair), and I’d love to get submissions from the agile community. Reflections on
how to create software, what the creative process is like for software, what extremes of process could work in the future, where else could agile work, has it worked,… you name it. Anything to do with software.

NB: Onward! is co-located with OOPSLA, but they are otherwise unrelated. OO is fine, but not required. Not even encouraged.

Don’t forget: 20th April.

PS: To get your imagination going, here are a couple of (strongly contrasting) past essays:

* Dan Grossman “The transactional memory / garbage collection analogy”

* Dick Gabriel “Designed as designer”

* Friedrich Steimann “The paradoxical success of aspect-oriented programming”

or pick up your favorite essayist - be it Samuel Johnson (it’s his 300th birthday!), John McPhee, David Foster Wallace (my favorite), William T. Vollman, Edsger Dijkstra (ugh), or, what the hell, Richard P. Gabriel - and get inspired.

Here’s a metaphor I use a lot. Let’s assume we’re doing some sort of process where some people (call them “testers”) provide examples that another set of people (call them “programmers”) realize. By “realize”, I mean they change the code so that the examples, which were previously examples of something the product doesn’t do, become examples of something it does.

Most often, there are more programmers than testers.

What I tell teams is that I visualize the programmers as many baby birds in a nest, all chirping “feed me! feed me!” What they need to be fed with are examples to realize. The testers are the harried parent birds, zooming up to the nest, dropping a grub (a test) into a programmer’s mouth, then zooming off in search of another grub because—oh no!—another baby is about to finish its meal.

I tell this story for two reasons:

• It captures how harried testers (and product owners) can be on a team. It encourages the programmers to have a little sympathy.

• Just as the parent birds don’t stockpile all the grubs they’ll ever need in advance, the testers don’t have to have all the tests for a story done before delivering the first one or first few to the programmers. As long as the next test is there when the programmer needs it, all is well. In fact, finishing the next test just as the programmer finishes making the last one pass might be most efficient.

It’s just a metaphor, and has some imperfections. For example, there’s more to it than dropping tests onto programmers’ laps. There’s also discussion of what the whole story’s about, etc.

Photo by Flickr user aaroneus. Some rights reserved.

I will be driving this route sometime in late February to early March:

I have to be in Salt Lake City for MountainWest RubyConf on March 13-14. I have no fixed departure date. That’s because I want to do some visiting along the way. I may also do some visiting on the way back.

I have a half-formed plan to use such trips to do research for a book, tentatively titled Travels in Software: What the Great Teams Know. I want to find teams that are special in some way that other teams ought to learn from. It could be that they are particularly good at some specific technique, or that they have a general style that deserves emulation, or that they’re notably long-lived. (I mention the latter because I’ve gotten interested in the idea of “resilient teams”: ones that don’t dissolve because people get bored with what they’re doing, have survived big changes in their corporate environment, etc.)

If you are such a team, let me know.

My idea for a visit would be to “embed” myself in a team for up to a week. I would work with people on the team, pitching in on whatever they’d be doing were I not there. I’d also consume some time interviewing people.

Someone with authority would have to sign a Disclosure Agreement beforehand. Roughly, you’ll have to agree that you have no control over what I write about how you do things, but you can have reasonable control over descriptions of what you’re doing those things to. If you don’t want me to describe the product or your super-duper, soon-to-be-patented algorithms, that’s fine.