Picture it: A programmer in the eleventh hour of his months-long development cycle, desperately trying to complete his feature list. His palms sweaty, he slugs down another cup of coffee, trying not to think about the client meeting toward which he and his team inexorably march.

Software testing is out the window at this point. Sleep is a forgotten concept.

He’s in the grip of the “waterfall” programming method, where a development team makes a list of requirements with the customer, then retreats with that list into a deep, dark cavern. Eventually, the team emerges with software that will hopefully prove to be a good match for the requirements that the customer laid out all those months ago.

Even if the team follows the requirements list to the letter, the code they produced very likely will not meet the needs of the client they face today.

This doesn’t get anyone anywhere. Programmers want to do good work. They want to look forward to client interaction. And they want to not have heart attacks.

The Big Brains Get a-Thinkin’

In February 2001, some programmers got together in Utah to have a chat about “lightweight” software development, striving to shed to the weight of regimented, micro-managed methods.

“Hey guys,” one said, probably, “What if we take these crazy death marches we keep doing and break them into manageable sections that we can then iterate upon?”

There was a general murmur of agreement, and hopes rose a bit.

Another might have said, emboldened by the murmuring, “And what if we include the customer in the development team so that we never get way off track?”

The murmur now perhaps rose a bit more, and smiles began to appear on some faces. Feeling the rising hope and happiness in the room, a woman stood, then faltered.

“Go on!” her fellows encouraged.

“What if,” she began, then looked around the room again.

“Say it!” the other coders whooped.

“What if we embrace change, rather than fearing it?” she said.

A silence fell across the room. The programmers looked at one another. Then, one rose, spread his arms and bellowed with pure joy. The room erupted in shouts and cheers, and agile programming was born!

The Manifesto Emerges

Out of this surge of joy, which may or may not actually have occurred, came The Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

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

With this method, agile programmers make the process of development easier and better, increasing customer happiness as a result. The customer becomes part of the development team and is a key part of development along the way.

At Highgroove, we embrace the agile method. We focus on constant communication with rapid feedback, so that software development can move at a rapid pace. We build and launch in phases, and do continual development, incrementally adding features to create exactly what clients envision.

Image credit: clango