Before I started working in tech, I worked at a non-profit called the Bus Project, focused on expanding access to democracy and building power for young people. My career transition has forced me to learn not just new skills, but a whole new way of working, and lately I’ve been thinking about what lessons I’ve learned that I would have loved to know as a non-tech worker.

For starters, I want to talk about what I’ve learned about the capital-A Agile way of working. Before 18F, I had never formally practiced anything like Agile development. I was familiar with the basic concepts, but hadn’t been a part of a team that really followed the practice. Two years in, though, I’ve learned a lot (and still have a ton more to learn).

I should preface by saying that none of these ideas are my own; there’s a bunch more out there you can read if you’re interested. And if you’re already familiar with the concepts, I can almost guarantee you’re not going to learn anything new here. But nonetheless, since I know a lot of people who don’t work in tech, here’s my take on a few things that I think could be relevant to folks who aren’t making software.

What is Agile?

If you’re wondering why I keep capitalizing this adjective, here’s a quick intro. The Agile I’m talking about refers to specific software development practice that can basically all be summed up by the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

I think of it like this: we’ve all experienced what it’s like when you spend a lot of time making a detailed plan, only for the circumstances to change or for you to learn that some part of your plan either doesn’t work or isn’t that important. Rather than spend more time trying to get the perfect plan, instead just start doing stuff, learn along the way, and intentionally incorporate that learning back into the way you work.

This has been a big change for me, and ultimately I’ve learned to love it. B`ut the parts of Agile that I really love are actually the set of practices that have evolved in response to these principles, and that’s what I want to share here.

Work in sprints

One of the hallmarks of Agile teams is that we work in sprints. A sprint is a period of time — usually two weeks but sometimes one — in which your team commits to doing a certain amount of work. It might have a goal — something you want to accomplish, or a question you need to find an answer too — or it might not. By breaking time into discreet chunks, I find it just makes everything more manageable. It gives your work a nice cadence and forces you to break big tasks down into their smaller components.

At the beginning of the sprint, you get your team together and plan out what you’re going to be doing over the next two weeks. If you’re in the same space, this might look like writing out tasks on post-it notes and sticking them to the wall. If you’re a remote team, you might use something like Trello.

By planning out your tasks as a team, it gives you the chance to build a shared understanding of everything that needs to happen. This helps everyone see how their pieces fit into the larger whole, and also gives everyone a chance to raise issues that are relevant to others’ tasks. For example, if it’s your responsibility to send out invitations to an event, but someone else is in charge of getting the guest list together, now’s the time when you can highlight that dependency (another word we use a lot). Sprint planning is also when you can estimate how much effort everything will take in order to make sure that what you’re planning is reasonable.

Make your work visible

At the end of a planning session, you should have a board that includes a bunch of tasks. There’s a bunch of ways to organize these boards. One popular method also happens to be super simple. It’s called Kanban, and it basically involves organizing your task board into a few columns:

Kanban board

  • To do: Everything you have to do
  • Doing: The things that someone is working on right now
  • Done: The things that are done

And if you’re feeling fancy, you can add a fourth:

  • Icebox: Ideas you might want to do at some point, but aren’t important right now

As you do your work, you move the stickies from one column to the next. This makes your work visible to the rest of the team, and provides an always-visible way of guaging the health of the project. It doesn’t require managers checking in to see how various tasks are going; you can just look up at the board. And because everyone’s work is visible to everyone, it leads to some useful social pressure that comes with that transparency.

Name your blockers

A big part of making your work visible is the daily standup meeting. This is usually in the morning and is a 15 minute time to share three things:

  • What you did yesterday (since the last standup)
  • What you’re doing today
  • And if there’s anything blocking you

That third point is the most useful aspect of standups to me. And in the teams I’ve worked on, it’s not just raising a blocker that’s useful, but the way that everyone else on the team does whatever they can to unblock that task. “I’m blocked” has a special kind of significance that cuts through the noise. Nobody wants to block someone else, and so if you can re-arrange your work in a way that unblocks someone then you do it. This power, I think, comes down to just the simple act of naming the ways you’re blocked.

Do retros

At the end of the sprint, you’ll have a retrospective, or retro. Retros are when the whole team gathers to discuss what worked well, what needs working on and what didn’t work well during the last sprint. Retros help you surface issues sooner than you would otherwise, and let you identify things in the way you’re working that you can change immediately.

I’ve done retrospectives in past jobs before, but always at the end of a big project. We’d take a few hours and debrief everything that worked well and didn’t work well, to revisit the next time. This is no subsitute for doing bi-weekly retros.

Taking an hour every two weeks to do this kind of inward-facing work might seem onerous at first, but honestly I can’t recommend it enough. I’ve never had a retro where I didn’t learn something useful: a problem someone was having or a process that was broken. Plus, if you work with nice people, they’ll usually like to throw in lots of feel-good-y stuff, and who doesn’t like that at the end of a long week?

Ok! That’s all I have for now. Like I said, these are all other peoples’ ideas; I just wanted to highlight some parts of them that I’ve found especially useful.

If you’ve got questions or suggestions, I’d love to hear it. And if anyone ends up trying out these things in a non-tech setting I’d love to hear how it goes. Find me on Twitter.