If I had to describe our agile process in a few words, I’d say we’re non-denominational Agile. We leave a lot up to our individual squads in terms of how they want to operate. One thing we do hold sacred, however, is the retrospective meeting.

If you’re not doing a retrospective meeting with your team, you’re doing it wrong.

For a lot of companies, the stand-up meeting exemplifies agile development. Personally, I could take it or leave it. I don’t necessarily have anything against stand-up meetings, but they’re probably the least useful of any of the “standard” agile meeetings.

Retrospectives are amazing because they reinforce that being agile isn’t just about completing stories - it’s about constant, iterative improvement, in your product, your people, and your process.

Retrospectives can take many forms, but at their core, it’s a meeting intended to root out the biggest issue with how you’re working together and make iterative, measurable changes to resolve that issue.

How we run retrospectives

At Influitive, we have two levels of retrospectives:

• Every squad (generally 2-4 developers, a PM, a designer, and QA) conducts a retrospective on how their team is doing at least every 2 weeks.
• Our “production team” (developers, PM, QA, and design as a whole) conduct a team-wide retrospective every month.

Both meetings run pretty similarly, and we’ve developed a structure that works pretty well for us. Your mileage may vary, of course.

1. We start off the meeting reviewing whatever change we agreed to make in the last meeting. We take a vote on whether we should continue doing what we agreed to last time by taking a Fist of Five.

2. Every person in the meeting writes down 3 things on post-it notes that they feel about how the team has been working since the last retrospective. They indicate whether these items are something they’re happy, sad, or confused about.

3. We stick the post-it notes up on a whiteboard and attempt to group them together. We’ll choose whatever item seems to be the most pressing for the team (usually this is the thing with the most Post-it notes, although we make a judgement call).

4. We have open discussion on small, iterative steps we can take to resolve this problem. Once we have a proposal, we vote on it (again, using Fist of Fives).

5. Once we have agreement, we stop. It’s very tempting to try and talk about multiple things, particularly if it’s been really bugging someone. It’s usually a mistake. Think of your process as a system to be tweaked - you can’t really measure how well a particular change worked when you’re making 5 changes at the same time.

That’s really all there is to it. By constantly iterating on your process as well as your product, I think you’ll find your team is able to work far more effectively together.