The Fractal Nature of the Revelry Software Development Process

“There’s a fractal nature to the Revelry software development process. Whenever I advise someone who is stuck using our process, I see this psychedelic, colorful background of like a Mandelbrot set or a video zooming into molecules and panning out to deep space in my head.

“Because no matter how far you zoom in or zoom out, the process is always the exact same pattern over and over again, as each problem is solved. We just need to be reminded: The next step is always simpler than we’re making it out to be.”

– Thomas Knoll, former Revelry COO

At Revelry, we care a lot about what we call “the process.” Put simply, the Revelry Process is our Lean-Agile approach to building software. It can be distilled into about seven steps, including:

1. Understand the problem we’re trying to solve (including context).
2. Define what it looks like when this problem is solved (writing user stories).
3. Decide what to do next (approvals and prioritization).
4. Talk about how hard it will be to solve this problem (Planning Poker).
5. Build the solution to the problem (implementation).
6. Make sure it won’t break anything (peer review and QA).
7. Make sure the thing you made does what it’s supposed to do (UAT).

Once the code does what it needs to do, we ship it and celebrate.

Then we start all over again with a new problem.

Beyond Code

Taken at face value, these steps seem pretty straightforward. After all, we didn’t invent Lean-Agile (although we’d certainly argue we’ve improved it). We follow widely-adopted practices for getting a user story through a few sprints in the software development process. And we constantly iterate our specific approach to make it better at shipping great code.

But the thing is, we use our process for more than just shipping code. Revelry’s leadership team uses the process to set quarterly and annual performance goals, and our Director of People Operations uses the process to improve and adjust things like our benefits program. Our former COO Thomas Knoll described this as “the fractal nature of the Revelry Process”…meaning that you can zoom in or out on the company and the process happening on each level will always be the same.

Relying on the same process in how we manage our company and support our partner projects is simple, but not easy. After years of success and hard lessons, we’ve found there are fundamental principles to live by when using the Revelry process at both macro and micro levels.

Make the Process Work at All Levels

Don’t break the pattern: Never skip steps. It’s tempting to skip ahead to the presumed answer or solution, but you have to go through each step. Did you tell someone what you were going to do, or were you in a cave for three days? Did anyone check to make sure your solution wouldn’t conflict with something else, or did we push it to live in a rush, thinking we would solve the problems later? Because now we’ve ruined eight other things and created a whole mess of issues potentially worse than the one we were dealing with before. This can happen when we skip a step to get something done as fast as possible.

If you disagree on a solution, make sure you agree on the problem first. As a company devoted to developing products we care about, our first instinct can be to dive right into building the solution – whether it be fixing a bug, kicking off a marketing campaign, deciding on some brand colors, or updating our payroll policies.

But when someone gets stuck building something, 90% of the time, it’s because the team has not clearly defined the problem. Suddenly, five different people with different areas of expertise start sharing a whole bunch of advice on things to try next. Frustration and stress levels run high until what was a minor issue starts to threaten coworker relationships and slow progress.

As soon as you realize you might not be on the same page, stop the discussion. Go back to step one. Do we fully understand the problem we’re trying to solve? Do we agree on it? Did we describe what it means to succeed? There might be another way to address the challenge / need, but we won’t know until we define the key problem.

Know when to zoom out and when to zoom in. When building a solution, you often find it’s more complicated than you thought it would be. When is inevitably happens, be ready to zoom in. For example, maybe you realize you need to kick off five sub-processes to solve the bigger problem. Getting more specific: In planning a party, your smaller processes could be: setting a budget, creating invitations, making a guest list, etc. Each of these processes starts at the beginning and doesn’t assume anything. Remember to ask: What problem are we trying to solve? Do we agree on it?

And if a lively discussion begins about the cocktail menu, zoom out and focus on the goal of the party that was established at the beginning. Do the menu goals align with that? And so on. Because no matter how far you zoom in or out, the process is the same pattern. The next step is always more straightforward than we’re making it out to be.

Keep asking why until the solution comes into focus. When something breaks, it’s easy to try to place blame, but here’s the thing: Every time we find another bug, it’s an opportunity to understand the problem more deeply. Use your bugs as fuel for making your solution better. Don’t just fix them and ignore the cause.

Let’s say you would like a driver to receive push notifications with delivery information on his phone. But then someone reports a bug: The display is difficult to see at night, so we need to increase the contrast of the dashboard. You could simply fix that bug, but this bug also tells you that you didn’t fully understand the context of the problem you are trying to solve. When you take the time to learn more about the driver experience, you might discover he is away from cell service half the time, so he can’t even view the dashboard. This would / should change the entire way you build your solution (even though the immediate need doesn’t change).

Keep Your Eye on the Outcome

When you are committed to a specific solution, you may be ignoring the real problem. Use the process to find an outcome, not a solution.

Knoll explained, “What often happens in software development is that a company hands a technical team an RFP and tells them to go build it. The tech team follows the instructions exactly. Then, they secretly giggle while giving you the thing they knew would never work, but you said you want.

“But that’s not what we strive to do here. What’s different about Revelry is that we care more about understanding those problems before trying to solve them, to ensure our software creates the right outcome.”

Every time we take a moment to slow down, check-in, and ensure we are all adhering to the process – from the top to even the most minor level – we take a step closer to a solution that works. And so the fractal continues: Planning parties, shipping software, growing companies, and building products that matter.