It started with a big list of little things.

"We had a backlog of items we wanted to get done," said Luke Freiler, Centercode's CEO and lead product designer. "But since we tend to develop by focusing on key areas and features of the platform, those small things never fit nicely into the process."

Ah, the dusty backlog—a common pain point for many agile SAAS platforms. With limited development resources and a focus (rightfully) on getting the high-priority items out of the door—the new features, critical bug fixes, VIP customer requests—the backlog can get very long without anyone noticing.

But the Centercode team, many of whom use the platform daily, did notice.

"If you use the platform every day, you get used to working around the idiosyncrasies," said Matt, who works with users as a solutions consultant. "When you're running a project every three months, however, it takes way more effort not to stumble over the usability bumps."

A solution to these usability bumps—a.k.a. DevJam—began to take shape while Luke was reading through Figma's release notes.

Figma, a design web app, does Little Big Updates, a big release of small, quality-of-life updates. Maybe only a third of the updates apply to any one user. But as an avid Figma user and a usability guy, it brought Luke a lot of joy to see those improvements throughout the tool. He wanted Centercode's users to experience the same delight he had as a Figma user. So he adopted the idea—but with a unique Centercode twist.

"Most of us are gamers," he said. "So of course, we had to gamify it."

Gamifying rapid iteration in software development

When Luke brought the idea of gamifying a small-improvements release to the product team, they latched onto it immediately, adding and tweaking the concept with parameters, points, penalties, and prizes. And so, Centercode's very first DevJam was born.

They'd assign each improvement a certain number of points, based on do-ability and impact to the user experience. They would give the developers three working days (capped at 7 hours a day) to smash through as many items as they could, racking up their individual points once they'd proved their implementation worked as intended.

They'd award you auxiliary points for aiding your competitors (we're a team, after all), but they'd deduct points if you couldn't finish all the tasks you assigned yourself. And, in addition to a generous three-day coffee stipend, the three developers with the most accumulated points would win cash prizes.

"It's very, very rare I have an idea that everybody immediately likes," Luke said. "Pretty much anything that creates fun for someone creates work for someone else, after all. This was different. All our key players loved it, and we got everyone on board from the get-go."

Once the game's scaffolding had been laid out, the product team invited the rest of the company to build out the backlog with even more ideas and improvements. Engineering, QA, Support, Services, and even Sales and Marketing contributed to the list. By the start of the competition, there were over 100 items the developers could jockey for—everything from UI polish and vocabulary refinement to code cleanup behind the scenes.

"I thought we would be lucky to hit 42 items—and that number sounded crazy to me because these weren't bug fixes, they were improvements. Even 30 improvements would've been an incredible accomplishment."

It goes without saying that the results—133 improvements ready for QA in just 3 days—surpassed everyone's expectations.

Inside the 3 magical days of DevJam

For nine developers (and one intrepid UX writer 👋🏾) to churn out that many improvements in such a short amount of time, the entire team could've easily turned into a hoard of stressed out, burnt out zombies. But we didn't. In fact, it largely had the opposite effect: knocking out small wins was a refreshing break from our standard mode of operation.

"It was crunchy, but it was also exciting," said Dustin, one of the competing devs. "I was in developer "beast" mode. Having few outside distractions really helped get a lot done."

"Once it got started, there was a lot of momentum on the engineering side," Luke recalled. "I saw more energy and heard more enthusiasm over Zoom than I had in a long time. That level of engagement is harder to come by in a post-2020 remote work environment."

For me, watching individual personalities come out was a highlight of the competition. Everyone had their own approach for choosing and working through improvements—some driven by game strategy, others by wheelhouse, others by the improvements they themselves most wanted to see.

"I took a minute to read the question, and if I could think out a solution in my head fairly quickly, then I’d pick it up," said Frank, who earned the most points during DevJam.

Eddie, who specializes in front-end development, put his focus on big customer wins.

"After we updated our navigation menu, moving the cursor through the nested options got a bit finicky. I knew it frustrated our customers, and I wanted the experience to feel better," he said. "It was hard to dedicate a window of time to improve it due to its complexity. When DevJam happened, it gave me the space to get it feeling and performing exactly the way I wanted it to."

While he didn't end up earning the most points, Eddie's improvement did win the vote for favorite fix amongst Centercode customers.

But the devs weren't the only ones watching the action; the entire company followed along as the string of improvements developed. No pun intended. 

"We were absolutely ecstatic," said Matt. "Probably even more than the devs, because we got all the benefits with way less effort."

The (mostly) pros and cons

Obviously, there are pros and cons to rapid-fire, continuous development. DevJam wasn't perfect. But it was, according to the team, almost purely pros. It made our customers happy. It made training new users easier. It gave the product team room to better define meatier future projects, and it smoothed out some of the rough edges left behind by the breakneck speed of agile development.

"What I like about DevJam is that it's effectively a polish build," said Ben, our QA manager. "It's easy to keep building and building and leave things behind. Taking a step back to shine up those small, more cosmetic issues is important for the customer experience."

From my perspective as a DevJam competitor, but also as a seasoned Centercoder, it reinforced our personality and values. Play and camaraderie are part of our ethos. Events like DevJam remind us how fun challenges can be, and how rewarding it is to make technology better, starting with our own tool.

"It could've backfired," Luke said. "People could have played it in a crazy crunchy way that left everyone bitter and exhausted. Instead, they were collaborative, they were passionate, they had fun. It was designed to be a game, and it stayed a game."

Plans for more DevJams (with smaller scopes and shorter playtimes) are already in the works. Stay tuned.