Debating Agility at ThoughtWorks

Posted by Deborah Hartmann on Dec 06, 2006 06:24 AM

Community

Agile

Topics

Methodologies

Tags

ThoughtWorks ,

Agile Manifesto ,

commentary ,

Criticism

A lively debate is underway among the folks at ThoughtWorks. Starting with Dr. Jim Webber, noted author and ThoughtWorks' top SOA consultant, complaining of religiosity among unnamed colleagues.  Does the rise of "Agile religion" signal that the moment has arrived to retire the "Agile" label? 

The discussion began when Dr. Webber described himself as an Agile atheist:

For those that have the agile religion, it is routine to express to others why they are not "agile" because they're not doing precisely 72.799 hour iterations, or because they have code coverage of less than 83.002% or other arbitrary measures. That is counter productive. Instead we should be encouraging good behaviour as a general practice, not enforcing it through religion and the humiliation of non-conformists that most religions - including agile - engender. Sensible software engineers do the things that make projects successful and we should maintain that, but without the dogma.

Fellow ThoughtWorker Jeff Santini called Jim out in the comments, disputing the existence of an "Agile religion":

I hear alot of talk about the Agile Religion, but I have yet to hear from anyone who actually subscribes to it. ...

You said you are not Agile because you don't believe in it's religion and you don't accept its dogma. Yet I AM Agile and I also don't believe in its religion nor do I accept its dogma. As a matter of fact I don't have any idea what its religion or dogma are.

In light of the above statement either we have different understandings of what it means to be Agile, or there is something besides these two issues that determines Agility.

But seriously, the Agile Manifesto mentions some pretty good guidelines in my opinion to keep teams focused on delivering software rather than adhering to a (potentially dogmatic) methodology.

To which Jim responded:

I don't think I can call myself agile because others who are agile would find my practices different. For example, I subscribe to (enough) architecture and design; I am also wary of YAGNI as a way to shelve important design decisions under the belief they can be magically retrofitted later. I also like quiet focussed areas in whcih to work, and I'm sure there are other ways I'm sure that I disagree with the orthodoxy.

I don't mean to convey any disrepect for agile practices. As I said in my blog post I like (most of) the engineering and planning practices that agile teams use. But I don't fully subscribe to ADD working environments or full time pairing etc. That is why I am an agile atheist.

Jeff Patton, another top ThoughtWorks' consultant and reknown product designer, shortly thereafter authored there Is No Spoon, why the best software design and development process is all in your head.  Using the spoon bending scene from the Matrix as a backdrop, he presented a compelling argument that the highest performing teams do not follow a consistent process. Much of the blog entry is drawn from suspicions confirmed at a UserInterface11 conference presentation by Christine Perfetti. :

The UIE folks expected to find that the highest performing design teams had the best processes; but in fact they found that high performing design teams might not follow a consistent process at all. What they did have was a big toolbox full of techniques and tricks, and a history of adaptation and improvisation. She went on to say that in organizations that had a documented methodology, they could almost predict poor performance.

Colleagues say that Patton is a big fan of Shu Ha Ri, a concept drawn from the martial art of Aikido, whose three levels of learning progressing to mastery roughly translate as:

1. Shu: traditional wisdom - learning fundamentals, techniques, heuristics, proverbs
   
   
2. Ha: breaking with tradition - finding exceptions to traditional wisdom, reflecting on their truth, finding new ways, techniques, and proverbs
   
   
3. Ri: transcendence - there are no techniques or proverbs, all moves are natural

For those that believe that Shu Ha Ri applies to the discipline of software development, rigid adherence to Agile practices is 'Shu', the first and furthest stage from mastery.  Patton wrote:

Deep down in my heart, I know that there's really no process. That I'll really have control over my process when I let it bend and sway like a blade of grass. When I focus on the objectives of my software I try to transcend the process.

