When someone asks a simple question about “agile”, and you try not to write a book in response

From: Wife (work)
To: Me (personal)
Subject: What’s your opinion on Agile?

[Blank email]


From: Me (trying to not open multiple boxes of Pandora, clean multiple Aegean stables, or attempt solutions to multiple enigmas wrapped in mysteries)
To: Wife (work, which by the way is nothing to do with software or web or anything like that)
Subject: Re: What’s your opinion on Agile?

As a way to make software? I’m very much in favour.


From: Wife (just asking questions that probably seem totally normal)
To: Me (personal)
Subject: Re: What’s your opinion on Agile?

What about the process being used in different contexts?


From: Me (doing my best to not obsess over the way ‘agile’ is not a process)
To: Wife (work, possibly while googling ‘Agile’ for the first time)
Subject: Re: What’s your opinion on Agile?

Hmmm.

I’m going to try to not get too detailed here, because this could turn into something book-length.

1. Manifestos

Agile software dev began as a manifesto – a set of principles. This can work anywhere, and I like it. There are a bunch of other disciplines that have copied the idea of explicitly stating “we value X more than Y, A more than B, and C more than D”. It’s a good way of thinking through what you do, why you do it, and who you do it for (without thinking too much about how you do it).

This is something eminently adaptable to different contexts.

2. Processes

One or two layers down, you get to “how we do things”. This is where Agile splits into a bunch of different religions with the same god.

Some people believe that “it’s not agile unless you’re doing a 10-minute scrum every morning” or “it’s not agile unless all your tasks are written up on a shared board”. This focus on process is wrong (see the manifesto: it doesn’t give a crap how often you meet or where you write your to-dos).

Usually when people want to do agile, they’ve seen a set of processes that they want to adapt. Depending on the processes, this is where context matters. Agile software development usually needs you to break big pieces of work into lots of little pieces – ideally pieces that don’t have to be done any set order. For software that’s fine, but there’s a lot of things that you can’t do that with. You can’t write a novel by doing all of Character A’s story, then doing all of Character B’s story.

My opinion on agile at the process level is that there are a lot of really useful practices that can be adapted to all sorts of uses in all sorts of contexts, but there’s (a) no set of processes that combine to become ‘the way Agile ought be done’; and (b) there’s no complete set of processes that can be usefully picked up and carried from one context to another. At [former employer] – the best agile house I’ve seen in action – different teams would use different processes. They were all agile, and they were all good, but even the slight context switch from [building one sort of thing] to [building something very similar] meant that a different set worked better. SO…pick and choose carefully, trial things, see what works and keep doing it; see what doesn’t work and stop doing it.

3.Tools

Another layer down. Slack, Trello, sticky notes on a whiteboard, JIRA…whatever tool you use to track your work and let people see where you’re up to – that tool is not an “agile tool”. It’s a thing that you’re using in an agile way (if you’re using it right). It’s very easy to use these things in non-agile ways. I’ve seen teams think they’re agile because “we have Trello now”. No. Just no.

But such tools are incredibly adaptable and can work pretty much anywhere.

4. So.

Working out loud, doing one thing at a time, demoing your work publicly, organising things into sprints and having sprint routines (e.g. demo sessions, post-sprint retros), sizing tasks collectively, letting teams choose their own work from a backlog they don’t directly manage…these are all adaptable things that I reckon you could pick up and work with almost anywhere.

Ok, I have a drop-in session to go and run. If this makes sense, then awesome. Otherwise, let’s talk.