Using Jira for Hardware Development: What You Need to Know

It’s no secret: Jira isn’t just for software development teams anymore. When Jira Software launched in 2002, it was an issue tracking system targeted at software teams. But from there, Jira has evolved into a suite of agile work management solutions with a broader audience—one that explicitly includes non-software teams.

Combine that with the reality that hardware product development is becoming intertwined with software development, and it’s not surprising if your engineering team is thinking about using Jira (or using it already). It’s agile, it works great for the software, and now it’s for other teams, too. Might seem natural to at least look into it, right?

Well, just to be clear, this article isn’t going to tell you if your team should or should not use Jira. There’s no one-size-fits-all answer to that question. Instead, this article will help you answer questions like:

• Why would a hardware team start using Jira, or start looking into it?
• How can the values of agile software development be applied to mechanical design workflows?
• What are Jira’s drawbacks for teams that build physical products?
• What traits would the ideal “Jira for hardware” tool need to have?

So whether you specifically want to be more agile in your product design process or you simply want to find better ways for your team to work, here’s what you need to know about using Jira for hardware development.

‍

More and More Hardware Product Development Now Involves Software, Too

In April 2021, The Japan Times reported on Toyota Motor Corp’s plans to hire a greater proportion of software engineers—going up from 20% of all technical hires to somewhere between 40% and 50% for the following spring. Although that’s only one small fact, it represents a very real shift. One that extends beyond just the automotive industry.

Nowadays, developing a hardware product often includes some level of software development, too. And this growing need to work closely with software teams is one of the things putting Jira on the radar for some hardware teams. But different teams start considering Jira for different reasons. 

Maybe the software team’s success with Jira has the hardware team wanting to get in on the action. Maybe adopting Jira seems like a way for mechanical teams to handle the increasing need for more collaboration with software developers. Maybe there’s an internal push at companies with both hardware and software teams for everyone to use the same tools wherever possible. Maybe it’s because the hardware team is taking (or wants to take) a more agile approach to development. Maybe it’s some combination of all of the above, or maybe it’s some other reason entirely.

But even for hardware products that don’t necessarily involve any software development, there are plenty of reasons why mechanical engineering teams are increasingly starting to seek out better tools for digital collaboration. The software world basically has a 20-year headstart when it comes to using agile methods and cloud-based tools to collaborate and manage work. It’s natural that some hardware teams end up looking at tools like Jira when they realize the status quo isn’t cutting it anymore. It feels like it might be a logical template to start from.

After all, Jira is pretty explicit about supporting agile methodologies. So with Jira’s expanded target audience for their products, and the way agile practices keep spreading to more fields and industries, hardware teams are bound to wonder if Jira could be the right fit for them. If business teams are adopting agile techniques and using Jira for non-software projects, why can’t an engineering team do the same?

‍

‍

But Agile Tools Built for Software Teams Have Limitations for Mechanical Teams

Of course, Jira isn’t the only tool out there that’s meant to facilitate agile methods. When the Manifesto for Agile Software Development was created in 2001, it laid down four values written as comparative statements (we value X over Y, etc). Those values defined the common threads that existed across multiple frameworks that were emerging at the time, out of a need for alternatives to the waterfall methods that software engineering had borrowed from physical engineering. One of those values prioritizes “individuals and interactions over processes and tools” so the agile philosophy has always been tool-agnostic, and even process-agnostic. 

‍

‍

Taking an agile approach doesn’t refer to a specific or single set of techniques. It simply means working in a way that’s aligned with the values and principles of agile. The Agile Alliance, a non-profit formed by some of the Manifesto’s authors, describes agile as “a mindset” that can be applied to activities beyond software development. Ultimately it’s an umbrella term and it covers everything from agile frameworks like Scrum or Extreme Programming (XP) to common agile practices like sprints or stand-ups to agile-focused tools like Jira.

What are the differences between agile for software and agile for hardware development?

Can you use agile for hardware development? Yes, you can—but there are caveats. Agile hardware development really just means applying an agile mindset to the process of building physical products, which is something any team can theoretically do. Plus, agile is used successfully by industry heavy-hitters like John Deere, Saab, and GE. But the methods and tools created for agile software development or agile project management don’t map directly to the needs of hardware teams. 

In this article, product design expert David Ullman describes 13 distinct challenges of using Scrum to design hardware—and he also offers examples and suggestions for how mechanical teams might overcome them. As Ullman puts it, “They are challenges, not impossible hurdles.” However, it’s one thing to adapt frameworks and practices. What about tools? 

To put it simply: agile tools that are created for software teams have limitations for mechanical teams because they’re not built for mechanical teams. 

What would an agile solution built for hardware look like?

For our co-founders here at CoLab, the same search for a better solution came up empty in 2017. Which is exactly what led them to leave behind Silicon Valley (including a job at Tesla) to start building CoLab. Taking inspiration from agile—but also from lean manufacturing, continuous improvement, and modern team collaboration tools like Slack or Google Docs—Adam Keating and Jeremy Andrews decided that if better tools for mechanical teams didn’t exist, they’d build them themselves.

