Agile product development is an application of software methodology to a physical manufacturing process. In a sense, building a product using Agile or – to be more blunt – making hardware like making software.
Agile isn’t new. Like SaaS, the cloud, and many technologies revolving around the concept of digital transformation, many write about Agile as a ubiquitous aspect of the future. Yet, for many hardware manufacturers, this creates a disconnect. They’re very likely aware of Agile, it’s true…but Agile as a software development philosophy. Agile product development in the context of physical products is another reality altogether, one that many still question.
In this blog, we’ll explore all different angles of Agile product development, from its origins in software to the values and principles to why it works for hardware product development.
While the exact origins of the principles of Agile are unknown, we do know when the terminology fully took shape. The Agile Manifesto was created in 2001 when 17 software developers convened to discuss the potential and strategies behind lightweight development philosophies. As this history suggests, it was purely in the realm of software. The manifesto can be broken down into 12 core principles and four central values, all of which are geared toward facilitating higher levels of collaboration, greater transparency, and faster time to product delivery.
After its debut, the Agile Manifesto quickly became commonplace in software, seen by many as a universal positive. True to its design philosophy, using Agile increased productivity, improved product delivery times, and strengthened communication between teams – especially when work was distributed.
Yet, while all of these positives were felt in the software space, many in hardware had doubts about Agile’s applicability. The work done in Agile is broken into sprints – preset durations of work that usually last a determined number of weeks and end with a deliverable product. Possible in software, seemingly impossible in hardware – at least when sprints must be weeks, and if the desired outcome at the end of every sprint is solely a useable product.
But, when you look at the values and principles, there are adaptations that can be made to support Agile in product development. Let’s take a closer look at those values and principles to better understand the Agile mindset.
As we mentioned, the 12 principles of Agile were written with software development in mind; while the spirit of them are very much applicable in hardware development, adaptations may need to be made to suit the creation of a physical product, rather than a digital one. We’ll note throughout.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Communication is paramount in Agile. The customer should be included in product development early and often, so they may provide accurate feedback of their wants and expectations. Doing this reduces the risk of misalignment and allows the team to more quickly bring challenges or obstacles to the client’s attention, if needed.
“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”
Agile embraces change in requirements – no matter when it occurs. In a traditional waterfall process, late-stage changes wreak havoc; with Agile, change – even in a late development stage – should be considered welcomed as it’s a representation of reality. The market, competition, and customer needs are always changing and evolving. As a project develops, it’s essential that new information is incorporated into the final design.
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
With Agile, the emphasis is on streamlined product development. The manifesto outlines a goal of delivering no later than every couple of months. For hardware design, especially with large, complex products - this short timeline may not be possible, but it is essential that there are clearly outlined goals and specific checkpoints for the project to meet and collect feedback.
“Business people and developers must work together daily throughout the project.”
No one should work in a vacuum within the Agile methodology. Frequent communication between stakeholders and developers ensures the project has necessary resources and stays on track. Daily stand-up meetings are common and work well with collaboration tools like Slack channels and other real-time cloud-based solutions.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Empowerment is a key element of Agile; both individuals and teams should feel invested in the project’s success and supported in ways that allow them to focus on their work. Part of this principle is not dwelling on the failures or mistakes, rather teams should be enabled to take calculated risks, try different things, and then discuss what did and did not work as a result. Learning from each other on each project is an essential aspect of iterative improvement.
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
There is no replacement for direct communications, the Manifesto says. In 2001, video calls were more of a future than reality for the average person. Now, it’s commonplace. Whether distributed or in-person, there is no substitute for direct, face-to-face interaction when it comes to reducing uncertainty and strengthening team collaboration.
“Working software is the primary measure of progress.”
This one is another one that can be adapted for physical product development where “working product” is relative. It could take two years to develop a new medical device that meets all the requirements. But with Agile, you can take that large project and break it down into more management parts and goals, with scheduled feedback along the way. Instead of something working, it’s more about making the deadlines set to meet the ultimate goal of a working physical product.
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Agile is iterative, meaning that there’s a constant, steady pace to evolve the product. It creates a plan for progress, one that considers the available resources and project requirements. There should be time built into the project to properly complete the task and reflect on the process as a whole.
“Continuous attention to technical excellence and good design enhances agility.”
This one is an always-on goal. Paying attention to the details along the way – to ensure best practices across the board – makes it easier to change course or adjust when unexpected hurdles come up.
“Simplicity – the art of maximizing the amount of work not done – is essential.”
This one translates very well to product design where simple is almost always better.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
Empowering the team to figure out how to get the job done will likely yield the best results.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Agile processes are cyclical, and part of that process needs to be reflection and adjusting as a result. Doing so creates an atmosphere of growth and positive change.
With the Agile principles in mind, let’s talk about how they apply (and make sense!) for today’s hyper-competitive market for physical products.
First off, the idea of multiple iterations seems, at first glance, to negate the applicability of Agile in product development. It is not feasible to consistently produce a useable product only to immediately iterate upon it in the next sprint, over and over, until a final is produced. This reasoning is in large part why many manufacturers have assigned Agile as solely a software tool.
The reality, however, is more complex and comes down to an issue of adoption vs. adaption. Merely adopting Agile principles, word for word, can create unreasonable demands for hardware manufacturers. Adapting Agile into a hardware mindset, by contrast, brings the best of Agile to the manufacturing space. Let’s break it down a little more.
All product developments have a lifecycle from conception to product release. Sprints are simply another way of breaking down the stages of the lifecycle. The main point of a sprint is to have a directed, achievable goal. In software, this most often translates to releasing a product. For hardware, however, the end goal doesn’t need to be so literal. Measurable progress is enough and can help break even complex hardware development down into clear, cohesive segments.
Even regulated industries such as healthcare can make use of Agile. If the average product development cycle is two years, manufacturers should think about what can realistically be done in six months. A two-year cycle becomes four sprints, complete with check-ins and product evaluation. By using Agile, manufacturers give themselves benchmarks, team check-ins, and greater transparency into the hardware development process.
The idea of distributed hardware manufacturing is not new. In fact, for many companies, distributed production has been the reality for decades – if not longer. Agile product development is simply about giving hardware manufacturers modern tools to maximize the capacity for distributed work. This goes beyond Zoom and other video conferencing software to a new mindset that prioritizes cross-team collaboration and improves internal dialogue and cooperation.
Communication and collaboration matter today, more than ever. There is growing uncertainty in the market, driven in part by customer expectations. Customers know what they want, and they want it quickly – shrinking the expected time to market. Organizations also must be ready to battle supply chain uncertainty, changing global conditions, and a host of other complications.
Agile product development applies the best of the Agile Manifesto – including increased internal communication between departments and stakeholders, frequent product development check-ins, clearly outlined objectives, and self-organized, highly motivated team structure – and brings it to the hardware space.
Organizations do not have to fully adopt Agile to see its benefits. Every company is different and Agile is designed to be flexible. As we alluded to earlier, the path to success often flows through adaption rather than adoption. Agile product development can help organizations innovate faster while delivering superior products and navigating around uncertainty in an increasingly volatile world.
With any approach to product development, there are going to be advantages and disadvantages. Knowing them in advance can help your team leverage the best parts of Agile and mitigate any potential drawbacks. For a deeper dive, read 3 Core Benefits of Agile Product Development.
Agile will likely represent a shift in how teams and companies approach product development. To level set and get teams on board, discuss what Agile product development means, especially its values and principles and figure out how to adapt those principles into practice for your projects.
Agile requires frequent, real-time communication between cross-functional teams. They need tools to support this way of working; email is not going to cut it when working with large, complex, product design files. Tools like cloud-native CAD and PLM solutions serve agile product development much better than older installed/file-based tools. Complement these core products with enhanced communication and collaboration tools like Slack, Miro, Smartsheet, JIRA, and others. Having shared systems accelerates collaboration across multiple stakeholders and teams, including external participants, like freelance designers, suppliers, and partners.
As teams transition to a more Agile approach, it doesn’t need to be all or nothing. There may be some parts of Agile methodology that simply do not work well at your company. Embrace what does work, leave what does not, and focus on continually improving your processes.
Agile accomplishes objectives in sprints with scheduled checkpoints for demos and progress to be shared. Make sure teams also have time not only to iterate on the product, but also give feedback on the process. Work to incorporate the feedback on product and process in the next sprint. With a growth mindset, the teams have the freedom to fail and learn from their missteps.
Agile and waterfall are both project management methodologies used for execution and management but are vastly different approaches.
Agile prioritizes iterative development, with teams moving in weeks or months to rapidly develop and fine-tune products alongside near-constant customer feedback. In Waterfall methodology, by contrast, every process follows a linear path: processes move through phases in one direction, with backtracking largely impossible or, at the very least, too expensive to be practical or sustainable. Emphasis is placed on optimization at every stage before advancement can occur.
Agile favors cycles over stages. Developers and stakeholders work together on a design, providing feedback along the way. Objectives are accomplished in “sprints”, typically dictated directly by customer input. A customer asks for a product and the team sprints, putting all effort into meeting this first outlined objective. The customer then gives feedback, and the team implements the changes, iterating on a past design to rapidly create a new product. Sprints tend to be short (days to weeks) and focus on accomplishing rapid, small objectives – rather than prioritizing grand accomplishments. With Agile design methodology, feedback and conversation start during the design phase.
No, the principles and core values of Agile methodology have application well beyond software development. While it started with software, businesses are seeing the value of a more flexible, adaptive, and collaborative approach to project management.
There are five phases of Agile, which offers some structure to the process, but they aren’t steps to be followed, per se. They’re designed to overlap and be revisited as new information or needs arise.
This phase lays the groundwork for any agile project; it defines both the vision and outlines it will be accomplished.
The questions to answer in this phase include:
Starting with a vision gets everything on the table (who, what, how, when) and the next phases begin to refine.
A brainstorming phase where everyone gets the cards on the table and it’s all given consideration in a collaborative process. The consideration will determine what’s possible to accomplish and what’s out of reach, given the parameters of the project (i.e. resources, time, etc.).
This phase will get the team to a point where they have a preliminary, broad requirements for the product, an good idea of the workload involved from various team members, a timeline plan for delivery (usually in phases), risks and dependencies identified and mitigated, and an estimate for costs.
The project is now in full swing and the team is executing on the product according to the vision and timeline. However, there will be hiccups and this is where Agile really shines. Through frequent check-ins and communication, the workload is managed, best practices maintained, and any challenges are addressed. The teams should collaborate as needed and keep each other involved in the relevant aspects. There should be regularly scheduled check-in with all stakeholders at various points in product development.
As new information comes out during the product development process, modifications, changes, and corrections are necessary. This is the adapt phase (and it more than likely requires a realignment with the speculate, explore phases as well). Critical to this phase is to seek out input from the various stakeholders, each with different perspectives and expertise. In other words, once the project has something concrete results, there needs to be an analysis of whether it accomplishes the goal. The adapt phase considers this diverse feedback, outlines improvements required, and then outlines the plan for the next iteration.
While agile is cyclical and iterative, every project must have an end. When the product goes to production, or a key feature is updated, of course celebrate this success, but also take stock in the process, analyze it, collect feedback, and incorporate the learnings into the next project.
The agile methodology works well because it understands that the product development process isn’t linear; it creates a framework that allows for teams to effectively respond to change, risk, and uncertainty. It emphasizes collaboration, inclusivity, and flexibility. It also puts customers at the heart of the process and product, which ultimately allows for better product design.
Colin McMahon is a senior market research analyst working with PTC’s Corporate Marketing team, helping to provide actionable insights, challenging perspectives, and thought leadership on trends, technologies, and markets. Colin has been working professionally as a research analyst for many years, and he enjoys examining and evaluating just how large the overall impact of digital transformation technologies will be. He has a passion for augmented reality and virtual reality initiatives and believes that understanding the connected ecosystem of people and technology is key to a company fully realizing its potential in the 21st century.