Myths or Why Agile May Not Save You

It has been interesting of late for me.  It seems that my corner of the world has discovered this way cool solution to all your problems with making software.

Have you heard about it?  It is so neat.  It is this thing called Agile.   Yeah.  Its cool.  There are conferences about it and everything.  And people talk about how great it is.

Now, there are some truly Agile shops around here.  Some have been here for some time.  Some of these are extremely good.  Others demonstrate what I think of as the Magic Myth of Agile.

We all know that silver bullets don't work, when it comes to software.  We know this because we have seen them not work.  So we've turned to the next best thing. 

Magic.

Yeah, that is even better than a silver bullet.

A couple of weeks ago I had a conversation with a couple of people that turned into Pete smashing their dreams into small tiny pieces.  Brutally.

I was talking with them about their current project and asked some questions on the intended functionality that would be gained.  They answered with where to find the answers in the documentation suite.  So I tried again with "What is the business intent in implementing this change?"  I was referred to the business requirements as documented in the requirements repository, which fed the documentation suite.

I kind of wrinkled my nose a little (I was still being nice, really) and asked if "the guys" who were deep into the project could describe what it was that they were doing, just really high-level, space-shuttle level maybe?  Well, they were them.  And they were not really sure.

OK - Red flag.  Big one.

They said the problem was that there were so many steps and so many people involved that no one really knew what the project was doing because everyone just worked on their bit and no one talked with anyone else. 

Hmmm - OK, do you have project meetings?  Can you ask questions in there?  Well, yeah.  They have meetings every week.  Sometimes twice a week.  But the people who are there are too-busy-to-really-answer-questions-and-want-them-in-an-email-and-then-they-don't-answer-emails-and-they-get-mad-if-you-ask-them-questions-on-the-phone-and-when-you-see-them-in-they-hall-and-ask-them-questions-they-say-everything-is-in-thedocumentationandtheyneedtofollowtheprocessandiftheydon'tfollowtheprocesstherewillberepercussionsandtheywillbesorry!!!!!

whew -Yeah, that is pretty much how that came out. 

Then one of them said something interesting. 

"I wish we'd go Agile." 

The other fellow there jumped in "Yeah, that would solve so many of these problems they were having."

I asked which ones?  The lack of understanding of what was wanted?  The people not responding to questions? People putting them off?  Or - worse in my mind - people wrapping themselves in the cloak of the process model to avoid answering questions? 

"Well, yeah, but with Agile we don't need to do all this documentation stuff, we can just start coding.  That is what from says they do and they are Agile." (Spot the magic shop...)

Isn't that kind of what the process was before this new process model was implemented?  Read the request then start coding?  Don't try and work with people to figure out the purpose and need behind the request, just start coding?

"But we knew what they needed or our managers did so we could always ask them" was the response. 

How will Agile help you?

"We won't need all these stupid meetings and we can just tell people what we're doing and we don't need to document all this junk  That takes so long and no one really reads that stuff anyway."

No one?  How do you make the design if you don't read the documentation you're given then talk with people about what that means and how it can be implemented?  How do you determine how these changes can be best implemented if not talking with people who need the changes to do their jobs?

It sounds like part of the problem you are having is in the way information is shared.  If people aren't communicating now, why do you think they will if the shop suddenly becomes "Agile"? 

"Well, the deliverables are all about writing the documentation stuff, not about talking about it.  Maybe if we did less of that, then we'd have a better understanding."

OK, that seems reasonable.  For the documents that you are supposed to be "contributors" on, do you actually contribute?  Is there the opportunity to do so or are they more like, the person "responsible" writes them and that is that?

"He's in a different department and he says that we can't meet with him in time to make the deadlines for the documents to be completed, so he just writes them.  When we ask questions later he says that it is too late and the documents are already approved and we should have thought about that sooner.  Its really frustrating."

OK, so what about the documents you are responsible for creating?  Do the contributors get a chance to really contribute?

"Well, they say they don't have time, or some of them don't understand what we are talking about and stop reading them."

And now the fun begins.

Since Agile is really all about people working together to make good software, how is it that this would work here?  Can people set aside their other projects and spend time on one at a time?  When you have three or four projects you are working on now, how would you expect that to work if we were an Agile shop?

"You don't get it!  We'd still have the same projects, but we could just do them differently.  We would not need to wait for this other stuff, because there is no documentation in Agile."

Really?  I've never heard that from a reputable source.  Most Agile projects I have seen have had loads of documentation.  The difference is that it was all meaningful.  We did not worry so much about the format or the template, but we made sure that the information, like the decisions made in meetings or discussions, were recorded and it matched everyone's recollections.

The other thing I saw was that people worked on one project at a time and saw it through.  There was not the "3 top priority" projects and the extra stuff to fill in when we had time.  We worked on the project and got the best stuff out that we could get out.

"Man, you just don't get it.  That is not what Agile is all about.  We have to get to a meeting."  ... and there was a bit of muttering as they walked away.

I am afraid that the myths are still there and are still as entrenched in some minds as they were before. I should have asked them if their information on Agile was garnered from things they read on the internet.  After all, everyone knows that if it is on the internet it must be true. 

While I can empathize with them for the frustration, I also fear they have no idea what the real problem they are facing is, nor even how they are participating in continuing that problem.