“Do you have any experience in Agile hardware development?” I was asked at the go/no-go decision meeting.
I was completely up-front with them.
“No,” I replied. “And I don’t know anyone who does.”
At that point, Agile hardware development was largely unexplored territory. We had decades of experience to draw upon in Agile software development, but very little experience applying Scrum to purely hardware products.
“You will be pioneers,” I added. “If you decide to proceed, everyone needs to understand that there may be challenges along the way.”
To their credit, they were willing to accept the risk, and the project received approval.
We planned the engagement in the same way we would approach a software project: begin with Scrum training, write high-level Epics for Release Planning, draft the Release Plan, write and refine Stories for the first Sprint, and then begin Sprint execution.
There was an additional challenge. The team members had never worked together before, and most had learned only shortly before the training that they would be using Scrum.
I give them a great deal of credit for their open-mindedness. They were willing to learn and give this unfamiliar process a chance.
At the time, I had not yet developed a dedicated Scrum-for-Hardware course. As a result, I used my standard Scrum training material, changed one slide, and discussed hardware-specific issues at the appropriate points throughout the class.
The Product Owner for the project was Dr. Michael Belford, a physicist who would also participate in the development work as a part-time team member. The project itself involved the development of a new mass spectrometer for Thermo Fisher Scientific.
This led to one of the first important lessons from the engagement.
Lesson #1: In hardware development, the Product Owner is often a team member.
The reason is that ownership of a hardware product typically requires deep technical knowledge of the product itself. The person making decisions about priorities and tradeoffs frequently possesses the same specialized expertise required to contribute directly to the development effort.
This differs from the software model, where Product Owners often come from a product-management background and focus primarily on user needs, market requirements, and business outcomes rather than technical implementation details.
Both models are valid, but they involve different tradeoffs.
In the software world, a full-time Product Owner can often support two or three teams simultaneously. In the hardware world, a Product Owner who is also contributing technical work is unlikely to support more than a single team.
That was the first major lesson we learned from applying Scrum in a hardware-development environment.
In the next post, I will discuss another important discovery: why Release Planning turned out to be far more important in hardware development than many Agile practitioners would expect.
For those interested in the full case study, the complete Thermo Fisher Scientific story is available on my website at https://kevinthompsonphd.com/storage/papers/LessonsLearned-AgileHardware-v6.pdf.
This is a highly accurate and fascinating point. Having around 10 years of experience with various hardware systems, and a bit less with software, I can absolutely confirm that the difference is huge. In software, a Product Owner can often rely on the development team to handle system limitations, but in the hardware game, making progress without deep technical knowledge is simply impossible. Thank you for the post!
Thank you! I appreciate your sharing your perspective from both hardware and software development.
I think you’ve put your finger on one of the fundamental differences between the two domains. In software, Product Owners can often focus primarily on user value because the development team has enough overlapping technical knowledge to work out many implementation details. In hardware development, the technical constraints of the product often shape what is feasible, so the Product Owner needs much deeper engineering insight to make informed prioritization decisions.
That was one of the biggest lessons from the Thermo Fisher engagement, and it’s a theme I’ll return to in several of the upcoming articles. Thanks again for your thoughtful comment.
As a Scrum practitioner, I want to understand how Agile can be applied to hardware development so that I can adapt Scrum practices effectively in projects beyond software. I found the insight about the Product Owner also serving as a technical team member especially valuable because it highlights an important difference between software and hardware development. This article provides a practical perspective on applying Agile in new environments, and I’m interested in learning more about the role of Release Planning in the next part of the series.
Thank you for your thoughtful comment. I’m glad you found the discussion of the Product Owner role useful.
One of the central themes of these articles is that Scrum itself translates remarkably well to hardware development, but several software-oriented implementation practices need to be adapted to fit the realities of multidisciplinary engineering. The Product Owner role is one example, and Release Planning is another.
In hardware development, Release Planning becomes especially important because it is the mechanism that exposes dependencies, technical risks, and long lead-time activities early enough for teams to respond effectively. As you’ll see in the next article, I view the planning process itself as being at least as valuable as the resulting plan because it forces those assumptions and dependencies into the open.
Thanks again for reading, and I hope you’ll find the upcoming article on Release Planning useful.