Exploration Through Example

Interesting survey:

How about you? How long would you have lived in the middle ages? Ignore all the general risks - like typhoid or the plague or cholera - that everyone would have faced in general. Let’s assume you were lucky and missed those. (Unless by some chance you actually DID face one of them in your life.) Also ignore the fact that your deadly injury might have been caused by modern technology, like an auto accident. Just pretend you were trampled by a horse or something. So, given the injuries and illness you’ve faced in your life so far: Did you make it? Would you have survived to your current age?

I would have died at 13 due to a ruptured appendix.

Judy Olson (University of California, Irvine) will be presenting a colloquium entitled “Distance Collaboration: What makes it successful?” on Thursday, May 21st at 4 pm. The colloquium will be held at Frances Searle 2-370.

For more information on the TSB speaker series (and to sign up for announcements), visit http://tsb.northwestern.edu

To add upcoming TSB talks and events to your Google calendar, visit the TSB Colloquium Series Google calendar.

DISTANCE COLLABORATION: WHAT MAKES IT SUCCESSFUL?
Judy Olson

ABSTRACT:
Many organizations, many sciences, and many of us have collaborations with people who are not nearby. We and they use various technologies like shared files, email, blogs, instant messenger…to support their work. Some of these collaborations work; others do not. What makes them succeed? We have collected data from 200 collaboratories, deep data from about 30, plus data from 20 sites in corporations, to determine what makes the collaborations work, what makes them fail. I will review this line of work and describe the factors that are apparently most important in both science and corporate long-distance work. All of us may benefit in learning these factors to ensure that our own distance collaborations succeed.

I’ll be giving a keynote at the Agile Roots conference:

The topic is, unsurprisingly, Artisanal Retro-Futurism ⊗ Team-Scale Anarcho-Syndicalism. Here’s the blurb:

A problem with the word “Agile” is that everyone already thinks they understand it at a gut level. Worse, everyone already thinks they’re agile in spirit. (After all, the thesaurus tells us the alternative is to be clumsy, stiff, slow, and dull.) So it’s too easy for people to feel free to launch into “doing Agile” without ever having a serious conversation about what that actually means.

This problem is easily fixed. We’ll just stop talking about “Agile” and start speaking of “artisanal retro-futurism crossed with team-scale anarcho-syndicalism.” There is, I think, no danger that anyone will reflexively say, “Yes! That’s just what I’ve been wanting to do all along!”

The new name does more than just encourage conversation. It encourages conversation about those very properties of Agile that have become obscure as Agile has been commodified. In this session, I’ll unpack the meanings of the new phrase and encourage you to rediscover what’s been lost.

I hope to have trinkets.

[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.

I’ve altered and made more specific the idea behind Travels in Software. People without experience can’t get by with only facts: they need stories. Stories teach them values—habits and reactions they can put to use when they have a thorny dilemma. Stories also give them a mental picture of an achievable way of working. People can say, “What we’re doing here just doesn’t feel right. Story planning [or test-driven design, or standups] seemed so smooth in that story. Let’s move toward that way of working.”

So the book will be largely made up of stories told by people who are proud of their work, their team, how they handled some problem or seized some opportunity. The stories will describe how to be or become a team that works with ease.

I plan to present these stories as oral histories. I’ll record people, ask questions, help them tell their story, then edit the story down—removing my promptings, any redundancies or un-useful digressions. The goal is to produce the most compelling possible version of the teller’s words. My model is Studs Terkel. (To see this style, look inside Hard Times.)

I’ll post the stories in a blog. In the book version, stories or groups of stories will be preceded or followed by explanatory text and essays on the topics covered.

The first interview is tomorrow. For now, I plan to conduct them in person. Mail me if you have a story to tell.