How to Overcome Internal Reluctance to Agile Product Development
Agile product development is in a strange place. In software, it is seen as commonplace, mainstream, and frankly, a no brainer. In hardware, however, Agile product development is often viewed as tricky, challenging, and perhaps – a gimmick. Yet Agile is already a differentiator for physical product creation.
In a recent PTC survey, respondents were asked to self-identify as either leaders or laggards regarding their competitive position. While this segmentation provided many differences, one in particular was stark. (We'll be covering the full results of this survey in a upcoming whitepaper, The Approach to Agile Product Development: What Leaders Do Differently.)
Laggards are much more likely to encounter internal reluctance when it comes to Agile product development. Indeed, they were almost twice as likely as leaders to report this obstacle. But why exactly is this an issue and what can laggards do convince internal leadership to buy in to Agile product development?
Before we get too philosophical, however, let’s lay some groundwork: What do we mean when we say Agile product development?
At PTC, we define Agile product development as an application of software methodology to a physical manufacturing process. In a sense, building a product using Agile or – to be blunter – making hardware like making software. Agile product development typically follows four core values:
- Individuals and interactions over processes and tools
- Working product over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
This methodology is now dominant in the software space, precisely due to its flexible nature and its prioritization of clearly defined value-driven sprints. Organizations find it easier to break down complex software projects into achievable, understandable work segments and focus on accomplishing one task before being distracted by another.
Think of it this way: Would it matter if Microsoft Teams had video chat if it first couldn’t integrate with your web camera? By prioritizing the work (ex. Enable webcam integration THEN enable video chat functionality), a complex project becomes more transparent and easier to understand, and there is less risk of missing a crucial step.
These benefits aren’t exclusive to software, yet many physical product creators feel exactly that sentiment: “Agile, great for them but not for me. It’s just not possible.”
Well, it is possible and – more importantly – odds are you’re doing at least some Agile product development without realizing it.
Understanding the internal reluctance to Agile product development
Agile can be a difficult methodology to track. There are no Agile police – no external force an organization can go to and ask “is my company really Agile?” As a result, we’ve seen organizations say they’re Agile when they’re not, and companies claim not to be Agile, despite following several key Agile product development procedures (usually daily meetings, frequent client feedback, rapid sprints through at least one production phase to create a prototype, etc.). This confusion can be one of the reasons executives dismiss Agile.
That said, much of the reluctance in the hardware space comes from Agile’s association with agile. A decision maker may read about Agile product development and say “Sure, software can be made in weeks, but hardware takes much longer.” While Agile product development relates to speed, however, it is not about going fast.
Agile’s focus on sustainable progress
One of Agile product development’s core principles is sustainability, just not necessarily in the context of environmental friendliness. Anything done using Agile methodologies should, in theory, be able to be repeated indefinitely without creating challenges or obstacles. Sprints are only as useful as they are dependable. Organizations are not encouraged to go too fast, lest they burn out employees or set unrealistic standards for the next project.
In software, a sustainable sprint may be weeks but hardware should never feel compelled to match this pace. If they do, however, Agile product development is flexible enough to accommodate. Sprints are not always about delivering working product, but rather measurable value. So physical products don’t have to be created in weeks. Organizations do, however, gain a more complete understanding of the phases and breakdowns required to consistently deliver measurable value throughout product development.
Knowing that time and speed are not the crucial factors of Agile that some believe may help alleviate the internal reluctance to its usage. Agile product development prioritizes consistency, collaboration, and risk aversion – all of which are achieved through sprints designed to deliver measurable value, whether that is a working prototype or simply a definite checkmark in the path to physical product creation.
Keys to Agile success
Start small
Reluctance to Agile product development also stems from its perceived cost investment. Digital transformation is rarely inexpensive, and companies are used to weighing the benefits of a digital initiative against the cost of its implementation. Agile, however, is not tied to technology. There is no startup investment cost. In fact, Agile product development typically uses software that is already increasingly common. Programs like Jira, Microsoft Teams, and Zoom can all be used in Agile workflows.
In addition, the switch to Agile doesn’t have to be company-wide to start. In fact, it most always shouldn’t be. Companies toying with Agile product development often pick a small team to experiment with. This team should be working on a project that feels appropriate to applying Agile concepts. Starting small allows organizations to compartmentalize Agile against existing workflows and fully understand if and how it’s making an impact.
Measure and measure again
One of the largest success stories of digital transformation has been the increase in transparency. With digital tools, organizations can better track performance and measure success, understanding exactly how certain systems perform and knowing when to regulate them. Agile is no different in this regard. It is not enough to tell a team to try Agile product development and then make no effort to measure the performance. Of course, instant results should not be expected and the first project will likely be the least efficient one as the team adjusts to Agile product development, but after that results should soon be forthcoming.
Pick a workflow where the results can be easily read and understood by the leadership team. That way, Agile’s impact on the current process is measurable. This will give internal stakeholders something concrete to point to when evaluating whether Agile product development is the right fit.
Getting internal buy-in on Agile product development is crucial to its success, and laggards risk further competition by ignoring what could be a real boon for productivity. Yes, Agile is often associated with speed, but this does not need to be the case. Agile product development does not need meaningful cost investment, it simply needs the right team, the right people, and the right mindset to see it through its testing phase, so that it can be truly determined if Agile product development is right for your business.