I bet you thought agile development was supposed to be easier than a traditional, prescriptive process! That I would wax evangelical that agile development is the answer to everything, and it simplifies your life. Yeah, just like UML and model-driven architecture and XML and SOA and Web services are silver bullets. Uh-huh, r-i-g-h-t.

If you aren't familiar with agile development, you can check out our manifesto here: www.agilemanifesto.org/. You can also learn more here: http://en.wikipedia.org/wiki/Agile_software_development. The difficulty with "agile development" is that it is "in the eye of the beholder." That is, even a highly regulated, constrained application can be conducted in an agile manner. That manner will be radically different from the way a five-member team might approach building a small desktop software product that they want to sell. Both projects can be agile, and therein lies some of the issues that make agile seem "hard."

Why, then, is agile development hard?

It might not be so much that agile development is hard, per se, depending on your perspective. The reason I give for agile development being more of a challenge for many teams is simple:

YOU HAVE TO USE YOUR BRAIN!

No, I don't mean to infer that you don't normally use your brain. However, in a highly prescriptive process, it is easy to fall into a trap of doing an activity because... well, just because! Typical reasons are that a specific set of steps are mandated by a process, possibly making sense in some projects, not in others. But often, the process grows old, people no longer remember why they are doing a specific task, but do it anyway. Folks get comfortable building some document without ever asking the recipient if it is enough, too much, useless, perfect.
- Don't Mistake Activity for Progress

Developers often jump into the fray by "cherry-picking" specific fun stories and sometimes missing the big picture. For an app that needs to message another app and then do some crunching, I have seen developers working on everything but the core system development needs: the messaging or shelling out of one app to speak to another app. When I asked if they got the basics working yet and are now discussing the pretty frills, they looked around, kind of sheepishly. "No, we don't have the parent app able to message our part yet." If you use your brain and step back a bit, you can see that nothing else matters.

Despite making progress on "stories" they actually had no meaningful progress. Remember, if you can't see it working, it doesn't exist!
- Show Me Working Features

Yeah, yeah, yeah, I know, someone didn't prioritize the stories properly. But, you certainly cannot expect a "customer" to figure out that some weird technical messaging thingy had to be in place first. The customers better only talk about the business and features that are (generally) devoid of technology words.

Development teams have to think more broadly than just coding. If a team understands that the client needs to know about some aspects of the technology that have to be implemented before anything else matters, this should be brought to their attention.

Development teams also need to help with the project management aspects. Yes, that's right. You need to learn how to say "No!" - in a gentle manner, of course.

"So, can we add some more features to this iteration?"

"Uh, since we are three days to iteration 'pencil's down,' let me think. NO! It has to wait until the next iteration."

After all, if you know in your gut that there is no way for a disruptive request to be accomplished, why bother trying? You should always maintain your iteration delivery schedule, slipping features instead of dates. You should always maintain your good habits. Someone has to be the adult ;=)
- Learn to Say "No"

In agile development, you (and everyone else) are charged with the rather difficult responsibility of always challenging yourself to ensure you are doing the smartest thing possible that will bring about the best solution for the current project (and within its context).

You need to set up your agile team for "running fast" through each iteration's features. To start with, I like to model the problem domain to enough of a level of understanding from which:

• Requirements/features can be written using a consistent language
• Enough of an object model exists to anchor the coding
• Enough complexity has been uncovered to make the cost/time estimate defensible

I like to ensure the team can hit the ground running with a list of features in hand, architecture, coding guidelines, automated build scripts, and a domain model from which to hang code.

Sure you can discover all of this piecemeal as you go along, but that is usually slower and less efficient than doing some work up-front to lay the groundwork. No, I am not talking about "Big Stuff Up Front" (BDUF/BRUF) type of an approach. I am talking about using your brain. Do enough up-front work to enable running fast (even with scissors). Maybe: Just Enuf Design Up-front (JEDI - if I substitute "Initially" <g>).
- You Must Lay the Proper Groundwork to Be Agile

By a few iterations in, if you are not ripping through the feature list/user stories almost faster than they can be compiled, you are not yet performing at a truly agile level. If it is "disruptive" that a customer changes the stories scheduled for the next iteration because of changing priorities, you are not yet performing at a truly agile level. If you and your team are not constantly using your brains, you are not yet in the agile state of mind.
- Agile Is a State of Mind!

Post any comments on my blog: www.compuware.com/blogs/jkern/