Mar

10

Process as Religion or How Agile Will Fail

Posted by Keith McMillan

March 10, 2009 | 2 Comments

Something’s been on my mind, and I need to speak up a bit.  I’ve grown increasingly annoyed by agile practitioners who are slavishly devoted to their favorite agile author.   It doesn’t matter if it’s Uncle Bob, Ken Schwaber or Kent Beck, I think there’s something a little unhealthy in some people attitudes.   I’ve seen trained professionals claim that they can’t do something because “Scrum doesn’t say they can.”  I’ve heard them take umbrage with questioning what their favorite author’s written, as though we were questioning the word of God himself.   How dare we question the word of Schwaber?!?

There’s a little bit of magic in agile techniques like Scrum or XP, but there’s tons of common sense.  For instance, people noticed that big, up front designs tended to take a long time, be wrong, and worst of all not be used very much.  Why were we spending good money on doing this?

It was really helpful to create the design,  because you got a chance to think through your structure and behavior issues, and if you did that with the whole team, then you could throw away the actual model document and still get the benefit: everyone’s on the same page.  Better yet, if you modeled just in time, then you didn’t base your model on bad assumptions, outrunning your headlights so to speak.  Voila, just in time, lightweight collaborative modeling tends to work better in many circumstances.

I don’t think the agile authors wanted to create a cult of unthinking zombies.  I’m pretty sure that Scrum doesn’t mention design modeling because not every project needs design models, and those that do need something different in the way of rigor every time.  In that kind of environment what are your choices?   Choice one: you could say “you should do enough modeling, and when you need to” and rely on people to figure when and to what degree to model.  We tried that, it hasn’t really worked that well in practice. This is how we got to big, up front design.

Choice two: you could not mention modeling at all, cutting the process down to it’s barest essentials, then rely on the practitioner to use common sense to determine when and how much to model, based on what they need.  It just seems Voltaire was right, and common sense is quite rare.

I give the authors a lot of credit with coming up with these approaches,  it takes insight to look at Industry Best Practices and say that the emperor has no clothes, but  I’m deeply troubled that some people are looking for the next “one way to do it.”  One of the twelve principles of agile is

At regular intervals, the team on how to become more effective, then tunes and adjusts it’s behavior accordingly.

That doesn’t sound to me like “check your brain at the door, because we’ve got it all figured out for you,” but gosh that seems to be the way that some people act.

Gentle reader, it probably sounds like I’ve just had a bad day, but this has really been brewing for a while.  I’m tired of hearing “Well, Schwaber says…” as though Ken had decended from the cloud to give his opinion to us on our specific circumstances.  I just want to say “it’d be nice if you thought for yourself.”

I think this is the way that processes die, too.  I bet that many of the processes that we’ve ever invented for software development were minimal collections of good ideas at one time.  We thought, “well, let’s try to think about the design before we just run off and write software.”  Hm, probably a good idea.  Over time, it becomes enshrined as part of The Process, and soon you can’t do it any other way without getting nailed by the process police.

Gradually, processes collect a bunch of things that were a good idea on this or that project, because someone said “doing xyz worked well with this other project, we should make it a best practice and always do that.”  Soon xyz is part of The Process as well, and oh by the way, it’s MANDATORY, never mind if it adds any value to you for this project.

The fatal flaw in the thinking is that no two projects are ever the same. Agile is brilliant in it’s focus on minimal process.  We specify just the skeleton, and the authors have defended that minimalism, bless them, which hopefully will keep agile from accreting all the bells and whistles that will eventually drag it under.

When agile fails, it will fail for one of two reasons. Either because we’ve lost the battle to keep the process minimal, and we’ve now got some bloated monstrosity; or enough practitioners will have become so dogmatic in our belief in Scrum (or XP, or whatever) gives us all the answers, that we fail to think about what’s the right thing for this project.  When that happens, and we fail because we didn’t do what was right for this project, the powers that be will conclude “well, agile doesn’t work” and we’ll be on to the next process.

I’m sure that some will want me disbarred from the Agile Alliance for speaking my mind, and for questioning their favorite author, and quite frankly, that’s kinda my point.  Agilists shouldn’t be shutting down conversation with “the process doesn’t say we can do that,” or other forms of mental violence like “My author citation is bigger than yours,” we should be concentrating on what’s right for this project.  I can only hope that people continue to think, and not rely on an agile religion to tell them whether they’re right or wrong.


Comments

RSS feed | Trackback URI

2 Comments »

Comment by Jamie
2011-08-10 08:09:19

You are right. Most religions have a small piece of truth buried beneath the process (ceromony).

The problem is that most people don’t understand what you do, namely the spirit of agile and not its implementation.

You may like this, which also has some comments on the matter.

http://www.financialagile.com/reflections/9-general/104-followers

J

Reply to this comment
 
Pingback by Agile as Religion | Agile Doctor
2011-10-05 23:42:19

[…] recently read a blog by Keith McMillan about this –  called Process as Religion or How Agile will Fail. I don’t throw his name around because he is one of the anointed disciples, but merely to give […]

Reply to this comment
 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll