Agile Programming - A Poor Choice of Words?

Agile Programming is a popular programming methodology.  But it's not alone. There are other methodologies such as the Rational Unified Process, Spiral, and the traditional Waterfall methodology in common use.  Each has it advantages and disadvantages and each is named in a way that describes the process.  However with Agile its very name can tend to cause confusion.  "Agile" gets confused with "agile".  Wait a minute.  Other than the capitalization aren't they the same things?  Well not exactly.  Agile with capitals does mean something different than lower case agile and that's where the confusion comes in.

Agile (upper-case) programming in overly simple terms is a method of developing programs using closely knit teams to quickly produce releasable code in short time frames.  Based on the Agile manifesto principles it has some certain processes.  Wikipedia provides a good overview and a simple Google search will provide a mass of references. 

agile (lower-case "a") programming simply denotes being flexible in our design and adjusting as we go.

The term Agile was no doubt derived from its lower-case counterparts and that's where the difficulty comes in.  When we speak of Agile others often hear agile.  And after all who wouldn't want some flexibility in programming?  So very often you quickly get buy-in to employ this methodology when you use this term.  That is until the realization sinks in that what your user thinks they bought is not what you thought you were selling. 

Another way to look at this is the debate of whether Agile/agile is a noun or an adjective.  Cory Foy's recent post presents a good discussion on this.  And while all of this discussion upper-case or lower-case, noun or adjective may seem like we are debating how many angels can dance on the head of a pin there is an important concept here.  That concept is about getting everyone involved to have the same understanding of how you are going to approach the programming on a project.

Agile (upper-case/noun) programming will call for closely knit teams of developers and users dedicated to the project, physically located together with an emphasis on face-to-face communications and delivering small releasable segments in a short time frame.  While this can be a very effective method it can also be a difficult one to get started. 

Agile can represent a significant change in the way we've always done programming both for our developers and our customers.  Presumably our developers are familiar with the term and understand its ramifications.  With our customers it may be a different story.  They may hear "agile" (lower-case/adjective) and assume it just means they'll have some flexibility in changing the design once it is completed.  Unless our customers understand this process, what it commits them to and are willing accept it our projects may be in trouble right from the start.

Because of this I believe that one of the keys to using Agile successfully is to provide adequate training for not just your developers but also you customers.  It also involves communicating the concepts to the customer managers not directly involved in the programming to properly set their expectations of what to they will get and what they must provide.

By the way, since we in IT sometimes get involved in Lean initiatives we should be aware that the same problem is there for Lean/lean.  Sometimes a very descriptive names has some unintended consequences that you must deal with.

How do you deal with the Agile/agile situation?  How have you communicated the concepts to your users?  Let's talk.

"20070925_1320 Acrobat" photo by williewonker

If this topic was of interest, you might also like these:

• Should We Stick To What We Know?
• ITs Weasel Words
• It's Not What You Say, It's What People Hear
• Or the posts in the "Application Development" category