Dear reader, let me share with you a conversation I had with the Chief Engineer Digitization & Software Development of a large company that produces complex electronic devices with many software elements in and around them. He is a European guy. His name is Michael. Michael has been in the business for years and accepted his Chief role some 6 years ago. For him electronics and software development is second nature, and he is savvy about physics. I recently spoke with him to understand his perspective on the new product development process the company is constantly working on, and I know he is struggling.
“Yes Huub, I am struggling. We try to figure out how to balance the software ways of working with the new product launch process. You know, we as software guys we don’t produce a product but features, if you will components for products. Not only firmware but also end user applications, GUIs and IoT applications. These have a very different nature”. I ask: “So, that is not new, what is the issue then for you?”. “Well, sometimes I doubt if my colleagues from other departments understand how we work and what we work on. The best software is created by dedicated teams, in a condensed period of time, with Agile ways of working. You can control the speed and quality of work very well. But the mechanical side of the company has a completely different rhythm, they cannot work with 2-week sprints, daily standups, etc. For example, a hardware test could take 6 months. Then my guys have to wait, so I have to give them other work in another software project. Months later we have to restart the old one. That is not efficient, it costs money, time and quality. And I am not sure the rest of the company understands this.”
This is not the first time that I hear about these conflicting rhythms of work and I think this is common, so I ask Michael: “But Michael, you have experience, I don’t understand why this is a problem, it belongs to the nature of your business. You know that designated teams are very difficult to realize. You know you have to organize your resources so that they can be used flexible?”. Of course Huub, but my problem is that my colleagues don’t appreciate the cost of this. It makes my components more expensive, and the pressure is on being productive, stick to cost ceilings. And if my component in the end is more expensive, I get blamed for this”. “But you can realistically estimate the cost of a new feature or a feature repair, can’t you?” “Yes, I can, but during the process there are changes, also because of testing, the requirements can change dramatically, the costs go up, and then we are not competitive anymore. Scope creep is really a problem, and re-doings. Expensive.”
He continues: “look, I am in fact an internal supplier of software features and software components. For the year I get a budget, a number of FTEs, and I have to make the best out of these. But there are hurdles. One of them is that there is an increasing demand on us to help customers, to help our services people and to do many quick fixes. My best people are very busy with that, and these things are always urgent. And when there is a problem with a product, software is always part of it. So my Team Leaders, I have 10 of them, struggle to plan for the new feature development work. On paper it is easy, but practice it is complex”. “So, are you saying you don’t have enough FTEs?”. “Indeed, the resource distribution needs review, but I can tell you, the company has to compete, digitization is strategic, and we are under price and time pressure from Chinese competitors and startups. So the space for extra resources will be limited. Perhaps we have to outsource more, that we do the prototyping and leave it to 3rd parties to make and deliver the product. There will be a lot of water under the bridge before we have fixed this however”.
I ask him: “Michael, how do you want to tackle it now, what is your plan?” “What really would help us is to know in time exactly what we have to deliver to the product and to manufacturing. And how much cost I can make. The earlier we know this the better we can avoid re-doings. We need early alignment and realistic agreements with product management and the mechanical side of the business. Then I can give realistic estimations because we will first prototype new features, in our innovation program. I have decided to separate the front end development from the actual delivery of the features. I think that will help”.
Again the request for alignment, coordination, better understanding and respect. I noticed that he did not talk about Scrum or Agile as such, but about the designated teams as an efficient method. He wants to win time and money through better alignment with the other functions, by being pro-active, and by avoiding restarts and disruptions. And also by separating the front end prototyping (more agile) from the actual delivery part.
I will talk with Michael again. I know he has ideas about how to do feature upgrades for products that are in the market. He wants to be a lot more dynamic than today.