Pick Your Agile Flavour

I’m not a hardcore follower of Agile, Waterfall, Scrum, Kanban, and all their variants, but I relish getting asked questions about the topic.

The conversation usually goes a little like this when I’m asked it.

Them: Do you use Agile?

Me: That depends on what you define as Agile?

(Insert awkward laugh)

Me: No seriously, how are you using Agile?

From there we go down the hole into an awkward conversation where the people I’m talking to look at each other, try to map out the process on the fly and give it some kind of a cohesive feel to it that resembles a process.

Them: Yeah, we create the story points and then timebox them to the sprints to deliver them and then hand off the work to be done. Oh, and we have daily standups once we start going.

This conversation is normal and my initial response when I hear this bit of vaguery is to reassure them.

Me: Okay, so you’re building the process, figuring out what works and what doesn’t and tweaking as you go.

Them: Yeah, yeah.

Me: Okay let’s get started.

I don’t mind the vaguery or the changes in implementation (as I’m not an Agile purist) and I think this makes a ton of sense — code for where you are and what you know — but I do get disgruntled when I hear — “we can’t do this because it’s not agile”.

We can’t let our requirements take more than a few days.

We can’t extend the sprint a day.

We must go fast and deploy, there is no thinking.

Who says? If that’s what you need for your product, team, and company then go with it and do it.

Here are a few tenets I’ve come to live by when discussing Agile with customers;

  1. Your first few sprints will be the most painful, build in extra time and drop the workload. You will not deliver everything in that sprint, that is okay — iterate and move forward.
  2. You’re doing things in a “sprint” not a rush, so there is no room for laziness. If you can’t write the proper requirements in that time, you will not be able to write proper code in that block either.
  3. Progress and updates are key — if at the end of the week you have no updates of completed/remaining activity in your work then you’ve lost a week of progress.
  4. Have you built in time to test? No? Then what are you hoping to release?
  5. Don’t worry if you are tweaking the process along the way. That’s the goal, to find something that meshes with your team and keep working towards it.

When the delivery of software is kept simple — requirement, code, deploy, test, repeat — whether in a 2 or 3-week blocks or using a markerboard, post-it notes, GIT or DevOps it’s all the same — work was delivered. Don’t get hung up on the process and the following everything to the T, when you do that — you make the process the delivery and not the code.

Start small, increment and tweak, build on each success, learn from each failure — give it a name and call it your own flavour and build adoption.

And when someone asks you if you use Agile, be proud of the flavour you use, because it works for you and that’s what matters most.

Want more? I run BetaRover Inc, muse on The Sniffing Markers Podcast and purge all my thoughts on Rambli.com — have a peek, read or listen.