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, 13 Dec 2004

Powerbook G5 to be announced soon

My powerbook is making truly alarming clunking noises. Gosh, could it be the disk? I'll probably be buying a new one soon, which can only mean that some wonderful new model will be announced in soon+1 days.

## Posted at 20:45 in category /mac [permalink] [top]

Selling Agile

As I've mentioned before, I sometimes hang out with Andrew Pickering, head of the Sociology department at Illinois. We've talked about Agile methods, which match well his analytical framework for explaining scientific progress (as put forth in his fairly dense The Mangle of Practice). As a result, he invited me to write a chapter on Agile for a forthcoming book on "the mangle." I produced a draft in February. It was mostly a detailed retelling of a refactoring episode in manglish terms. Lots of Java.

As so often happens to me, the current draft is much different. Instead of being about the micro, it's about the macro: explaining Agile development to sociologists.

So far, so boring. But I decided to end with a topic that intrigues me. Agile software development is not "businesslike". You've got a room full of programmers yammering to each other. And let's be frank: that room is messy. There's food all over the place. Maybe toys. Tables with 3x5 cards lying on them, programmers pushing them around like game pieces. Crude, childlike graphs on the wall.

Since at least the '60's, business has been successfully domesticating programmers, and all that progress seems to have been lost. There's even a company where the dress code calls for ties, and the programmers on the Agile team have been given a waiver. That's the first step to the harder stuff. What now will prevent all that California-style New Age babbling about 'emergent design' from leading to web sites describing which crystals are best for writing PHP code? And office water coolers filled with "energy water"?

I exaggerate. A bit. But the style and many of the beliefs of Agile development do not mesh well with what's traditionally thought of as the proper business workplace and practices. So why is it that I run into business people who love their Agile teams? What is it that those teams are doing right?

Is it just that Agile projects deliver better ROI? I certainly hope they do, but that claim isn't proven. And I don't think it accounts for the distinct emotional response I've seen. And, in any case, those concerned with ROI are no more dispassionate utility maximizers than the average hairless ape, so there must be more to the success of Agile.

Not that it's always successful. We so often hear the sad tale of a new VP coming into an Agile shop and destroying the Agile teams, typically for reasons that seem (to us) raw prejudice. Perhaps the reasons why some teams sell themselves well can help those teams that don't.

Pages 8-10 of my paper give those reasons, so far as I understand them. But I could be wrong. And I've probably overlooked or incorrectly discounted some. So I'd truly appreciate reviews, which you can send to marick@exampler.com. I have both a PDF of the chapter and a Word version in case you want to put comments in the text. (Sorry, RTF users: Word mangles the document when it exports it to RTF.)

I'd also appreciate comments on my description of Agility. I do use manglish jargon in that description, but in a way that I hope will still be meaningful for people who haven't read Pickering. (And I've also previously posted a description of the key terms.)

(And I have a guilty feeling that I'm being unfair to Parnas and Clements in my description of their "A rational design process: how and why to fake it." If you think I am, let me know.)


## Posted at 12:16 in category /mangle [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.




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

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


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



Agile Alliance Logo