nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

This is my proposal for an Agile Hardware Development Workflow, what do you use?

Patrick Geers_ktt59r

Dear Community,

Our Software Group is currently using Jira.
The Hardware Group is still using an old issue management system of which the support is declining.
We are planning to migrate to Jira.

So I have a choice: Do I create a workflow similar to the current system, or do I create a more agile workflow.
I think an agile approach using KanBan will fit.
Basically my interpretation is: The Engineer picks the most important issue and is assigned to only that issue (with exception of some standalone processes).

Agile Hardware Workflows are hard to find, so I tried making one.

Following images contain my proposal, it might violate some Jira "must haves" (like an open state).
Feel free to comment on it, but above all I would like to see and learn from your Hardware Development Workflow.

Thanks,

Patrick

Accepted answers

All comments

Patrick Geers_ktt59r

Are there no Hardware Engineers on this forum that find this an interesting topic, or are there none at all?

Nil Ister

I'm also working on hardware product development and project management.

Would you use the proposed workflow for one issue type or all issue types in the hardware project? You can also have different workflows for different issue types (would need to use workflow schemes to match a workflow with an issue type).

The only suggestion I have might be limiting the number of statuses the ticket/issues goes through. This might make the process of opening/closing tickets a bit more faster.

Let me know if you're working with fix versions/releases, I find that part a little tricky with hardware development. I would like to have a discussion about it.

Patrick Geers_ktt59r

I will start of using this workflow for most of them, only subtask have a different, much smaller, workflow (Scheduled, In Progress, In Review, Closed).

The number of statusses is one of the reasons I posted this thread, because I think I am making it more complex than needed. So I would like to see what you use.
Can you please share your workflow?

Maybe you should create a thread to discuss the topic about using fix version/releases for hardware development. I'll be happy to join the discussion (if you can please invite me).

Nil Ister

The workflows I use are not created by me but by the admins and I currently can't change them. I'm trying to utilize the pre-determined workflows for hardware product development. Most of the issue types have only Open, In-Progress, and Closed statuses. A few of the issue types also have "assigned" or "on hold".

Since you can configure your workflows anytime, you could try out the workflow you created for a period of time. If you feel like there are too many transitions and statuses, some of them could become tasks or sub-tasks. For example if you think manufacturing doesn't have to be in the workflow, then it could become a sub-task.

Looking back at your workflow, I actually think the number of statuses are fine because they represent important stages in product development. Correct me if I'm wrong, the transitions automatically happen based on the activity in an issue right?

I created a question related to fix version/releases but a discussion would be better, I agree. I will invite you to it once I create it. Thank you!

Patrick Geers_ktt59r

Thank for reviewing the workflow, I'm in the middle of implementing them and will indeed plan to do retrospectives to learn and adapt the workflow accordingly.

At this moment I'm still working on migrating from the current issue management system to Jira. So I do not have the experience yet. I'm preparing the Jira environment with workflows, issue-type and so on. When that is ready we are exporting and importing the current issues.

If you can I would like to see a screenshot of the workflow you use, and maybe you can comment on what you are happy and not happy about. (I assume there are things you are not happy about since you cannot change it :-)

Andrew Forrest_qw4tzo

Just found this...

We are struggling to establish a HW Workflow. Any updates or incite since this post?

Curious that there is such limited discussion.

Patrick Geers_ktt59r

Hi Andrew,

I'm sorry I did not reply to your post.

There's not much to say about this at the moment. I did not make a lot of progress and am equally curious that there are no more companies using Jira for a combination of Software and Hardware development and willing to participate in this discussion.

It would be great if you could share your thoughts about an Agile Hardware Workflow.

Best regards,

Andrew Barnes_ylh3pr

Another Andrew here (I see a pattern developing) and I'm a hardware/software/firmware developer. Several years ago I took Scrum Master Certification and it was fantastic but I challenged the instructor on it's use in a hardware development environment. It would be cost prohibitive to pick several features off a back log, do a schematic, create a layout, order a PCB, populate, test, do a retrospective, then repeat with some new fun features. Imagine trying to do that in a two week sprint.

I do believe there is a way to introduce Agile concepts in a hardware design cycle. My vision has a preliminary research phase where the team gets to play for a time boxed period to experiment with new ideas from a backlog using cheap, inexpensive PCBs. These can be hand populated and tested to validate particular backlog features that are desired during the next hardware design cycle. During this period there will be many lessons learned that should be documented and often thoughts on how it could be better. Hack away at the PCB, make it do what you want and order a new cheap one implementing your lessons learned but remember, you're time boxed. Toyota Kata is an excellent approach for this phase using Plan Do Check Act cycles. After this period the team reports on their success or failure (lets call it a hardware retrospective) at reaching the new desired state for the hardware platform, then begins the grunt work on a final hardware platform that implements the new features with the lessons learned from the research phase (pull up resistors, impedance matching and such). Schematic, layout, PCB, populate, test. Classic waterfall.

