Revelry Labs

Unleashing Human Potential with Technology

A colorful illustration of many black R letters in a spiral with purple, cyan and yellow background in a fractal design. Revelry blog

The fractal nature of the Revelry 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 & 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, Revelry COO

Here at Revelry, we care about what we call “the process” a lot. Put simply; the Revelry Process is our lean-agile approach to building software. Thomas Knoll, Revelry COO, has distilled his explanation of the process to seven steps.

  1. Understand the problem that 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 & prioritization)
  4. Talk about how hard it will be to solve this problem (poker)
  5. Build the solution to the problem (implementation)
  6. Make sure it won’t break anything (peer review & 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. 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. Our leadership team uses the process to set Q1 growth goals, and our director of operations uses the process to plan a happy hour menu. Revelry COO Thomas Knoll describes this as “the fractal nature of the Revelry Process,” that you can zoom in or out on the company, and the process happening on each level will always be the same.

Using the same process through our company and partner projects is simple but not easy. After years of success and hard lessons, we have found that there are fundamental principles to live by when using the Revelry process at the macro & micro levels.

Make the process work at all levels

Don’t break the pattern: never skip steps. It’s tempting to skip ahead to completion, but you must 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 would 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 nest of situations worse than we were dealing with before. That 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 building products we care about, our first instinct can be to dive right into building the solution. That could 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 many areas of expertise start sharing a whole bunch of advice on things you should try next. Everyone starts getting frustrated and increasing stress levels until what was a minor issue starts to threaten coworker relationships & stop progress.

As soon as you realize that you might not be on the same page, stop the discussion. Go back to step one. Do we fully understand the problem that we’re trying to solve? Do we agree on it? Did we describe what it means to succeed? There might be another way to solve it, 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 that happens, be ready to zoom in. Maybe you realize that you need to kick off five sub-processes to solve the bigger problem. 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 you trying to solve? Do we agree on it?

And if a lively discussion begins about the cocktail menu, remember to zoom out & focus on the goals of the party we established. 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 on their phone with delivery information. But then someone reports a bug that the display is difficult to see at night, so we need to increase the contrast of the dashboard. You could fix that bug.

But this bug also tells you that you did not fully understand the context of the problem you are trying to solve. When you take the time to learn more about the driver’s experience, you might discover that they are away from cell service half the time, so they can’t even view the dashboard. So that would change the entire way you build your solution even though the 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.

Thomas Knoll explains, “What happens typically 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 wanted it.

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 following 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.