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

We hear statements all the time from hardware teams that are trying to increase speed and predictability in their product development projects – but refuse to believe that they can employ Agile methods. They just don’t get the real deal for Agile.  They simply don’t understand that it isn’t the practices themselves (Fixed Length, Short Duration Sprints, Standups, Burndowns, Planning Poker, User Stories) that enables success – it is what these practices enable.  Think about it more deeply and you will find that the real reasons that these practices work is that they facilitate a conducive environment for success!  The elements of success, based on our research has 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 there are key elements of Agile that 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, explode the myth that Agile is all or nothing and that it is inapplicable to tangible products. The Agile manifesto itself refutes the notion that Phase-Gate/Milestone and Agile are mutually exclusive. Of the twelve Agile principles contained in the Manifesto, 75 percent are not specific to software. 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 a lot to be said for having flexibility in the product definition for dynamic markets and fast changing customer needs.  Furthermore, it takes a long time to get all the requirements documented – and so waiting for this to be finished before the team starts just delays time to value.  If you really think about it, this is possible in hardware as well as 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 some 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 itself. 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 their 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 really should be incessantly texting the project team lead in the morning OR if you should find out what the team needs from you to be successful.  If you must 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 to you when there is a problem?  Do you have rapid ways to get back to the team with a management decision?

If not, the problem is in your court – not with the development methodology. Get real about getting Agile and look under the covers. Focus not on the rituals and ceremonies, but what those practices actually 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.