Agile guest lecture series: Manifesto

A couple of times a year, I'm fortunate enough to be invited to give a guest lecture to the graduating seniors in the MIS department at the University of Texas at Austin. The lecture is typically over Agile principles. Given that it's only a single lecture, I try to focus on things that can be immediately applied to the projects that the students are working on. It occurs to me that the things the students and I talk about are things that might interest anyone that is looking for low-hanging fruit towards making a transition to or simply getting started with Agile methodologies.

 The lecture begins with a simple question: What is Agile? Agile methodologies, in their simplest forms, are popular alternatives to Waterfall methodologies in the software development life cycle. They allow us to adapt to changing technologies and requirements far better than traditional approaches to software development. Agile methodologies are inspired by the tenets of the Agile Manifesto (http://www.agilemanifesto.org/).

 The above question is, unfortunately, immediately followed by perhaps a more important question: *WHY* is Agile? As it turns out, the folks that originally wrote the Agile Manifesto did so because they were tired of doing software projects as if they were "fixed" projects. When I say "fixed," I mean that all three sides of the project management pyramid are fixed but the project is still expected to be successful.

These folks were (and are) pretty brilliant, yet despite their brilliance they still experienced far more failure in software projects (or re-definition of "success" such that it fit whatever was delivered) than actual success. The projects went over budget, or over deadline, or didn't deliver the full scope, or some combination of two or three of these three. And inevitably, the quality was never good enough. There had to be a better way to make software, specifically business software, more successful. When they put their heads together can came up with the original Agile Manifesto, they did so with an eye toward which precepts and principles would actually lead to working, valuable software in a reasonable amount of time which allowing the delivery team to learn, grow, and enjoy professional life along the way.

So what are these vaunted tenets? Adherents to the Agile Manifest 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

Do you see the big, boldy words? That's for extra emphasis! 

To be clear, it's not that the words on the right aren't valuable -- they most certainly are valuable. The direction here is that you have to make a decision between the two choices, favor the choice on the left. Favor individuals and interactions over processes and tools. Favor working software over comprehensive documentation.

One of the most important things to recognize here is that the tenets are very much attitudinal and behavioral; they aren't meant to be only procedural. In order to have a healthy Agile environment, you need to have the right attitude and approach. Some teams can't make that change, and that's nothing to beat yourself up about. For the teams that CAN make the change, however... it's a brave, new world!

Stay tuned for the Principles in the next post!