I have spent a lot of time trying to figure out what ‘Agile’ is. Back in the early/mid 2000s, after the tech bubble and before the great recession of 2008, there was a brief period of optimism and solidarity in software engineering. We learned a lot from the booming late 90s and from the bubble bursting in 2001. Aside from the economic turmoil there was also turmoil in the personal lives of engineers and developers.  120 hour work weeks, sleeping in the office, breakups, divorces. It was a lot like the gold rush out west in the 1800s, but instead of a material commodity it was information and access/sharing of that information that began really generating revenue and movement.  Along with individuals going gangbusters to get a piece of the information/technology pie, large companies became more excited or greedy about getting a piece of the pie or even a bigger piece of the pie. This lead to many companies rushing plans together that were not the most well thought out and squeezing every drop of production out of their employees.  California, being one of the first to go through a cycle like this, implemented their overtime law. This basically says that even if an employee is on salary, if they work over 40 hours they’re entitled to 1.5 X their pay per hour.  This was implemented because companies were hiring their employees and paying them a ‘good’ salary but then pushing them to work 3X as many hours and thus resulting in a pay cut in reality.

We Respond And Change

After living through and seeing all this happen through the 60s, 70s, 80s and then the 90s, a group of experience people got together and started….’Agile‘!  This is Agile…right here…on the next line…that’s it…read it and pay attention!

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.

You may have read that and thought ‘where does that mention sprints?’, or ‘they didn’t mention the burn down chart!’…etc…etc.  That’s because those things have nothing to do with Agile at all.

I often hear people compare Agile with the Waterfall Model and that really doesn’t make a lot of sense. Agile is a philosophy and the Waterfall Model is a development cycle model. While in college, in my last year, I chatted with a professor about this difference and why I thought it was significant because there was a final version of the Waterfall Model that I thought would work pretty well.  In theory Royce’s Waterfall Model  could even be executed in an Agile environment. The Agile Manifesto is a set of values to be applied when working with humans and in realizing this I think those values are far more powerful than any development cycle or methodology that will ever exist.

We Practice

Try making the Agile Manifesto the first thing you read in the morning before you start working for 1 week.

Individuals and interactions over processes and tools

The next time you hear someone complaining about a process or tool ask them how they would fix it or update the tool.

Working software over comprehensive documentation

When people ask for documentation, make sure that there’s something out there to document.

Customer collaboration over contract negotiation

Work with your client/customer/boss/coworker to figure out what it really is we’re trying to accomplish instead of blindly doing something and then falling back on your contract/agreement when your product misses the mark.  Building better software/products means we have to own a project if we’re participating in it.

Responding to change over following a plan

If something isn’t working…stop…turn…go. None of us live long enough to waste time follow a plan we’ve proven doesn’t work.

Conclusion

Remembering that Agile is actually a set of values and not a methodology could really open up our eyes to improving our methodologies over time. We have been clinging to ‘Agile Methodologies’ too tightly and with that we have ignored one of the Agile principles, “Responding to change over following a plan”.  Let’s keep responding to change and valuing people and interactions over processes and tools to move forward in creating better software for people that can bring us to a better future as humans.

TL;DR;

Um, it’s not that long…just go back and read it 🙂