Does the Agile Manifesto Ironically Rigidify the Agile Software Process?

The four tenants of the Agile Manifesto are certainly a sexy quartet. Difficult to properly harmonize at times, but certainly helpful to companies looking to move forward in an accelerating technological environment. However, too many agile developers forget the sentence that the 2001 Utah ski lodge group placed right after the Big Four:

That is, while there is value in the items on the right, we value the items on the left more.

This is definitely not as sexy, but it is necessary to understand the true agenda the Manifesto puts forth. Rigid adherence to the four tenants of the Manifesto without acknowledgement of the flexibility that its less famous continuation gives your process may increase your bottlenecks and rigidity. Let’s take a look at how the Agile Manifesto needs its own agility in order to work.

Individuals and interactions over processes and tools.

If your company can afford the best talent and the time necessary to cultivate synergy between individuals (and their inevitable egos), then certainly, allowing for complete freedom of process can be advantageous. Talent, however, can be too abundant for its own good. Plucking a great library of newly automated functions from the “SDK tree” is no crime, especially if the creative juices of your team would be better spent dealing with mission critical points within the software! Your team will have enough purely intellectual exercise reducing the risk of the dependencies that naturally build within a process as more procedures are implemented into a software package.

You may have a whale of a client that insists upon compliance with ISO 9000 processes. This might be inefficient for your team, but too much individuality here might cost you your business. Perhaps it is best to keep some industry standard tools on hand to quickly comply with clients who have a particular process in mind, suggesting improvements once you have gained trust?

Working software over comprehensive documentation.

On its face, this statement is obvious. Getting to the point in today’s lightning fast world of technology improves your chances of getting business and keeping a schedule of deliverables on time. However, there is nothing worse than that client who can’t decide what he wants until your team has already spent hours upon hours streamlining a software iteration that you thought was thisclose to perfect, by the client’s own words. With extremely large projects, it also benefits everyone involved to agree contractually to a deliverable over a technical outlay so that the valuable time of your developers is not wasted.

Customer collaboration over contract negotiation.

Reading this tenant literally assumes the worst of tech companies – that coders are actually those unsociable trolls typing away computer code endlessly in the shadows of a dark basement! A successful client to company relationship is built on a two way stream of communication that may occur best over a set of initial terms. Contracts can be made quite vague, as any lawyer can tell you. Once the general terms are set, programmers have a set of parameters to start with. This greatly reduces time to market and makes errors easier to find. Also, contrary to popular belief, setting a standard actually increases room for creativity rather than decreasing it. An analogy:

If someone asked you to write a piece of music, you might stay at the piano for years before you actually composed something agreeable to that person. However, if composer and patron contractually agree that the piece of music should suffice for a Renaissance Halloween party, and thus be composed in waltz time in A/B format lasting for 15 minutes, the composer will likely finish an acceptable piece much more quickly!

Responding to change over following a plan.

How about responding to changes in a plan? Technology moves, and disruptive technology moves with even more volatility. Clients will also change their minds as much as you let them, which will eat away at your time and patience. Fundamentally, customers are coming to you for your expertise. They want you to have an initial plan. This plan can account for future contingencies, however, and list alternative paths should a certain instance take place.

Agile is great in theory. We need to make it work in the real world. The real world has customers who are unsure, need guidance and may prefer rigid plans and contracts. The real world has programmers who will work ad infinitum to perfect the elegance on a non-critical point and make everyone miss the deadline. Agility without a structure to be agile from is just wobbling around. Don’t be a used car salesman balloon thingy and wobble in the wind. Those things are scary, and you know it.

The original writers knew that the Agile Manifesto itself needed agility. The line after the four tenants, the one that no one pays attention to, is the line that actually puts the agility in the agile development idea. Give it the respect that it deserves, and you will find the right agile balance instead of trying to adhere to an intellectual standard that was never meant to be embossed in stone!