Debugging development cycles with Lightning Decision Jam

Shavin Peiries

Mar 22, 2024 — 8 min read

It was the 12th day of our development cycle for the new “Leads” feature, and my tech lead looked like he wanted me dead.

The team worked long hours, fueled by lattes and the pressure to deliver. Despite our best efforts, our Linear board was growing more than it was shrinking, and progress felt slow.

We budgeted seven days to build this “mini-product” in our core application, but that was too optimistic.

Integrating the new feature into our existing architecture was like fitting a square peg in a round hole; every step took twice as long.

As the days passed and the stress mounted, I could see it taking a toll on the team: tempers were fraying, discussions were heating up, and our camaraderie started to crack.

By the end of the 14th day, everyone was drained and demoralized when we finally shipped the feature.

We put our hearts into this project, knowing how much it mattered for the product to be feature-complete. But we were left questioning ourselves and wondering what had gone wrong instead of celebrating a job well done.

How did we misjudge the scope so badly? What could we have done differently to avoid this death march?

As I heard team members propose solutions like hiring more UI resources or lengthening our development cycles, I realized we needed to step back and shake our troubles out of the tree.

What critical mistakes led us astray, and what could we learn from them to ship quality work on time?

I was determined to find out.

Business as usual post mortems

As I reflected on our challenges, I realized that our standard post-mortem would not provide the answers we needed.

The issues were too tangled, emotions were too raw, and perspectives were too varied.

We needed a way to systematically untangle the knots, one by one, and get everyone on the same page.

Our usual discussions likely led to circular arguments, with no precise alignment or concrete steps forward.

We might have fixed some superficial symptoms but not the deeper root causes. To solve our problems, we needed a fresh approach to air out our dirty development laundry.

That’s when I remembered the Lightning Decision Jam (LDJ) workshop I had run for executives. It had worked wonders for solving thorny strategic problems.

With a few tweaks, I thought it could be the perfect tool to debug our development process.

Lightning decision jam for developers

I gathered the team and posed our core question: “How might we refine our dev process to ship high-quality features within seven days and without exceeding an 8-hour workday.”

Together but alone, each team member silently brainstormed on sticky notes on Miro, surfacing raw and honest perspectives that might not have come out in a group discussion. As we shared our ideas one by one, patterns started to emerge.

“I feel like we didn’t make enough tradeoffs to fit work into a fixed seven-day cycle,” read one note from our usually quiet senior engineer.

“Working on tickets that still need shaping (a lot of unknowns),” said another from a developer who rarely got the chance to give his input because he was working remotely.

The LDJ’s brainstorming gave everyone an equal voice, surfacing insights from all team levels that might have been drowned out in a traditional discussion.

As we grouped similar ideas into themes, it became clear that our issues spanned the gamut from technical to organizational.

But by voting on the most critical challenges, we were able to zero in on the fundamental problems quickly:

trying to tackle too much in a 7-day cycle,
prioritizing the wrong tickets,
tickets not being broken down enough to track progress,
and testing being left until the last minute, causing delays.

In under 30 minutes, the LDJ helped us cut through the noise and identify the root causes that had been hiding in plain sight.

It also gave us a prioritized list of concrete actions to address each issue.

There were no more circular discussions or band-aid solutions. We finally had a clear path forward to debug our development process from the inside out.

Reframing problems as opportunities

One of the most powerful aspects of the LDJ workshop is how it helped us reframe problems into opportunities.

Instead of dwelling on what was wrong, we focused on what could be improved.

The key was to convert our problem statements into “How Might We” (HMW) questions.

This simple linguistic tactic opened creative possibilities and encouraged the team to think about solutions.

It was like trading in our “problem glasses” for a shiny new pair of “opportunity goggles.”

For example:

“Trying to tackle too much in a 7-day cycle” became “HMW ensure that we’re betting on work that can be accomplished in 7 days?”
“Prioritizing the wrong tickets” transformed into “HMW sequence our work so we worked on scopes in the right order?”
“Tickets not being broken down enough to track progress” shifted to “HMW break down tickets so we can see progress?”

By reframing our challenges as HMW questions, we primed our team to generate targeted, actionable solutions in the next process step.

Solution storming

With our problems reframed as HMW questions, it was time to harness our team’s creativity to generate solutions.

The key here was to brainstorm “together but alone.”

Here’s how it worked:

We displayed the HMW questions we generated and gave each team member 5-10 minutes to silently brainstorm solutions individually. This ensured everyone’s ideas were heard and prevented groupthink.
We went around the room and had each person share their ideas individually. We encouraged wild ideas and built on each other’s suggestions.
Once all the ideas were out, we gave each team member three dot votes to vote on the solutions they thought would have the most impact. This helped us democratically prioritize ideas and build alignment.
We discussed the top-voted ideas as a group and decided which ones to move forward with.

