There are many organizations developing embedded systems trying to adopt agile practices as part of their digital transformation. Many get limited results for one or another reason. In this article series, we will go through some of the more common reasons for not getting the most out of digital transformation and agile. This first article is about not letting go of existing processes.
Challenge your existing processes
Out of the different agile practices, many companies try to adopt the Scrum process. Scrum as a process is not very prescriptive but there are a few things all Scrum implementations have in common to be able to be called Scrum at all:
- An autonomous team
- A scrum master
- A product owner
- A product backlog
If you were starting a new development organization from scratch, these prerequisites would be very easy to fulfill. However, all mature embedded organizations already have existing processes, and all these elements are usually not there.
The common mistake to make then is to lay Scrum, or any other new process, upon existing processes. Suddenly you have two processes on top of each other. However, these processes seldom align.
Your old process prescribes individual responsibility and now you are supposed to have teams. Or, you have a team leader and now you are supposed to have an autonomous team and a facilitating Scrum master. You have project managers and now you are supposed to have product owners. You have Gantt charts and now you are supposed to just have a product backlog.
Usually it is a missed deadline or a change of management. And agile is out the door head first.
This misalignment creates tension. People will start to say that agile does not work. That they need the previous ways of working. And the agile coaches will push on until finally something breaks. It does not have to be much. Usually it is a missed deadline or a change of management. And agile is out the door head first.
So, how do we avoid this?
We need to realize that the current process is there for a reason. This reason might be more or less valid but you are probably reading this article because you see that your current does not fulfill all the needs of the future.
Build collective understanding
The first step is building a collective understanding of what assumptions are behind the current processes. If we then can show that these assumptions are not true any more, for example that the value comes not from hardware but from software, we will be able to create a sense of urgency in changing. We can then use this sense of urgency to get the organization into a creative mode.
Build consensus on wanted goals
Then we use this creative mode to build a broad consensus on wanted goals. It could be business value based such as halving the time to market, changing the customer perception of technology leadership or indirect values such as having happier employees.
Continuous improvements
When we have figured this out, then we need to start working with continuous improvements to reach those stated goals. Practices and ideas of agile processes such as Scrum and Kanban should of course be considered as potential solutions, but it is important not to see them as goals themselves. And it is important to not jump directly to these new processes for the whole company at once but to let them grow out of continuous improvements of the current processes organically. And for that to happen you, you must let the old processes change.
It is not easy, as a leader, when you think you have the solution to step back but remember, leading by pointing with your whole hand is not agile, leading by showing vision and direction is.
This article was also published on Transforming Embedded here.
