Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Mon, 11 Sep 2006

Across the chasm

A couple of years at the Agile conference in Calgary, a big topic of discussion was whether Agile was poised to cross the chasm from visionary early adopter types to the early mainstream. This year at Agile2006 it sure seemed to me we had.

If I recall the high-tech adoption curve correctly, a big difference between the Visionary early adopters and the Pragmatist early mainstream is who they talk to. The Visionaries talk to the Technology Enthusiasts to find ways to have big wins. The Pragmatists talk to other Pragmatists, especially ones in the same industry, to find ways to have safe wins.

My main client these days is a good example of a Pragmatist. Before adopting Scrum, they methodically went to visit other companies that had been using Scrum successfully. That's the first time I've seen that.


Agile in the mainstream is definitely a good thing, but every silver lining comes with a cloud. I worry that the clear sunshine of innovation will be obscured by the mists of scale. (Sorry about that...)

If you believe Moore, the mainstream market naturally shakes out into a single dominant "gorilla" and several "chimps" that scrabble for the leavings. He uses Oracle as an example of the gorilla, companies like Sybase as examples of chimps. Or you could think of the relational model in general vs. other ways of organizing and accessing persistent data.

On the one hand, that's good for innovation: the chimps have to find some angle to distinguish themselves from the safer gorilla choice. On the other hand, the innovation is constrained: it can't be too wildly different from the gorilla or else you're no longer in the mainstream market. (The distinction here might be between object databases—never made it in the mainstream—and adding object-ish features to relational databases or just figuring out how to make object-relational mapping work.)

But more important, to me, is a redirection of talent. The gorilla of Agile is Scrum + a selection of XP practices (perhaps most often the more technical ones like continuous integration or TDD). Consultants and consultancies can make more money, grow their practice faster, and have more influence by helping new teams start with Scrum+XP and by taking steps to make Scrum+XP more palatable to large segments of the mainstream market (the later mainstream, what Moore calls Conservatives). People doing that don't have time to do other things.

We saw that at Agile 2006, where the proportion of novices perhaps reached some sort of tipping point that made it more like a conventional conference. That's not a criticism: the Agile Alliance is there to help Agile projects start and Agile teams perform—says so right on the website—and making sure the beginner is served is absolutely necessary to those goals.

So that's all good. But I'm not comfortable unless I've got the feeling that there's something just beyond the horizon poised to surprise me. I'm not usually the one to find it: I'm more of a synthesizer, amplifier, or explainer than an innovator. So I selfishly need people out there searching, not teaching Scrum+XP.

I'm getting a sense that some significant chunk of people are ready for Agile to take a surprising jump forward. See, for example, what Ron Jeffries has recently written. Some part of my next year will be spent in support of that. I have at least one whacky idea, a bit related to the MFA in software.

I'll be poised to spring into action soonish. Just let me get this book done, please let me get it done, without any of the changes in response to reviewer comments introducing a nasty bug.

## Posted at 21:34 in category /agile [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.

 

Syndication

 

Agile Testing Directions
Introduction
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects
Postscript

Permalink to this list

 

Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list

 

Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI

 

Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."

 

Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich

 

Where to Find Me


Software Practice Advancement

 

Archives
All of 2006
All of 2005
All of 2004
All of 2003

 

Join!

Agile Alliance Logo