ThoughtWorks is a consultancy whose "chief geek" is an Agile Manifesto founder, and which differentiates itself through use of Agile methodologies.  It seems doubtful that Martin Fowler's brainchild would need to consider a realignment - moving the company's public image away from being an "Agile consultancy", but others have already made this move.

If Agile religion exists, it seems to consist of a focus on strict adherence to practices without a need for understanding, combined with judgmental criticism of others - clearly ignoring the spirit of the Agile Manifesto's "people over process," values-driven approach.  As another commenter noted: "When I refer to Agile - just the word - as you have in the title, I'm focused on the mindset, the spirit, not the practices."  There are in fact NO practices specified in the Agile Manifesto, or its accompanying list of principles.  Is it time to abandon the term "Agile," allowing it to be redefined by this pale shadow of Agile mastery?  Why not simply refuse to be painted with this paintbrush, when it does not apply?

1. Back to top

   Definition of success

   Dec 6, 2006 7:18 PM by Michael Burke

   I thought Patton's definition of "software success" (taken from the blog post) was interesting:

   'We knew we?d delivered successfully not when the ?EAR file as uploaded to the server,? but when we saw end users successfully working with the software on a daily basis.'

   Depends on the scope of a project I suppose, but for me, I would add to that sentence "and in 5 years' time". That draws in concerns such as flexibility of design, level and quality of documentation, ability to accomodate increasing volumes, anticipation of change, etc. A lot of these things are anathema to the Agile dogmatist mindset (you ain't gonna need it!), and, dare I say it, the typical consultancy mindset (I've used my glorious methodology, now the maintenance guys can take over and I'll move on to the next gig - but first I'll blog about how great I feel about it.) Given the investment in money, people and time for software of any real significance, just having something that is good enough today is, not, well, good enough. The point that 'Agile' is now an overused cliche is well made. As is the use of 'Waterfall' to paint any project that doesn't call themselves 'Agile'. They're just labels that lazy people use to pigeonhole - kind of like music genres!

   Reply

2. Back to top

   Everyone is right, they just fail to agree. ;-)

   Dec 7, 2006 2:16 AM by Clinton Begin

   The key to Shu Ha Ri is realizing that it's a process and that it cannot be rushed. Agile the term means nothing, it's like saying "Martial Arts". The actual methodologies like XP and Scrum are like the individual arts themselves -- Aikido and Wing Chun to name a couple. Nobody ever suggests that we should remove the term "Martial Arts" because it doesn't really define anything itself. And nobody suggests we stop teaching Aikido or Wing Chun because the top UFS and Pride champions are mixed martial artists who study many forms and tune them into their own personal styles. The fact is, only Shu can be taught. Ha and Ri must be found throughout a person's career. Furthermore, even new teams with masters must begin at Shu, as "Shu" is the only common language that the team can use to communicate with each other. The team will find their way to Ha and Ri as they learn to work with each other. The same is true with all individual interactions. In Canada we say "Hello" (Shu) by default when we meet someone new, whereas we may greet a long time friend with a knuckle shake without even meeting eyes (Ri). So Agile must remain, but we must understand what it means. We have to keep the commercialization of the term from blurring the meaning of Agile. Furthermore, we must respect the differences of the various methodologies, realizing that each has its merits and weaknesses on almost a case-by-case basis. Different team, different project, different methodology. The realization that there is no single methodology for every team and project is exactly what makes it agile. Cheers, Clinton

   Reply

3. Back to top

   When do you become agile?

   Dec 10, 2006 7:57 AM by Yagiz Erkan

   I become more agile when I can react better and faster to changes. For example, if some upfront design provides me that, I'm all for it. I guess we shouldn't forget about the reasons when we apply some of the guidelines/recommendations/rules.

   Reply

4. Back to top

   Re: Everyone is right, they just fail to agree. ;-)

   Dec 12, 2006 7:31 AM by Yagiz Erkan

   One of my colleagues, Brendan Lawlor, just blogged about a relevant topic: How Mumbo Jumbo is Conquering Software Engineering

   Reply

• Older >