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

[Patrick Geers]

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

[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]

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]

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 :-)

[Admin]

So 18 months later or so- how are things going? ;-)

[Patrick Geers]

Hello Marko,

Things are busy, so busy that I still have not made the change to use Jira.
As it seems that at this moment there is also a push from management to make the transition.

What do you think of the Agile Hardware Workflow I created?

Do you have ideas about such a workflow?

Best regards,

[Admin]

It makes sense as an overall concept- it "feels" that you have a multitude of people working and a multitude of projects running at the same time to require so much segmentation in the process flow, right?

My company requires a decent amount less, we're focusing on a handful of projects and products- so the level of compartmentalization isn't necessary for us but may not be harmful either.

Have you made any changes to the list now that it's been 18 months? Would you still implement as is?

I too am a little confused as to why hardware isn't more talked about here.

[Patrick Geers]

Hi Marko,

We have a small Team of hardware developers 2 Mechanical Engineers and 3 Electronics Engineers, and a handfull of projects.
I think what you call compartmentalization is my way of trying to have an Agile workflow in which an Egineer works only on the most important task until it is finished before starting on the next. Because for HW-engineering you mostly wait for the complete design is ready before you start a "Build" and "Build" often take 6-10weeks, there is a long time of inactivity on a ticket between finishing progress and starting validation.

To have one in progress item on the board per Developer I created some wait statusses, "Processing" and "Manufacturing".
At this moment I am feeling that this is overcomplicating the workflow, and I feel more like accepting more than one issue/developer to be "In Progress". And thus removing the wait statusses.
I see in our SW-group that Developers are assigned to more than one issue in progress.

Can you share your plan for a HW-Workflow?

Patrick

[Patrick Geers]

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

[Andrew Forrest]

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]

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]

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]

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]

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

[Scott]

Following this thread... lurking for a couple of years now. Have a bit more experience with JIRA/CONFLUENCE now and can give my 2 cents legit. I work in a company designing agricultural equipment. This entails mechanical, electrical, hydraulic, pneumatic, electronic and software design and manufacturing. About 10 years ago, we moved our company toward MBE [model based enterprise]. This means that our engineering outputs are the source information for all business activities. This resulted in our primary MCAD software driving our workflow which we manage in EPDM [enterprise product data management] from our MCAD vendor [SolidWorks]. As a result, when I got into JIRA/CONFLUENCE, it was for requirements, testing and knowledge base development and tracking and not global activity workflow management. Since then, I have also got our contractors on JIRA too and we now only collaborate over JIRA [KANBAN] for all developments and changes.  This is primarily for the electronics/harness/software side of things. I am happy with this and continue to find additional value in its use. Recently, I have started another project, which is more of a blue sky development between several parties in the Ag sector. I am finding that all my playing around and experimentation with Jira has become more valuable and don't care that I am using it well outside the original intents of software development. I am using Jira Software Cloud and Confluence to glue together in a collaborative way, all team activities. Its more of a GPS than a shovel for me in this respect. The more complex projects get, the more value it has. It allows me to bring clarity to the table for all parties involved in projects. So to sum up, I use the features that give value to my activities and they always seem to exceed my needs. For workflows, I will stick with our EPDM versions and remember folks, when it comes to workflows: simpler is better.