Layout

Agile Myth #1: It Can’t Work for Hardware!

TCGen is trusted by
these brands and organizations

Workday Logo
Workday Logo
It’s Management, not Ceremonies. - That is the problem and solution

It’s management, not Ceremonies.

That is the problem and solution

We repeatedly hear statements from hardware teams trying to increase speed and predictability in their product development projects but refuse to believe they can employ Agile methods. They don’t get the real deal for Agile. They don’t understand that it isn’t the practices themselves (Fixed Length, Short Duration Sprints, Standups, Burndowns, Planning Poker, User Stories) that enable success – it is what these practices allow.  Think about it more deeply, and you will find that the real reason that these practices work is that they facilitate a conducive environment for success!  The elements of success, based on our research, have much more to do with management than teams:

  • Facilitating changes in product
  • Enabling teams to do their best work
  • Getting managers out of the way

Myths Hinder Adoption

The myths about Agile generally come from those who aren’t students of the discipline but merely observers from the side. They’re correct that a rigid application of Agile software techniques within a hardware development project would break down quickly. However, when modified for the unique characteristics of hardware design and manufacturing, Agile’s key elements allow teams to gain the speed, predictability, and product definition advantages that their software counterparts enjoy.

The Agile Manifesto – Not Just for Software

Our experience with clients, as well as our primary research, explodes the myth that Agile is all or nothing and that it is inapplicable to tangible products. The Agile manifesto refutes that Phase-Gate/Milestone and Agile are mutually exclusive. Of the twelve Agile principles in the Manifesto, 75 percent are not software-specific. For example, such concepts as “Business people and developers work together daily,”; “Projects require motivated individuals, support & trust,” or “Face-to-face conversation is most efficient” are not software specific. There’s no reason that these principles cannot operate in any product development environment.

Facilitating Change in Product

There is much to be said about having flexibility in the product definition for dynamic markets and fast-changing customer needs.  Furthermore, it takes a long time to document all the requirements, so waiting for this to be finished before the team starts delays time to value.  If you think about it, this is possible in hardware and software.  It starts with having a dedicated Product Owner – and a Process for documenting and prioritizing requirements.  If hardware teams do these two things, they can gain substantial benefits from the Agile methodology without getting all bogged down in a perception that you can’t create stories for systems or hardware (which you can).

Optimizing Team Performance

We’ve discovered that much of Agile’s success comes from the scrum team. We have found that teams perform best when you hire good people, define the leadership system for the team (including self-organizing), and clear the path from obstacles.  In summary, this can be achieved by enacting the following:

  • Upper management encourages teams to plan from the bottom up
  • Middle management changes its focus from micro-managing to removing roadblocks
  • The team stays together and develops cohesion

Getting Managers out of the Way

The third factor is the most sensitive – as you managers may be reading this post.  But look in the mirror and ask yourselves if you should be incessantly texting the project team lead in the morning OR if you should find out what the team needs from you to succeed.  If you frequently query the team about a task, a deliverable, a deadline, or a result… again, ask yourself, do you have the right people on the team?  Do you trust the team to communicate with you when there is a problem?  Do you have a rapid way to get back to the team with a management decision?

If not, the problem is in your court – not with the development methodology.  Get honest about getting Agile, and look under the covers.  Focus not on the rituals and ceremonies but on what those practices achieve in effective organizations.

Further Reading

Enhance your understanding of Agile by reviewing our selection of top Agile Framework books authored by leading experts in the field.