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 steadily more intertwined with software development, and it’s not surprising if your engineering team is thinking about maybe using Jira (or you’re using it already). It’s agile, it works great for the software folks, 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.

‍Yet, as Caroline Mimbs Nyce wrote for The Atlantic in 2017, “On the heels of Agile the philosophy came Agile the industry: Agile software, Agile coaching, Agile trainings, and Agile conferences.” The agile movement keeps on growing, and the number of agile tools out there grows along with it. And when the Atlassian Marketplace launched in 2012, allowing third-party developers to offer plugins for Jira, it helped accelerate the spread of agile among non-software teams.

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. But to get more specific about what that means and why it matters, let’s get back to Jira and look at where it falls short when used for hardware development.

‍

Jira Isn’t Designed to Manage Mechanical Workflows

Even as Jira is targeting more non-software teams, and hardware is becoming more closely linked with software, mechanical teams aren’t part of Jira’s core focus. Can you use Jira for hardware development? Well, though it’s definitely possible to set up your own custom-built hardware development workflow for Jira, that’s also true for any old agile project management tool out there. But often, going that DIY route involves a lot of pain if you want to get (and keep) it working.

There are three main shortcomings for hardware teams using Jira:

1. Hardware isn’t a focus for Jira.
2. 3D viewing isn’t supported.
3. There’s a lack of industry-specific Marketplace plugins.

Although that’s not necessarily a comprehensive list, these three items on their own still have significant impacts. You could also argue that item #1 is a contributing factor to items #2 and #3. Basically: since Jira wasn’t built with mechanical teams specifically in mind, it can’t always deliver on needs that are specific to mechanical design workflows. Those needs can be something as substantial as not supporting 3D viewing or they can also be something potentially less crucial, like not having a community where you can easily get advice or ideas from others who use the tool similarly to you. 

For example, the discussion from this Atlassian Community post (select replies pictured below) gives the impression that there might not be the same sense of community for hardware teams using Jira as for other teams. But perhaps the more relevant example is the post’s actual original topic—creating an agile hardware development workflow to use with Jira—since it really underscores the pains of trying to customize your Jira setup from scratch to adapt it for hardware design.

‍

‍

Then there’s the fact that Jira isn’t equipped for 3D. When software teams use Jira to track issues, there are efficient ways to provide the relevant code information and the relevant context for the issue. That’s all simpler to do for software teams than it is for hardware teams, in part because of the 2D nature of code. But hardware teams using Jira run into familiar problems and complications when dealing with 3D. It’s not just the lack of 3D viewer within Jira, it’s how difficult it is to efficiently communicate about a design issue on a 3D model without the right context.

And the total lack of Atlassian Marketplace plugins to support integrations with CAD and/or PLM systems doesn’t help the situation. Teams looking into Jira might be disappointed if they expect to have access to things like an out-of-the-box SolidWorks PDM Jira integration or a Windchill plugin. It’s tough (possibly impossible) to find anything on the Marketplace that allows users to easily include or connect all the context and product information that pertains to an issue, right from their CAD or PLM tool.

So Jira’s a powerful tool for software development and project management, it’s just never really been meant to be used by mechanical teams. That’s why it’s not tailored perfectly to their needs. So then, it’s worth asking: what qualities would a “Jira for hardware” type of tool need to have?

‍

What Hardware Development Teams Really Need to Deliver Quality Products, On Time

Looking at tools like Jira or GitHub for software teams, the mechanical world typically hasn’t had access to equivalent types of hardware development tools. CAD and PDM/PLM have been the dominant technologies for mechanical design teams since the 20th century. But for collaboration and work management, the status quo in mechanical engineering is still basic, old-school communication methods for sharing and reviewing design files—like sending marked-up screenshots via emails or PowerPoint decks (potentially even resorting to the likes of Microsoft Paint to get the job done).

Before the pandemic hit in 2020, some teams were still pretty reliant on paper-based processes and an abundance of in-person meetings or ad-hoc, over-the-shoulder reviews. Now, remote and hybrid ways of working have become widely normalized and enabled. So it’s no surprise that more hardware teams than ever are looking for new and better solutions for their collaboration pains. 

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) and to start building CoLab instead. 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 engineering better ways for engineers to design products. 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. On top of that, inflation and rising costs are also canceling out the effectiveness of cost reduction efforts for many companies. As a result, many engineering teams are feeling the need to rethink their current approach.

To support collaborative hardware development, the right tool should make it easy to:

• Quickly and securely share design files among both internal and external teams, while maintaining control over the access and permissions of any given user.
• Provide full mechanical context to anyone who needs to give input on a design, letting them view and interact with 3D models even if they don’t have a CAD or PLM seat.
• Automatically organize and track a complete digital thread of the discussions and decision history associated with any given design file.
• Gain greater visibility into the design process without needing to manually ask for status reports.

‍

‍

‍

A Design Review and Collaboration Tool Purpose-Built for Mechanical Engineers

It might sound like a tall order. But the companies leading the industry are the ones trying to solve for 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 from a tool like Jira—and then some.