Back to Basics with Agile

This week Harvard Business Review published Why Agile Goes Awry — and How to Fix It by Lindsay McGregor and Neel Doshi. The article argues that many of the companies who claim to be agile have actually forgotten the four agile software development values defined in the Manifesto for Agile Software Development:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

It’s been a while since I read those values. It’s actually possible that the last time I read them carefully was when I was still studying at university. This is when I had no real-life experience in software development projects. I had no idea how much is contained in these simple statements.

Before we continue, let me acknowledge the fact that I currently have zero professional certifications. Since my university studies I haven’t done any formal courses related to agile software development practices.

I do read and listen to content related to project management. I work in a company that promotes agile working methods. However, I wouldn’t be able to give you a detailed explanation on how Scrum works for example.

I’m telling you this because I don’t want you to read this post as a guideline to how agile works. Instead, I’m hoping that this post will inspire you to reflect on the agile values themselves.

You might be now thinking that, unlike me, you do remember these values. You know agile. But keep in mind that agile is not like riding a bike. You don’t learn it once. You will forget what agile is really about. Bad software development habits will creep in if you don’t pay close attention.

You will diverge from the agile software development values because it’s so easy to keep your focus on processes and tools instead of individuals and interactions. You will try to ignore change by following your carefully made plan.

You might also go to the other extreme: you’ll start remembering “Responding to change over following a plan” as “Don’t try to make plans.”

McGregor and Doshi suggest that your team should have a habit of “constantly diagnosing and iterating [your] operating model.” Some teams do this diagnosing on a monthly basis.

These teams know that being agile is about finding a balance over and over again.

***

Lately I have found myself obsessing over processes and best practices in software development. At my work I’m going to take a pause with that stuff for now. Instead, I’m going to obsess over the four agile values.

At the time of writing I still don’t have a good idea of how to make this reflection a regular habit. I’m starting by taping the agile values next to my desk.