Hardware Meets Agile: a real-world approach to Scrum implementation

Have you ever tried fitting a square peg into a round hole? That’s what implementing Scrum for hardware engineering teams often sounds like.

We recently faced this exact challenge: helping two teams of brilliant mechanical engineers and robotics specialists embrace Agile practices without crushing their creativity or disrupting their workflow.

In this post, I’ll share how we transformed a pen-and-paper tracking system into a streamlined Agile workflow for two different cutting-edge robotics companies in California who were facing very similar challenges. You’ll discover:

• Why we work to migrate from Jira in favor of more intuitive solutions
• The step-by-step approach we used to introduce Agile concepts to Agile novices
• How we created a custom workflow that respected the unique needs of hardware development
• Practical tactics for prioritizing work when everything seems urgent

Whether you’re a Scrum Master struggling to adapt Agile for hardware teams or an engineering leader looking for a more effective way to organize your work, our experience offers valuable lessons in flexibility, pragmatism, and meeting teams where they are.

These weren’t just any teams; these were brilliant groups of engineers at cutting-edge tech companies in California, building AI-powered robots.

The catch? They were tracking their work in an old school way - pen, paper, and sheer memory power.

Oh, and Jira was technically there… gathering dust, as the teams were not really engaged with the platform (and we know why, don’t we? Atlassian, never gives up on disappointing us).

The Initial Challenge: where do we even start?

When we arrived, these were the three main obstacles we found:

• They were not familiar with Scrum. One of the teams had zero exposure to agile practices. Daily stand-ups? Backlogs? Sprint planning? Nada. While the other team had stand-ups, that’s it.
• Task tracking was not going very well. Everything was either scribbled down in notebooks, stored in someone’s brain, or lost in the abyss of Jira, which hadn’t been updated since who-knows-when.
• No regular meetings among the teams. There were no structured check-ins or processes to ensure alignment. People were just figuring things out as they went.

Notion to the Rescue

Both companies initially struggled heavily with Jira’s complicated UX, leading to low engagement and inefficient task tracking.

One company fully transitioned to Notion, while the other opted for a hybrid solution - software development tasks moved to GitHub Projects, and hardware production tasks migrated entirely to Notion.

Why Notion? Because Notion is the cozy coffee shop where your tasks hang out, while Jira feels like trying to brew espresso inside a spaceship cockpit.

For the hardware teams, Notion allowed us to:

• Create customized pipelines and production calendars.
• Clearly visualize whether machines being produced were already sold, aligning priorities and deadlines.
• Automate task creation, automatically generating all production tasks in Notion whenever a new machine serial number is created.
• Develop a custom production calendar displaying machine statuses, deadlines, and priorities transparently.
• Build a customized board that actually made sense for these teams.
• Keep things simple and inviting, so they’d feel encouraged to use it instead of afraid to break something.
• Ensure visibility without overwhelming them - because nobody wants to feel like they need a PhD just to update their task list.

Organizing things with a board that makes sense

At first glance, our workflow might look like Kanban, but we’re not calling it that.

Why? Because while Kanban is great for continuous flow, we’re still aligning with Scrum principles.

We’re laying the groundwork for structured iterations, backlog management, and prioritization - things that go beyond pure Kanban’s “pull system” approach. In other words, we’re Scrum-first, but with flexibility built in.

We tailored a custom workflow in Notion to fit the teams’ needs:

• Needs Refinement: Ideas and tasks that weren’t quite ready yet.
• Next Up: Prioritized tasks, ready to go.
• In Progress: Actively being worked on.
• In Review: Engineers checking each other’s work before it moves forward.
• Completed: Done and dusted.
• On Hold: Because hardware isn’t software - sometimes things have to wait (supplies, approvals, reality).

This structure gave them the flexibility they needed without overwhelming them with Scrum purism.

Priorities matter, and not everything is on fire (just some things)

To help them focus, we introduced priority levels:

• Critical: The sky is falling. Do this NOW.
• High: This needs to happen soon, but nobody’s panicking (yet).
• Medium: Important but not urgent - won’t cause a meltdown if delayed.
• Low: Nice to have.

Now, the teams always know what to tackle first, as their backlogs have clear priorities,

One company further enhanced their workflow with automated pipelines.

Every time a new machine serial number is created, automations trigger the creation of all related production tasks in Notion.

This has dramatically increased efficiency and transparency.

What’s Next?

Now that the teams are comfortable with tracking work and prioritizing effectively, the next step would be introducing sprints to one of the teams, as the other is using sprints from day 1.

The big question is ‘Should we?’

Since hardware development doesn’t always fit neatly into software cycles, we’re taking our time to figure out the right cadence - or actually if we’re going to introduce sprints at all to this team.

Again, we’re adapting Scrum to make these teams work smarter, not harder. If it makes sense eventually, Sprints will be introduced to the flow. If it doesn’t, well, “If it ain’t broke, don’t fix it.”

Making agile work for Engineers, not against them

Scrum for a hardware team isn’t about forcing them into a rigid framework - it’s about giving them the right tools and flexibility to stay organized and efficient.

At Avanti Studio, we believe in adapting Scrum to the team, not the other way around.

Focusing on visibility, prioritization, and a friendly toolset, we turned two somewhat complex environments into clarity without scaring anyone away. And that’s a win in our book.

But we’d love to hear from you! If you’ve worked with hardware teams before, what sprint length has worked best for you? Two weeks? A month? Something custom? Let us know your thoughts!