My experience is that the research phase is often integrated with the development phase and the end product is what it is, and often not designed for manufacture.

I just completed my PMP certification so I kinda see how Agile can be integrated into a waterfall development cycle such as hardware.

Boris Van Hardeveld

@Patrick Geers @Marko Mandaric @Nil Ister @Andrew Barnes @Andrew Forrest

I don't want to hijack this thread, but it is one of the very few posts I could find where hardware development in the Atlassian ecosystem is discussed.

In support of a hardware development workflow for Jira/Confluence, I'm currently entertaining the idea to develop an add-on for visualisation of EDA files such as Gerber and Drill/NC. These files could be uploaded to a Confluence page or a Jira ticket as a regular attachment (so they are versioned), but the add-on would allow rendering the PCB layers and adding comments and red-lining for review.

Does this seem useful to you? How are you currently handing the "in review" step in the proposed workflow, or how are your documenting your HW designs in Confluence?

I greatly appreciate any feedback on this.

Thanks.

Patrick Geers_ktt59r

Hello Boris,

Currently we share schematics by linking to the design files. All Engineers (also the relevant SW-engineers) are able to view these files using the free viewer that comes with the E-CAD tool. We do not attach design data to confluence pages, we do document review items in a collaborated page.

The review items are currently done in text and sometimes screenshots of the design details. It would be beneficial to be able to do the commenting directly in the design, but I doubt if Confluence is the place to store and version hardware designs.

For revision control in hardware development many PDM/PLM systems are available. A very important feature of these applications is the connection to an ERP system. These applications are often integrated in a specific CAD-system and can often also show data from other CAD-systems (so you can see MCAD and ECAD information simultaneously).

In our case we have been looking for a PDM-system for a long time, but costs are high and time to research is limited. We mostly do manual revision control, manual imports in ERP and exchange 3D-data manually between ECAD- and MCAD-developers. We can do that because there are a relatively small company where Developers are close to each other.

As I learn more about the software progress the "In Review" step resembles a Pull Request in SW. Colleagues are reviewing the design data before going to the next step. With new designs (sometimes multiple) schematics are reviewed by several people also because there are SW-related elements. For the board design the review is mostly done by 2 E-engineers and one M-engineer.
In our software workflow this is not a specific state of the Jira ticket, but an element under a "Development" header. I think this has to do with the tooling used for designing SW.

Hope this helps.

Patrick

Boris Van Hardeveld

Dear @Patrick Geers

Thank you for taking the time and your extended reply.

Given your quest for PDM. In the mean time, I came across a different thread which mentions the following blogpost by Altium: https://resources.altium.com/p/end-end-tracking-your-pcb-design. In it, the author advocates storing the design files (in this case EDA files, but I don't see why you could not extend this to CAD files using git LFS) in Bitbucket (which could even co-host the firmware or software as well). Using Jira ticket numbers in the commit messages, the work items in Jira and the design changes are fully traceable and there could be some kind of uniform workflow between HW and firmware/software. Think: pull request in Bitbucket which include both the HW and firmware changes. In this case, I could see value in being able to visualise PCB's directly in Bitbucket to ensure a uniform review experience as well.

Given your explanation, this workflow would be lacking in terms of a connection to the ERP system, am I right? Which features exactly does the ERP bring to the table in this context?

Thanks again.

Patrick Geers_ktt59r

Hello Boris,

What you propose is interesting, it is giving the E-engineers the possibility to cooperate better an in a more uniform manner.

What my main goal is for a PDM system is revision control on the complete product, including COTS-part, custom mechanics, cables and electronics.
I have no experience with Bitbucket and if it could provide revision control and hold all documents and design files for these parts.

An ERP (Enterprise Resource Planning) system uses information from the PDM to plan purchasing and production of the products. In our case this is also where we do revision control and link to production date (ERP is not ideal for this purpose).

The PDM is build for this purpose. Since we don't have it I do not know all details. Discussions about it are often which (PDM or ERP) is leading in information. I assume that production data and revisions are leading in PDM, but cost and lead-times are leading in ERP.

Some PDM's (especially when based on M-CAD) provide 3D visualization of all components.

Best regards,

Patrick

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira