You can integrate hardware and software development with a cross-border team setup, where it’s important that hardware and software developers speak each other’s languages. The suggestion is to focus on "us" instead of "we" and "them", and on the technical competence that connects developers over agile or lean terminology.
Eva Hedin spoke about how to work cross-functional in hardware and embedded software development at Agile Tour London 2021.
The biggest challenge is to get an understanding between SW & HW developers, Hedin said. We are sort of living in a parallel world even though we are all developers, as she explained:
- Languages - SW and HW use different languages and abbreviations. Sometimes we use the same word or abbreviation with a different meaning, or with a similar but not exactly the same meaning.
- Timeline - SW developers are working in short development cycles; this is not possible when developing HW due to the fact that it takes time to produce HW.
- Prototype cost - it is costly to produce an HW prototype; a SW prototype is nearly "free".
As an example of different languages, Hedin mentioned CI: Continuous Integration for SW and Continuous Improvement for HW. The first is the integration of SW to SW and the second is how to improve the way of working, Hedin said. The word integration also has a slightly different meaning. For SW it is the integration of SW to SW, and for HW it is to integrate the product (HW+SW) into the product system.
Hedin suggested to stop using the words lean and agile and to start to talk about how to develop products:
That is the same as with SW and HW; we are developing products and the way of working shall be what fits us best. That depends on where in the life-cycle the products are.
It is always better to focus on "us," not "we and them", Hedin mentioned. People working with development are technicians interested in their technical competence, not that much in the lean-agile vocabulary.
InfoQ interviewed Eva Hedin about developing products that involve both hardware and software.
InfoQ: What have you seen when exploring people working cross-functional with the development of products including HW & SW?
Eva Hedin: Learning…. We have a lot of things to learn from each other.
The people working in SW work in short cycles, dividing their products into small "pieces". This is hard to do when developing HW, but the mindset/WoW is adoptable. For instance, it is possible to inform our customer that the HW will not have all features this time but that some will come later.
The HW developers are the ones getting field returns to troubleshoot so they have a product customer experience that SW developers don’t have, seeing the whole product, not just HW or SW.
For instance: the start up of a product when installing and configuring in the field shall be done according to instructions, and SW tests are built from these requirements. HW developers who have done troubleshooting of field problems at several products know how the installation people usually work and how they install the products in practice. Feedback on tricky and early field problems is sent to HW development for troubleshooting. Therefore, they know the most common installation faults. They therefore do this fool-proof testing when starting up to assure the product can handle this. Many of the testers have worked for more than 10 years, so they are really experienced. To feed back knowledge to SW developers makes the SW more resilient.
When SW and HW developers are starting to work closely together it poses challenges and we are struggling a lot but if we can overcome that, the benefit will be better products. Most of the problems are due to misunderstanding and that we are working in different ways. One example is integration. SW integration is going fine without any problem and then HW comes and says that "integration failed". We do not have the same purpose for our integration. HW integration is to secure the SW and HW work together and SW integration is to secure the SW work in the legacy SW. I have seen this all over the organisation when we have SW/HW relations.
InfoQ: How do the agile values and lean values relate to each other?
Hedin: Agile comes from American SW development and Lean from Japanese car manufacturing (Toyota), so they are actually two different cultures.
Several years ago we tried to compare Agile and Lean by setting up values for lean similar to the agile values. This to show the organization the similarities between the two. We took the one below since they are central for lean. Lean has 14 management principles and lean development adds some more, so this is our adaptation to be able to start up discussions.
If I compare the lean and agile statement, the similarity can be seen in these values.
Agile value:
Lean value:
Individuals are more important in the US than in Japan, but on the other hand, both lean and agile are people oriented. People are important.
These two values are also related to each other.
Agile value:
Lean value:
Optimizing the flow is a way of reducing "waste of time," and to reduce the documentation is also a way of reducing "waste of time".
InfoQ: How can lean and agile work together and what benefits can combining them bring?
Hedin: To divide things into categories is sometimes good, but it also gives us a signal that we are not on the same team.
Our product system is a complicated to complex system with a lot of products included. We have a high development speed so we must develop a lot in parallel. It is important to have clear interfaces between the products, but not between the people developing the products.
InfoQ: What have you learned?
Hedin: I am still learning a lot. One of the most important learnings is that "most important of all in development are the people working with it".
Another insight is the importance of words. The use of the right words and to explain what they mean for me is a cornerstone.