Do retrospectives (just make it up as you go)

A great product development process is not a one-size-fits-all solution. Many parts of “Agile” might not be useful for your team. There are good and bad patterns, but there is not a rigid process that everyone should follow. A rigid process is inflexible and brittle. A great process is form-fitted to the humans and circumstances it exists to serve.

It’s closer to improv theater sports than it is to a pilot’s checklist. It’s interactive, emergent, and iterative. The longer you refine it with one group of people, the stronger it gets. This is because you’re dealing with humans, not the laws of physics. Humans have weird proclivities, communication styles, working hours, and tolerances. Group together 3 or more humans on a team and you’ve got a unique set of needs.

Finding the right process takes careful attention, frank conversations, flexibility, and humility. You’re going to make it up as your go — and that’s a good thing.

My first product management role was at a startup that had a chaotic development process. Our CTO wrote most of the code without review, there were no tests or tickets, things were wild. This is normal at early stage startups, no big deal.

I prepared to save the day. I armed myself with with Agile sprint plans and SWOT analyses. I made a long, boring presentation about how product processes should work. I believed I had all the answers, even though no one had asked any questions. I had a prescriptive solution to a problem no one else yet believed we had. It was too complex and detailed for anyone to latch onto. I was spraying them down with a firehose of prioritization, customer interview tips, sprints, and estimations. There was no room for anyone else to weigh in.

My brilliant plan went nowhere:

• The team did not see the problems for themselves, and so they were not interested in my solutions. The process felt burdensome and unnecessary. This was a top-down, one-size-fits-all approach.
• I tried to make tons of changes all at once. Many of them were not necessary. Sure, we needed a ticket system. But no one needed a lecture about the nuances of the Fibonacci estimation scale.
• I introduced a bunch of meetings and new processes that ended up wasting everyone’s time.

Every team is unhappy in its own way. You don't need a burdensome, rigid process. You need a reliable way to (1) identify what’s not working, and (2) implement relevant solutions. Do this over time, with the whole team’s involvement.

So how does this continuous improvement process happen? Through the magic of retrospectives. A retrospective is a regular team conversation where everyone shares:

1. What’s going well?
2. What could we improve?
3. What specific changes do I want to make?

Simple. Brief. Lightweight. This can be a 20 minute meeting. Everyone should share their list. Write down what they say. Pause a moment to celebrate (1). Seriously, do that. Discuss which items from (2) and (3) the team actually wants to address, and then let it be so. Finally, read back through changes suggested from previous retros. Are those still relevant? Did we actually make the change?

This is thematically similar to my post about reducing project scope. Don’t over-engineer your projects, and don’t over-engineer your process. Identify a problem, agree to a solution, see the results, and repeat. Don't fret if you didn't solve every problem in your first meeting. You'll be doing this again in 2 weeks. Within a short amount of time, you’ll have a tailor made process. If the team changes, and grows out of that tailored fit, you have a process to identify that and fix it yet again.

There’s not an end point here. Continuous improvement is part of the job. One of my first bosses used to say, “Suck less every day.” And that’s pretty much it.

Later in my career I joined a team with an excellent lead developer. We did weekly feedback sessions, and team-wide retrospectives after every project. Here’s a little sampling of what came out of that:

• We were both anxious about the complexity of our next few projects. He suggested we write every ticket together. It took longer. But we had total visibility to each other’s work, and everything we did had an extra set of eyes on it. We were in lockstep.
• A junior developer wasted a month building an interface for external APIs that we didn’t need. We decided that (1) every project should have an engineering design document, and (2) these docs should have two reviewers, not one. Make every project explicit, and get some more eyes on it. Problem solved.
• Our devs were losing entire weeks to devilish bugs that were hard to fix. New team policy: bugs are always 1 point tickets. If the bug investigation takes longer than a day, write up a better ticket, and share it with the team for re-prioritization.

These aren’t hard and fast rules that apply to all teams at all times. But it’s what made our team work. Within a few months, we were crushing. A year later we had a re-org and I had a new lead developer. Through our retros, we landed on totally different conclusions:

• The new lead found our old process burdensome. He suggested, “Give me a good scoping doc, tell me the priorities, and I’ll handle tickets and sprints.” Easy win.
• I lost some visibility to project progress, so we started doing shorter retros more often.
• Devilish bugs were still a problem. The real problem wasn’t the number of points on the bug, it was the lack of clarity in the tickets. New policy: we never work on a bug unless it has clear “steps to replicate.” If the developer can’t replicate it, how can they work on it?

Our meetings, schedule, task ownership, tickets, everything was different. And yet, it was healthy and productive. The natural evolution of good retros led us to a different destination in just a few weeks. Neither process was strictly Agile, and both processes were appropriate and productive.