Some time ago, I was asked if I was familiar with agile hardware development, or if we even practice agile hardware development and are familiar with the relevant tools and processes. As anyone working in development knows, "agile" is currently in vogue, and every development department and every development project, if possible, should be or become agile.
What are the Hopes behind the trend towards agility?
Wikipedia has an article on agile software development (https://de.wikipedia.org/wiki/Agile_Softwareentwicklung). It states:
The goal of agile software development is to make the development process more flexible and streamlined than traditional process models. Agile software development is a countermovement to traditional software development processes, which are often viewed as heavy-handed and bureaucratic [...].
By developing a product in an agile way, one hopes to make the development process more flexible and lean, and thus achieve the following:
- more valuable products
- shorter development cycles
- early and continuous value creation
- learning organizations
- enthusiastic customers and employees
out of https://www.it-agile.de/wissen/einstieg-und-ueberblick/was-ist-agile-produktentwicklung/, one of the first hits on Google for agile development
These points can be viewed as optimizing the three factors of cost, time efficiency, and quality. Of course, one would like to optimize all three factors, which often leads to contradictions.
Furthermore, there is a desire not to draft the planning and specification at the beginning of the project, but rather to have the planning and development phases run in parallel. Especially at the beginning of the project, there are open issues that can only be addressed during the project's development. Some specifications only prove untenable after testing, and as the project progresses, more and more requests for changes and ideas arise. For example, one can assume approximately 5% of requirements changes per month. The desire to define the specifications later is therefore understandable.
| Dipl.-Ing. Martin Bosch, shareholder, hardware developer E-mail: bosch@medtech-ingenieur.de Phone: +49 9131 691 241 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
Finally, agile development is characterized by earlier and more frequent deliveries compared to traditional development, which allows for earlier investigations and feedback. This sounds reasonable at first. The problem with many projects that don't run perfectly, however, isn't a lack of feedback or late delivery, but rather that critical and warning voices aren't heard. Experienced developers provide valuable opinions, suggestions, and feedback on the products, but they must also be heard. If the wrong parameters are measured or developers aren't listened to, then feedback will be missed. This requires a great deal of sensitivity and attention from those responsible for the project.
I find it particularly interesting how the "agile" movement emerged. This can then be used to draw conclusions about its application in hardware and one's own projects.
The Agile Manifesto
The term “agile” comes from software development and was coined at a meeting of software developers in Utah in 2001 embossed. Before that, the term "lightweight" was common for these processes and methods, so "agile" naturally sounds better. Who wants to be called "lightweight"? :). Agile sounds better, and this decision certainly contributed to its spread. The development is beautifully described on the Agile Manifesto website.
In their manifesto, the participants formulated lofty goals. Reading these goals, you'll wish for nothing less for every type of development. And since you can't read these goals often enough, and the Agile Manifesto may not be well known outside the software community, they're listed here again:
Manifesto for Agile Software Development
We explore better ways to develop software by doing it ourselves and helping others.
Through this activity we have learned to appreciate these values:Individuals and interactions more than processes and tools
Functioning software is more important than comprehensive documentation
Collaboration with the customer is more than just contract negotiations
Responding to change more than following a planThis means that although we find the values on the right side important, we value the values on the left side more highly.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, the above authors
this declaration may be copied in any form,
but only in its entirety through this notice.
Principles behind the Agile Manifesto
We follow these principles:
- Our highest priority is to satisfy customers through early and continuous delivery of valuable software.
- We welcome changes in requirements, even late in development. Agile processes leverage changes to the customer's competitive advantage.
- Deliver working software regularly within a few weeks or months, preferring the shorter timeframe.
- Subject matter experts and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need and trust that they will get the job done.
- The most efficient and effective way to communicate information to and within a development team is through face-to-face conversation.
- Working software is the most important measure of progress.
- Agile processes promote sustainable development. Clients, developers, and users should be able to maintain a consistent pace indefinitely.
- Constant attention to technical excellence and good design promotes agility.
- Simplicity—the art of maximizing the amount of work left undone—is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how it can become more effective and adjusts its behavior accordingly.
What does this mean for hardware development?
Let us keep the sentences short and everyone can consider whether these principles are implemented in their project.
In principle, the word "software" can also be replaced with "hardware" (or "mechanics," or "system") in the principles. Of course, hardware and mechanics have some special features that distinguish them from software. But most agile principles are universal and applicable to any discipline. Every development project will benefit from them and should heed these principles, regardless of whether or not they are preceded by "agile." The point "Deliver working software regularly (...) and prioritize the shorter timeframe" can also be heeded in hardware and mechanical development and is gaining importance due to new prototyping processes such as 3D printing and rapid PCB assembly services.
Concluding remark
To return to the original question: Yes, we are familiar with agile hardware development and try to implement the principles of the Agile Manifesto in our work. I would recommend the same to anyone involved in development projects.
The most important thing is the principles; the tools change. Whether you use Kanban or Scrum, how quickly you order circuit boards, and how much you develop in simulation are all debatable. I welcome discussions, comments, and personal experiences with agility in hardware development.
Best regards,
Martin Bosch
Left:
