Agile for non-profits How to "do agile" for non-technical teams

Everybody wants to be more agile. It’s like the organizational equivalent of going gluten-free, or planking. But how do you do it?

“What’s best book out there about agile for non-technical teams,” my wife asked me. I was stuck for an answer. There’s a few bits and pieces, and lots of blog posts — but I still found it hard to refer her to a great resource. So we made up our own.

I’m sharing what we did here — please tell me where I’m doing it wrong. There’s a bunch of added context here — but I’m trying to strip this down to the *least about of reading and work required to start seeing some benefits early.

Agile = continuous learning and improvement

That’s how <name> explained it to me, and I think he’s right: at its essence, an agile approach is about creating rituals and systems for continuously improving — what in Japanese we would call kaizen, or what my colleague David Ascher would call “getting better at getting better.” The reaons for this are manifold — chiefly: because continuously getting better increases our chances for success, build stronger relationships, and (crucially) feels good. There’s an agile mindset that’s as important as a bunch of systems and procedures.

The most simple idea: agile breaks big goals into small pieces, then shortens the feedback loops between planning, building and delivering so that you can learn and adapt as you go. This reduces risk of failing, makes the work better, and allows your team to learn what they’re applying and course correct as they go.

How do you get started?

I’m going to skip over all the jargon and blah blah and try to deliberaly boil down and simplify. This is how I do it — others can tell me I’m doing it wrong. But I think at the end of the day, you’re best to focus on three things:

  • Objectives — what are you trying to do? agree on 1 to 3 big short-term objectives, and use a simple template to make them clearer.
  • Heartbeat — design a process for how you’re going to prioritize work against those objectives. Have rituals for how to prioritize, kick-off, leave people the hell alone (so they can actually get work done), and then have a big retrospective “learning part” at the end to unpack what you achieved and learned.
  • Tools — the least important piece — but you’ll probably want to experiment with and eventually agree on some agile tools for your superhero utility belt. A few tools (like social chat: (IRC or Slack), some way to do distributed retrospectives (like Retrium) and maybe an issue tracker can work well. The important thing is just to find ways to push out of the broken telephone of email and dull meetings. Smart tools can help.

Objectives

I’ve become a big believer in Objectives and Key Results.

Heartbeat

This is the most important bit in

Retrospective