Because at the end of the day, any hardware team that’s curious about Jira or about agile practices really just wants to make it easier to deliver quality products, on time. It’s not about using any particular tool or framework,  It’s about being able to innovate faster and spend less time on non-value-added work. 

And although change is more difficult and expensive for hardware products versus for software, the volatility of global supply chains in recent years is creating an urgent need for greater responsiveness and adaptability in hardware development. So how can teams make the most out of the toolsets of yesterday while adopting and integrating the tools of today and tomorrow? First let’s take a look at the value that engineering teams are getting from Jira.

How are teams using Jira successfully today?

While Jira wasn’t initially designed for complex mechanical product development workflows, modern hardware teams have found success in using Jira for managing top level engineering programs. And it isn’t just engineering that uses Jira. Program management, manufacturing, supply chain, product management also use the tool. Teams use it to effectively manage project plans, roadmaps, and resource allocation, as well as mid-level work like task management and issue tracking. 

Hardware specific challenges still remain

Teams have successfully used Jira for project and task management. However, challenges remain for those seeking solutions that can handle the unique complexities associated with hardware workflows. In 2024, CoLab Software surveyed 250 hardware engineering leaders, identifying the following challenges that have gone unaddressed by traditional project management tools:

• 43% of design issues are never tracked or addressed
• 88% of engineering leaders say it takes several hours or more to find relevant information about a specific design decision
• Engineering teams spend almost a quarter (23%) of their time on non-value added work

The impact of these challenges is simple: 90% of hardware teams experience delayed time to market on new products. And while it would be irresponsible to suggest that there is only one way to address this issue, engineering leaders point to design review quality as the biggest predictor of on-time delivery of new products.

So working backwards, what capabilities would a tool need to provide to enable teams to elevate design review quality, and in turn unlock new levels of product development speed? CoLab provides several capabilities to tackle this. Here are a few examples:

1. Request Reviews – Users can prompt anyone to participate and contribute design feedback, driving accountability across the team and increasing the volume of high quality design comments. 
2. Automatically documented design feedback – as mentioned above, 43% of design issues are currently not documented and go unaddressed. CoLab automatically documents design issues as they are created, ensuring that issues don’t slip through the cracks.
3. Integration with Jira and other tools – CoLab will send design feedback directly to Jira as issues, making it easy for teams to transfer design review context into their task management system without any administrative burden. 
4. Insights – CoLab considers your design review data and will provide you with insights you can use to identify and resolve bottlenecks in your review process. 

The Best of Both Worlds: CoLab + Jira Integrated

We would be remiss to say that Jira doesn’t work for any part of the hardware development workflow - so long as its gaps are filled by other purpose-built tools.

In fact, we are seeing teams make better use of Jira by leveraging integrated tools. In November 2023, CoLab launched an integration with Jira. The goal was to empower users to get the design engagement benefits of CoLab, namely more effective design reviews, simpler external design collaboration, and true engineering-led cost reduction. This opens space for teams to use Jira for its intended purpose: issue tracking and task management.

Users place design comments directly on 2D or 3D CAD files, which are immediately sent to Jira as issues. Teams using the Jira + CoLab integration are seeing the following improvements to their workflows:

• Design review comments become Jira issues with no manual effort
• Higher volumes of issues making their way into Jira
• Fewer discrepancies between issues communicated in design reviews and corresponding Jira issues

It may seem simple, but it’s important. Because at the end of the day, engineering teams need a simple way to:

1. Share and discuss designs
2. Capture comments and feedback that are actually useful
3. Organize and prioritize feedback and issues in a way that makes execution easier

We’ve seen proof that this can’t be done with agile project management tools alone, but can be pulled off when agile tools are supported by the right system of engagement. 

Looking Forward: Winners and Losers 

It might sound like a tall order. But the companies leading the industry are the ones trying to solve these collaboration challenges and stay ahead of the competition by executing strategically on practical digital transformation initiatives (rather than slogging through big, costly implementations). It’s also no exaggeration to say that those who fail to adapt to new ways of working are making a fatal mistake. 

What got you to where you are today won’t be sufficient going forward. There’s growing frustration with design review and communication processes and tools that have been the status quo for years. Customers, suppliers, and top talent now increasingly expect to have access to modern, cloud-based collaboration and work management tools. 

So, since 2017, the CoLab team has been gathering feedback from 100s of engineers and leaders and iterating on a solution that meets the unique needs of mechanical design teams. And given the success teams like Johnson Controls and Hyundai Mobis have already had with using CoLab, we know we’re onto something with the potential to accelerate the pace of engineering innovation by making it easy for teams to deliver quality products, on time.

You don’t need to use CoLab to make changes for the better. For small teams that only have a handful of engineers and a limited number of external collaborators, there are lots of ways to use homegrown processes and generic tools to improve the design process. But for large companies or teams that need to scale, CoLab might just be the solution that delivers everything you’re looking for.