Every thursday morning, we meet over tea/coffee with other people living in Toulouse. We call that event “Code & Coffee”.

Reinventing the world

There are no rules over those mornings. We may take our laptops out and hack a bit. More often though, we discuss and reinvent the world for an hour. A recurrent subject of discussion is how we work, what are good practices or aren’t.

During one of those discussions, I had a sort of epiphany.
I often hear people talk about agile methods. And while discussing that, I realized in 2 years working at Heroku, I never heard anyone say or write that word. Ever.

And yet, I believe we have an efficient project management process, which could be considered agile.

Agility

The issue with agility is that people tend to make it a “method” or a “process”, when that’s actually the wrong approach.

Waterfall is a method. There are striclty defined rules for practicing it, and if you decide to change those rules, you’re not doing waterfall anymore.

Agility does not follow a strict set of rules. Of course, you can’t keep doing waterfall and say “I’m agile” to actually be agile. But you also don’t necessarily have to do daily standups, fire your project manager and hire a scrummaster instead (It would be the same person anyway). Agility is a way of thinking how projects are handled, by focusing first on shipping your product. And that’s something each team will do differently.

Any strict rule someone would try to apply on top of that would be counter productive.

Continuous improvement

I’d like to propose we ditch the agile word out of our vocabulary. It had it’s time, and people are using it for everything and nothing today, so that is doesn’t mean anything anymore. Instead, Let’s put the most important bit of agility first. Continuous improvement.

After each project, let’s ask ourselves some questions (this is definitely not an exhaustive list).

• How did the project go?
• What could we have done better?
• What went well?
• How did this retrospective go?

And, most important of all, act on what we say. If what went poorly during the project is that we didn’t get customer feedback early enough, let’s fix that.

Once this is done, we can move on to the next project with our changes. Iteratively, you will reach a good process which works for everybody at that time. The day that way process doesn’t work anymore, you will iteratively change it again.

Going farther

Let’s not only do rerospectives for projects. Let’s not only do them for a team.

Got a production incident? Learn from it, and take measures to prevent it from happening again.
It’s friday? How did the week go? What could you improve in the way you work individually and as a team to be more efficient?

Wrapping up

Fixed methods are inherently bad. They assume everyone works the same way, and we can all be productive by applying them. Getting out of that way of thinking will get us more productive, as we adapt our way of working with what actually works.