I Make Tools: A Scrum Master's Journey with AI | Fred Deichler

My spidey senses were tingling.

That’s the feeling I keep coming back to. The thing Scrum Masters do without naming it. We walk into a room and feel when something’s off. Notice the silence after someone speaks. Clock the eye rolls, the checked-out body language, the way a standup drags three minutes longer than it should.

Spidey senses. Pattern recognition. Intuition honed by years of watching teams.

But you can’t put a spidey sense on a slide deck.

The Gap Between Sensing and Seeing

I’ve been building a tool for a couple of years now. Started as a bridge between two systems that didn’t talk - Request Tracker and Jira. Every week I was manually filling that gap with spreadsheets and copy-paste. Tedious. Error-prone. Invisible to everyone except me.

Somewhere along the way, the tool became something else.

The DevOps team I work with looked like they were failing their roadmap. Month after month, planned work slipped. From the outside? A delivery problem.

It wasn’t.

Interrupt work comes in all sorts of flavors. Incidents. Access requests. Helping Scrum teams troubleshoot. Releases. Certificate renewals. All competing with roadmap commitments. All unmeasured.

A team’s doing the best they can given what’s going on. I say that a lot:

They’re operating perfectly for the system they’re in.

The problem is nobody could see the system.

I could sense it. My spidey senses were screaming. But I couldn’t point at it in a meeting.

So I built something that could. That RT-Jira bridge? Became the foundation for something bigger - a way to visualize all the interrupt work eating the team alive.

Now when a VP makes a decision to react - to drop everything and pivot - there’s data about the actual impact. The hidden tax becomes visible. The sensed becomes seen.

Dave Westgarth and the Delivery Question

I’ve been following Dave Westgarth for years and consider him a friend. He’s Head of Delivery at UnifEye, and he keeps asking a question that makes me uncomfortable: Does delivery matter to you as a Scrum Master?

Not facilitation. Not coaching. Delivery.

Uncomfortable because the orthodox answer is that Scrum Masters don’t own delivery. The team owns delivery. Product owns delivery. We’re coaches. Facilitators. Servant leaders. We hold space. Ask questions. We don’t... ship things.

But Westgarth pushes on this. He argues the core competencies - facilitation, coaching, team empowerment - aren’t just about enabling teams. They’re about enabling delivery. And if you can’t see what’s blocking delivery, how can you enable it?

The tools I’m building aren’t about me delivering software. They’re about seeing clearly enough to help others deliver.

Telling Stories to Tell Stories

Here’s what building tools feels like now.

I'm not a developer. My degree's in business. Two decades ago I was a Geek Squad agent - Agent 425, one of the originals in Seattle. I could troubleshoot hardware and explain things to confused customers. Not the same as writing code.

Or was it?

Humans have always been storytellers. It’s how we make sense of things. Before writing, we told stories around fires. After writing, on pages and screens.

Now I tell stories to an AI, and the AI helps me discover stories to tell about the team. And to them.

I describe what I want in plain language. Sometimes voice - just ramble ideas to Copilot until something coherent emerges. Then I ask it to write a PRD. Hand that PRD to Cursor: here’s a feature, analyze our codebase, create stories, implement. Half a day later, something works.

That’s a gross oversimplification, honestly. There’s more to it. I should probably write about the messy middle in a future article.

But the arc is real. Storytelling all the way down. I tell a story about what I need. The AI translates that into a story the computer understands. The computer produces something that helps me tell a clearer story to stakeholders.

Ahhhh, the circle of life.

Prompt vs. Program

There’s a distinction I keep returning to.

Solving a problem one time? Generative AI is a great tool. Ask, answer, move on.

Looking for a repeatable process - consistent data, reliable output - you want a program. Something that acts the same way each time.

The problem with prompts: run the same one through the same AI multiple times, you’ll get different answers. Models are probabilistic. They’re guessing, elegantly.

With structured data and a program, you can measure things consistently. Compare weeks and months. Finally see patterns.

That’s what I’m after. Not clever prompts. Instruments. Tools that reveal what’s really happening, repeatedly, reliably.

And here’s the thing I want y’all to hear: you can do this too. AI makes building these tools accessible in a way it never was before. Not rocket science. Modern software development, and the barrier to entry just dropped through the floor.

The Question I Keep Getting

Here’s where I get stuck.

When I explain what I build, people look at me like I’ve crossed a line. But describe it differently - “I made a Jira dashboard” or “I built an Excel workflow” - suddenly it’s normal.

I don’t know if what I’m doing is fundamentally different from what Scrum Masters have always done with spreadsheets and reports, or if the tools have just gotten more powerful.

Maybe it’s the same instinct. The Scrum Master who built elaborate pivot tables to track velocity. Created a Confluence macro to automate sprint reports. Figured out how to pull data from three systems into a single view.

We’ve always been building things. The capability just caught up.

What’s different now is the ceiling. A spreadsheet can only take you so far. A Jira dashboard has limits. But a custom tool that bridges RT and Jira, visualizes interrupt work against roadmap commitments, gives VPs the data they need to understand the true cost of context switching?

Different order of magnitude. Same instinct. New ceiling.

Making Tangible the Intangible

My spidey senses were tingling.

That line keeps coming back because it describes a before and after.

Before: intuition, pattern recognition, the gut feeling something was off but no way to prove it.

After: a chart. A number. A trend line making tangible the intangible.

But here’s the wrinkle I keep thinking about: the observer effect.

In physics, observing a system changes the system. Measure an electron’s position and you alter its momentum. The act of looking affects what you’re looking at.

Works that way with teams too. We’ve been doing this for years in retrospectives - the moment you name a pattern, the pattern starts shifting.

Start measuring interrupt work and people change behavior around it. Put a number on context switching and suddenly it becomes something people negotiate about. Make the invisible visible and the invisible stops being what it was when nobody could see it.

I’m not saying measurement is better than sensing. Some things that matter can’t be measured. And some things, once measured, stop being what they were before we looked.

But that’s the trade-off. Keep sensing the friction with no leverage in stakeholder conversations. Or bring data to the table - that third person in a conversation without an ulterior motive. Thanks for that one, Angela Johnson.

What We Can Finally See

There’s a category of organizational friction that lives in the gap. Things we could sense but couldn’t point at. Work invisible to leadership even though it was drowning the team.

Those things can finally be seen now. By people like me. Scrum Masters who build their own instruments.

I’m not alone in this. My colleague Dwayne Mullins is building dashboards that rival commercial software - finding the harmony between agile coaching and data-driven decisions. Same instinct. Same tools. Different expression.

My spidey senses are still tingling. But now I have something to show for it.

I still don’t know what to call us. Maybe the name doesn’t matter. Maybe it’s enough to say: I make tools.

Learn More from Triforce Agility

Free Resources:

🎓 AI Builder Foundation Course - Learn to build AI-powered tools for your agile practice
📊 Monte Carlo Simulator - Probabilistic forecasting made simple

Connect:

🎙️ Speaking & Workshops - Bring these ideas to your organization