THOMAS ESEBRANT, HEAD OF PRODUCT CENTER, ECARX

Cracking the code: Agile alone can’t deliver the best software development process

Agile is transforming software development in the automotive industry just as it is in every sector, but In the era of software-defined vehicles, closer partnerships between suppliers and manufacturers are also needed to manage ever-increasing complexity and shorter development cycles

Like many innovations, the origins of the Agile development methodology are hard to pinpoint. But we do know that it was in use in one form or another across a number of industries well before the term Agile was first used in 2001 to describe a new approach to software development. We can be just as sure that Agile’s widespread adoption across a range of sectors has dramatically accelerated the rate of change.

To put it into context, when I was studying electronics and computers in the late 1990s, the Cray supercomputer of the time – the SV1 – was capable of processing data at 1 teraflop; incredible then. Today, our next-generation digital cockpit computing platform is more than 10 times as fast, because that’s the performance it needs to manage all of the software within the infotainment system. Writing, testing, validating and releasing that software in the timescales required by our OEM customers simply wouldn’t be possible without Agile development processes.

Agile’s adoption was given an unintended boost in many sectors by a law known as the Sarbanes-Oxley act, or SOX, which was introduced in 2002, in the wake of the Dotcom bubble bursting and the collapse of big corporations such as Enron. Aimed at improving the accuracy and transparency of financial reporting, it also helped to steer software development in a different direction within the OEM I was working for at that time.

Proof of Concept

Before this, it was typical for engineers working alone to develop their own code, fix the bugs, then deploy it into production. But SOX really pushed people to a different way of working, where you had to have different steps in the process and you could no longer do everything by yourself – tasks were broken down and shared within the team; nobody was working in isolation anymore, and progress updates were made far more often. This was good grounding for what would be formally launched within the company later as Agile.

The formal implementation of Agile signalled a step-change in our ways of working. Until then, software development, like the engineering of hardware and, and, above that, the entire vehicle programme, was run using the traditional Waterfall method, where everything was defined and documented before any work started, with all of the gates and milestones, from kick-off through to start of production.

Going from phases measured in months to planning for what’s coming in the next sprint, typically four to six weeks in Agile, gave us much more flexibility to prioritise what was most important in the here and now. It also gave us great opportunities to figure out that some features and functions would never be used by the end customer and were just waste from a project perspective.

Rules of the game

The value of Agile development was proven again when a colleague moved to the gaming industry: contrasting the way of working there with what he was used to, he said it seemed inconceivable to decide at the beginning when everything should be done, where and how – even though you hadn’t even started. In other words, that you should know exactly how you were going to end the game before you’d even started to create it: that would’ve been devastating to development. In other words, Agile gives you a completely different level of creativity and enables you to think much more about how to keep the software up to date.

Agile also changed how his company tested the code because when you have the freedom to make a lot more changes, there’s the risk that you can introduce more bugs. Games are built up in many different pieces, and every team working on a game – there might be 10, for example – had its own branch. So they learnt to merge everything into one code branch each night. Difficult at first, for sure, but it showed them exactly where the problems were so they could start to solve them much sooner. Companies working on music streaming platforms work in much the same way.

At ECARX, we develop everything within the digital cockpit computing platform, or the vehicle mind as we refer to it – hardware, software and the operating system – and this work is coordinated across 10 R&D centres worldwide. This level of in-house capability gives us a lot of advantages, and every project which has a software element is managed within our Agile ecosystem. Benchmarking from those other industries brought a lot of invaluable learning into our business.

Some people say you can’t compare Spotify to the car industry – of course you can. The way of working is fundamentally the same; it’s just a different product. You have a start, and a stop, and you want to keep the software up to date at all times. Of course, a car is a much more complex product, and so we’re not quite at the same level of Agile, but we’re working towards it, and if we can get to that we’ll have achieved something really outstanding.

There are still challenges, however, although some of our OEM customers are very far ahead when it comes to software-driven development, and some have created their own separate companies to take care of all of the software development. Others are much more traditional, and the level of Agile working can be on a very different level – this can lead to issues.

Timing is everything

The biggest clash we see is that when you work a purely Agile software-driven company you can run up against the vehicle programme milestones. Which we do quite a lot. So what would really help - for the industry, not just for ECARX – is just sharing more about the whole plan right at the start. Then we and the other suppliers can better plan our development work. That sounds really simple but right now, there are some programmes where we are effectively working blind: we don’t know when the OEM is going to do homologation, for example, or what exactly the test plans are for hot and cold weather testing.

Others are much more specific: they’ll ask us to do something now because we’ll need it next week. Agile working just gives you so much more flexibility, and you can adapt accordingly. When you’re not in that mindset, you’re back to the Waterfall approach where everything has to be done at a certain time, and that’s usually when the product is ‘done’ – i.e. start of production – but product evolution in the software domain is never over. And with the leading OEMs working towards delivering truly software-defined vehicles, the amount of software development will just explode in the coming years and you have to be Agile to manage that.

So coming back to the plans, if we know all of the timings, then we can agree that, up to start-of-production we’ll have a certain level of software, and then we can properly plan to reflash a later level of software once the vehicles are shipped to market. But, this is easier to say than to get it to happen.

Some OEMs still want everything done by start-of-production. But then you can have problems on the line with software downloads exceeding the cycle times allowed, so they ask for pre-installation in the head units. But invariably, this software is out of date when the components are delivered to the plant. So you still have to plan for re-flashes anyway. Others want as little software installation in the plant as possible because they see this as inefficient: they want the software installed when the car reaches the harbour in the country it’s going to be sold in. This gives much greater flexibility to the OEM as well as to us, and that’s before the later roll-out of further updates over-the-air once the vehicles have been sold.

Redefining the future

Further advances in infotainment and connectivity, together with increasing levels of autonomous driving capability, will bring a level of complexity that OEMs and their supplier partners must work together very closely in order to manage. At the same time, there may be changes to come in the way those relationships function, driven by new players in the automotive industry.

In the past, a lot of the sourcing decisions were based purely on product specification, timing, and cost. But now with suppliers coming from other sectors into automotive with technologies that the OEMs want, it can be those suppliers who determine how things will be done. And then there are companies who might only work with those suppliers, and if an OEM doesn’t already have them on board, then they might say that they’re not interested.

The software-driven world is changing everything, and we’ll all have to meet those challenges together – it’s going to be fascinating. 

For more information on how ECARX is helping OEMs build software services from the ground up, visit our dedicated Software Services page.