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

Sun, 12 Sep 2004

Andy Scheider comments

Andy Schneider had some interesting comments on my cybernetics post. I'll comment on his comments after I get through various pressing business. The rest of these words are Andy's, reprinted with permission, except where he's quoting me.

I've worked on a bunch of broken and working agile projects and when I was reading your missive it kept taking me back to stuff I've observed.

I'm picking the bullpen as the unit of adaptation because I want to talk myself out of the notion that everything that matters is in the heads of the team members - some of it is "in" the configuration of the room, the Big Visible Charts, the source code, the Lava Lamps, the rituals that people take part in and the rules they follow and reinterpret...

When I read this I read the 'team' as the development team, the people cutting code and probably the customer representative. The definition is very dev centric (BVC, Lava Lamps, source...). When teams buy into this perspective I think they are already in trouble. These teams are often have the following traits:

  • They are not managing the 'group think' that arises from teams that bond and look inwards rather than outwards.

  • They see their team as the 'agile' team surrounded by a hostile, non-agile or problem environment (reinforcing the group think and introversion).

  • They fail to realise that feedback loops need to be in place between all the suppliers/providers and themselves, not just in the ways drawn out in the XP book - i.e. they just don't get the feedback part.

The best agile people I see working view the team as encompassing people involved in the end to end process. Furthermore, they view agile as part of a multi-paradigm approach to the entire constructin process rather than as the proverbial hammer. I do a brief and not very profound short talk in scaling agile and I spend 50% of it ramming home the need to make business engagement work and the other 50% discussing how you dovetail your agile dev team into the corporate environment in a way that is acceptable to all. In my mind these are two key cornerstones to an agile project, often missed in the rush to pair programming, lava lamps and A3 charts on the walls.

You then go on to say:

...and others appalled by how often successful-in-their-own-terms Agile projects get taken down by organizational struggles and interests are trying to figure out how to convert receiving organizations into something Agile enough to really use their Adaptive Bullpens well.

The fact the Agile projects believe they need to convert other parts of the organisation suggests a few things:

  • they haven't figured out how to adapt their external facing image to the needs of the host.

  • conversion... sounds awfully religious to me (slightly tongue in cheek).

  • The projects that later get taken down don't deliver busines value so their going in position, that the agile model they established would deliver business value, was probably mistaken - or at least its naive application was.

The fact that some people are even defining success 'in-their-own-terms' seems a bit of an issue with an organisation where success is probably defined in very different ways.

Of course, it can be argued that true success can only be achieved when the entire business is agile, but I think that's an oversimplification. Whilst some agile projects may be too passive, I have found many are too introverted and focussed on the 'one solution'. What we really need is not the establishment of agile development teams with a 'customer on site' but the realisation that agile is an approach, that needs to be tailored to the host environment and that must be driven by people who see the 'team' as the people in the end to end process chain, not just dev and the customer rep. Let's break down this insularity and start to see the bigger picture.

Andy S

## Posted at 14:46 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.




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