Agile or You Keep Using that Word; I Do Not Think It Means What You Think It Means.

Its funny.  Many of the more recent blog posts have come from ideas or thoughts or reactions to comments and discussion at the local tester group meetings.  I think there's a blog post in there, but this one is triggered around an idea I've have for some time.  Of course, it came together clearly during a lightning talk at the most recent meeting. 

Yes, yet again the local testing group had gathered to discuss testing and eat pizza.  I don't know if it is the collection of bright people sitting around munching on pizza just talking - no slides, no formal agenda - just folks talking about testing - or if it is the collection of minds engaged in thought on the same topic that I find so interesting. 

The Trigger

One of the presentations discussed "The Fundamental Flaw in Agile" - and was based on the presenter's experience around Agile environments in software development shops.  Her premise, which I can find no fault with, was that most shops "doing Agile" make the same mistake that most shops did with "Waterfall" and experience very similar results.  That is, the belief that there is a single inerrant oracle for "user information" for software development projects. 

Mind you, she is no slouch and is extremely talented.  In fact, one statement she made was the key to allow my mind to pull things together, and that in turn, lead to this blog post.  You see, sometimes (like at conferences or presentations) I use twitter to take notes.  Other times, I outline ideas then add ideas around that outline and that turns into a blog post.  Then sometimes that blog post turns into the foundation for a presentation or longer paper. 

You see, I've worked with some really bright people in agile environments.  I've also worked with some really bright people in Agile environments.  I've also had the pleasure of working with some really bright people in Waterfall environments. 

Some of the people in the first group (agile) are also in the third group (Waterfall.)

Nah, Pete - you're kidding, right?  Everyone knows that Waterfall is not agile.

Really?

I'd argue that the way most people functioned and called it "Waterfall" was anything other than "agile."  It certainly had little to do with the Agile Manifesto.  Now, I have some theories around that but they will wait for another time. 

I might suggest that the ideas expressed in the Agile Manifesto were the extreme antithesis of how many folks "did Waterfall."  I certainly would suggest that the idea of using "Agile" to fix software development practices of some shops is equivalent to the silver bullet solution that gave us project managers and business analysts and other folks getting involved in software development with limited experience  in the field themselves. 

Now, an aside.  I do believe that some very talented people can help move a project nicely.  They can be Project Managers.  They can be Business Analysts.  They can be Programmers and Testers and DBAs and on and on.  The interesting thing, to me, is that when I got into software development, the common title for those people doing the bulk of that work was "Programmer."  Anyone else remember when programmers were expected to sit down with business users or there representatives and discuss in a knowledgeable way how the software could help them do their work better?  Now, avoiding images of people getting excited and yelling "I'm a people person!" why is it that we figure people who are good at technology stuff should be un-good with people stuff?  I don't know either.  But for now, let's leave that and consider it in another blog post.  OK?

Right.  Where was I?  Oh, yes.  Silver bullets. 

Many shops where I've seen people "doing Agile" seem curious to me.  In fact, I get curious about them in general.  I ask questions and get answers like "No.  We're Agile so we don't need documentation."  A close second is "We're Agile so we don't need to do Regression testing."  Third most common is something like "We're Agile so we don't track defects..." (now up to this point, no worries; the worries normally come after) "... because we don't do documentation." 

Thus the thought that pops into my mind,,,

"I do not think it means what you think it means." 

Now, I'm not the sharpest knife in the drawer.  I make a lot of mistakes and I have said some really un-smart things in my time.  Having said that, those folks I sometimes hear selling "Agile" to people - and neither the person selling nor the potential customer/client have a decent idea, or at least a more clearly formed idea of what "Agile" means, than I do.  I mean, come ON! 

Listen to what you are saying!  "Oh, you have communication problems! That is because you use Waterfall!  Agile fixes that!  You have customers not getting what they need! That is because you use Waterfall!  Agile fixes that too!"  And on and on and on...

sorry.  got excited there a moment.

Here's what I'm getting at.  There are some really smart people who firmly believe that Agile methodologies are fantastic.  I think there is a lot to recommend them.  Really, I do.  I can agree with everything listed in the Agile Manifesto - Really! 

I disagree with the way some people interpret Agile.  Why?  Because they are missing the point.  In my mind, the entire purpose - including dropping the stuff that is not needed, that does not move the project forward, etc., boils down to one thing:  Simplify Communication.

By that I mean exactly that - help people communicate better by breaking down the barriers that get pur in the way by process or by culture or by evil piskies. 

It seems to me, that is the greatest flaw in "Agile." 

Without good communication, Agile projects will fail.  Full stop.  If you do not have good communication, nothing else matters. 

When you replace one set of burdensome processes with another and wrap it in the banner of "Agile" have you really made it better?  Really?  Is the process the key?  Really? 

Do me a favor and  grab a dictionary and look up the word "agile."  Go ahead, I'll wait.

OK, you're back?  I bet you found something like this...

Adjective: Characterized by quickness, lightness, and ease of movement; nimble.



Wait.  Did you look up "Agile Development" or "agile"?  Yeah, consider what the word means - not the methodology but the word. 

Now. Someone please explain to me how folks demand that something be done because "that's what you do when you're Agile" is really agile?  If they are following form over function - doing something by rote - without explaining to the rest of the team why this is important (I understand that each Scrum master or whatever the "leader" is called needs some leeway in approach) then will the team see any more value in this than in the "evil" methods of "Waterfall"?

Then again, in my experience, what is the difference between teams that were successful and those that were unsuccessful in Waterfall?  Communication.