For example, for the HMW question “HMW test well and early?”, our top-voted solution was: “In the first 2-3 days of the cycle, build a low-fidelity frontend prototype with backend functionality. Focus on getting the system working first, then beautify it later.”

(Adios to those last-minute bugs!)

The LDJ process boosted our creativity and buy-in by separating idea generation from evaluation.

In an hour, we went from tangled problems to prioritized solutions.

Connecting solutions to root causes

The LDJ workshop’s power lies in connecting the dots between problems and solutions.

We explicitly tied each action to a root issue and ensured our changes were targeted and impactful.

We weren’t just making adjustments for the sake of it - every decision was purposefully designed to untangle a specific knot in our development process.

For instance, to address the problem of “trying to tackle too much in a 7-day cycle,” we implemented a “smell test” with lead engineers.

If a pitch seemed too much work to fit into a 7-day cycle, we pushed our cool-down period for the shaper to adjust.

This helped us avoid overcommitting and ensured we could deliver the essential functionality on time.

Similarly, building a low-fidelity prototype in the first 2-3 days was chosen to tackle the issue of “testing being left until the last minute causing delays.”

By testing core functionality and interactions early, we could reduce last-minute surprises and ensure a smoother path to completion.

The LDJ gave us a laundry list of fixes and a plan of attack to do our jobs effectively.

Each solution was a precision strike on a specific pain point rather than a band-aid or best guess.

This targeted approach was vital to debugging our development process effectively.

Seeing immediate results

Our LDJ’s impact was visible immediately in our next development cycle.

We made significant strides in just one cycle by implementing our targeted solutions.

Our CTO noted the difference, saying:

This marked an improvement from our previous cycle, where we were still frantically integrating pieces at the last minute.

The smell test helped us scope our work more realistically, so we weren’t betting on anything that wasn’t shaped enough or seemed too smelly.

The low-fi prototype allowed us to catch and fix interaction bugs early rather than getting blindsided by them later.

However, perhaps the most significant change was in the team’s morale.

Instead of feeling drained and demoralized, we were energized by our progress. We could see the direct impact of our process changes, and it motivated us to keep refining.

Even the tech lead, who had previously looked ready to murder me, was celebrating the release of the latest cycle:

It was a complete 180 from the dark days of our death march. We had gone from stressed and demoralized to cheering each other on.

Of course, one good cycle didn’t mean all our problems were solved forever. But it gave us a solid foundation to build on and the confidence that our new approach was working.

We had proof that systematically debugging our process allowed us to ship better software within the allocated time and have fun doing it.

No more near-death experiences required.

Running your LDJ

Sold on the power of LDJs for dev teams? Here’s a step-by-step guide to running your own:

Gather your team and present the core question: “How might we improve our development process to ship high-quality features on time and sustainably?”
Have each team member silently brainstorm problems on sticky notes for 5-10 minutes.
Go around and share problems one by one, grouping similar ones.
Vote on the top 3-5 problems to focus on.
Reframe problems as “How Might We” questions.
Brainstorm solutions individually, then share and vote on the top ideas.
Assign owners and next steps for each solution.
Review progress at your next retrospective and iterate as needed.

Tailoring the prompts to your team’s specific context and challenges is vital. Don’t be afraid to experiment and adapt the format to fit your needs.

To make it even easier to get started, you can use an existing Miro template from AJ&Smart for your LDJ.

Duplicate the board, invite your team, and start debugging your development process today.

Some pro tips I wish I had incorporated

Pro tip 1: Create a map of your development process beforehand. This will allow you to visualize where each problem or pain point occurs, giving you a clearer picture of your challenges.
- You can create the map before the LDJ and confirm it with the team during the session.
- Once you’ve identified and reframed the challenges, place each HMW note on the map to visualize where the issues are concentrated.
- If you notice a cluster of problems in one area, focus your brainstorming efforts there. Concentrating on those bottlenecks can help open up the rest of your development workflow.
Pro tip 2: Besides voting on solutions based on impact, consider including low-effort ideas that team members feel strongly about. This can help you capture quick wins and build momentum.

With some practice, you’ll debug your development process like a pro.

But don’t just take my word for it - put it into action!

Gather your team and run your first LDJ this week.

Experience the power of systematic problem-solving firsthand and see the immediate impact on your team’s productivity and morale.

Your future self (and your team) will thank you for taking this crucial step towards smoother, more successful development cycles.

Happy shipping!

Referenced