Experience report from embedded software projects

I have worked in many embedded software projects in various industries, both large and small companies. I’ve noticed a few things they all have in common. I will share these experiences here.

Introduction

Most of my assignments have been about transforming the current project into a more efficient way of working, usually from waterfall to agile, but also from some form of hybrid to a more agile way of working. So, they usually start from a point where only scripted testing is performed. Usually like this:

unit testing and at best integration testing of the software then the software is loaded directly onto the hardware as a big bang and complete system testing is performed.

Early stage

In the beginning when you start explaining how you can help change the way they work. For example, by introducing an agile way of working and starting to do exploratory testing. Set up automated regression testing and they will begin to realize how much we can do to make it more efficient. Also explain the importance of increased collaboration between testers and developers. They also usually find out that we can use a CI / CD concept.

Once they have realized all these things, they want to go from 0 to 100 in just a few weeks, they do not realize that such a transformation will take time, at least a year or even longer depending on the size of the company.

•    You can compare it to the fact that today they travel by horse and carriage when they only do scripted testing.

•    If we introduce an agile approach and exploratory testing, it would be like traveling by car.

•    When we introduce test automation, it would be like traveling by plane.

•    Finally, when implementing a CI / CD concept, it would be like traveling with a space rocket.

As you all probably know, it took a long time to develop these different ways of traveling. It will not take that long, but I think it is a good and fun pictorial comparison.

Why the change needs to take time

First and foremost, the people who work in the organization must adapt to the changes. If it is done too quickly, they can´t adjust in time. There is always someone who does not like the changes either and staff who need some training as well to be able to adapt.

A change must be allowed to take some time, if it is done too quickly the end result will still not be good. Another big issue here is changing tools. They usually like to continue with those they work with today. Instead of taking the chance to switch to more agile. Usually there is also resistance to working agile. ” It feels strange and it’s just a lot of meetings” “we do not have time to do anything”, ” we only go to a lot of meetings” are common comments. Another reason may be that they prefer to work alone instead of working together. Simply no team player.

Organisational challenges

Another common thing that occurs more frequently in large companies is that they often reorganize, which also makes the resistance to changes in the way of working greater. It also creates chaos. The reorganization can take place in two ways. Either the whole organization is reorganized, or it is just one or a couple of teams.

There are usually many who also lack the right skills and need to learn how to do it from scratch. A big reason for this is the recruiters who do not know what skills are needed and have difficulty distinguishing a skilled person from one who is not. This does not apply to all recruiters but many.

The IT department is a story in itself and this I would say is applicable to all industries. They say they trust you despite this, it is difficult to get administrator rights on the computer and other problems with logging in to various tools for example. Which slows things down, removes the agility and makes you frustrated.

Two different types of problems in a challenge

Presenting the agile way of working has two different challenges depending on whether it is the managers who have decided it or whether it is the people on the floor who want to work agile. The latter is preferable, as those who will be working in the teams want to make the change. If it is the other way around, it is forced on them. Which is not a good combination because working agile is not just something you do, it’s a mindset. When it is the people on the floor who want the change, it is managers who must be convinced. That change to an agile way of working will benefit the company and increase productivity.

In the first situation, it is the people on the floor who need to learn how to work smoothly and usually most do not know how to do it. So, you start on a big uphill, because of what I mentioned it’s a mindset. Not just something you do and many of them usually do not want to change working methods.

In the second situation, it is managers who need to be convinced. Here the challenge becomes greater the bigger the company is. In a small business, only one manager or two may need to be persuaded. In a larger one, there may be 3 or 4 managers with increasing control.

One way to do this if it is difficult to get the change approved is to ask permission to at least make a proof of the concept and then show them how much more productive you became.

Big organisations

When you have a huge organization with many Scrum teams and, for example, work according to the SAFe method, other problems arise. Tools are one of those where the teams use them in different ways and there is no uniformity. When senior management has to try to understand what all the different teams are doing, it just gets confusing. Another is also how to use points in your Scrum team, which can also differ between different teams.

Hardware & mechanics

The last challenge is about those who work with hardware and mechanics. They have great difficulty seeing the benefits of working according to Scrum. Because they hardly update their drawings and have very few deliveries. In addition, almost 100% of all examples use software as a starting point, on how to work agile. Almost no one has thought that you need to include both software and hardware in the development strategy.

I made the mistake myself the first time I worked out a test strategy for an embedded project but got help from a more experienced person. You need to start with two legs, one for the hardware and one for the software, and test them separately, so you know that both work when separated to make an HW / SW integration where you load the software on the hardware. As mentioned above, this is often forgotten and the software loads almost immediately on the hardware in a big bang and when it does not work you do not know if the problem is related to hardware, software or maybe both.

Summary

As you may have realized, there are many things that need to be taken care of and thought about to make it work in the end. What you usually need to start with is to calm down the process and ambition because every company I have worked with wants to get everything started in just a few weeks.

Being able to explain why it needs to take time is an important skill to have. Get to know the team and the organization quickly to get an idea of ​​what skills need to be taught or if we even need to recruit someone.

Adapt to the challenge you have, whether the agile desire comes from the floor or if it comes from the managers. If you have a large organization, the challenge is even more difficult because there are many teams that have to work together and it can be some form of Scrum of Scrums in the form of, for example, SAFe.

The development of hardware and mechanics is a challenge in itself. It must be remembered in the strategy and get those who work with it on the train as well.

Thank you for reading the entire post and I hope you have learned something and good luck if you are going to change an organization.

Feel free to comment if you have other experiences or think I have forgotten something.