According to Siddharta Govindaraj, there are five main dangers to be aware of when adopting agile processes:

• Unfamiliarity
• Top-down thinking
• Culture Change
• Incomplete implementation
• Silver bullet syndrome

Out of the five listed I partially take exception to number one and four. For example, number one is easy, pick up a book and try.  Give yourself some credit, you will be able to figure it out.  And number four, I believe that it is ok to do it partially (however, I don’t think it is ideal). In my eyes, doing any part of agile is better than doing nothing. Moral of the story, pick up a book and just give it a try.  If you find yourself having problems, adapt and change.

Gus Power has an interesting quote about the agility of a team,

“Agility of a team is inversely proportional to the number of external people involved.”

If this is true, and I think it is, how do you convince the team to start making decisions for themselves and stop relying so heavily on the external players. Is there such a thing as an “Agile Revolution?” Lots of times team members are afraid to stand up and make decisions on their own. Why is this? I say in the words of a very wise man,

“Get up, stand up: stand up for your rights!”

You and your team will be better off making decisions for yourselves. And don’t forget, it is always easier to ask forgiveness than it is to ask for permission.

Luke Francl over at http://centralstandardtech.com has started a pretty sweet Midwest blog aggregator. You will notice family favorites like Alttext.com (Ben Edwards), Scratch Mount (McClain Looney), Unpossible (Dan Grigsby), Garrickvanburen.com (Garrick Van Buren) and your very own Refactr (The Refactr Crew).

Luke, hats off to you for finally getting a local aggregator implemented. It has definitely been needed for a very long time.

Many of these seem like positives to me, but it’s still worth noting that there are some things you have to be willing to accept if you’re going to go Agile. Most of them are perceived losses due to the transparency of Agile, but these “losses” are really gains for the team and the company in my opinion.

Agile’s Dark Side

I have been on too many projects where the discussions went way overboard (many times through my own causing.) It is so easy to fall into the trap of “let’s just discuss it quick” and one hour later still be debating the finer points of a relatively minor architecture issue. The truth of the matter is this happens more frequently for teams that don’t do pair programming. When pairing is used, the discussions tend to be shorter and you are generally still working while you are debating. So the question is, how much time should “discussions” take?

Here is a simple scorecard you can use to figure out if you have beat-the-horse-dead.

Tally your total points and see below

Now take your TOTAL answer and multiply it by 10 minutes. In the absolute worst scenario the discussion should only take 60 minutes.

If your TOTAL was zero or negative, you should be doing more development and less “discussing.” As a rule of thumb you should limit all design conversations to ten minutes, anything over is waste. If you find your conversations are getting out of control try some of these tactics to reel them back in.

• If you aren’t already pairing, do so. Sit down and pair for a few hours. You will get so much more done than having a 30 minute debate about if you should use polymorphism or delegation.
• Start a team decision maker baton. When you get hung up in a debate, it is the person holding the baton’s job to step in and make a decision. After the dispute is settled pass the baton to a new team member to solve the next problem. This way everyone at some point will be the final decision maker which will foster collective ownership.
• Remember winning the battle doesn’t mean you are winning the war.
• For 90% of you, relax and remember, you are just building a social networking app for teens. It isn’t pace maker firmware.
• Cite actual evidence; show patterns or examples of others in the industry that are doing it like you are proposing.
• Take precedence of a solid object model that represents your domain and reduces your complexity *** (I highlight this one because I think people sometimes take exception to it. Some argue if you spend time on a “solid object model” you are building more than you need right now. I argue it is generally as easy to build it the “right” way than to piece it together the wrong way. When there is a significant difference in time (hours) between “ways” choose the faster, (and I know this is many times at the heart of debate). If they are pretty close in time, (within hours) choose the one that reduces and cleans up your model. Performance should not come into consideration at all at this point.)
• Tell your partner this time we do it his way if next time he promises to do it your way.

I hope these few simple tips will help you save time and headache in your next design discussions.

There’s an interesting post over at Clarety Consulting today that seems to be guilty of spreading FUD about Agile development. In the post the author goes through several “real-world” experiences with Agile techniques and explains why the projects failed because of Agile. The problem with the article, in my mind, is that these failures have nothing at all to do with Agile. All of these projects would have had the same problems regardless of development methodology. The main crux of his argument seems to be that Agile creates a chaotic development environment where the developers rule and everyone else is at their mercy, but I think that has much more to do with the developers you hire and less to do with the methodology they use. He talks about the senior developers being dictators and taking all the good work for themselves, but that goes directly against one of the key tenets of Agile (i.e. no code ownership). It seems to me that the author has had some bad projects, with some bad developers, that were done with Agile techniques and he is choosing to place the blame on Agile when it really belongs squarely on the shoulders of the team itself.

That being said, I do think that the experiences he has run up against are probably pretty common and the Agile community is partly to blame. There are too many in this community that believe that Agile is some panacea that will solve all your problems if you do it “right.” The reality is that development is hard and there is no silver-bullet. Agile can help precisely because it is meant to be flexible, but no one will get that if the community turns into a bunch of raving know-it-alls whose only response to problems that teams encounter is “you’re not doing it right.” There is no one way to do Agile development; it needs to be tailored to the environment you are using it in, just like every other methodology does.

In The Art of the Start Guy Kawasaki tells us to “Make Mantra”. I think this is good practice in any endeavor. A simple message that can be conveyed to all parties, is easy to remember and gets to the heart of what you are trying to accomplish, a mantra, should be concise but it should also think big. Try making mantra in your own life. Where I work, we create software to allow employers to attract, select, assess, develop, and reward people. The unofficial mantra I have taken up when designing the interfaces is: “Build better leaders.” On my kickball team (yes, I am a 31 year old man playing a game for grade-schoolers) we could use the phrase: “Never stop running” to describe our aggressive base-running and, in fact, the secret to our success. When training our new puppy my wife and I could use the slogan: “Just make it past year one”. And in politics, the nation’s Democrats could use the mantra: “Fairness and opportunity for all Americans”.

Mantras are a beautiful thing and can be very powerful. I expect every project I work on to have one or I will make one.