We recently got the chance to talk with the Head of strategic delivery and operations at Bamboo Apps, Alexander Antonuk. Alexander has overseen projects for a great number of big name clients, including Rinspeed, Škoda, Mitsubishi Electric, and Jaguar Land Rover.
We discussed the viability of Agile practices in big automotive companies and projects, the challenges associated with their implementation, and the best strategies for integrating the approach on all corporate levels.
The following is an edited transcript of our interview.
Today we’ll talk about Agile development in automotive projects. I’d like to start with the question of scaling Agile practices, since you already have experience in working on development projects in the automotive sector. Could you please share your experience of scaling Agile in large enterprises? Maybe some challenges you had to overcome?
In big companies, any scaling begins with a kind of trial. For example, they take one team from a particular project, maybe not a very big team, and use it to test Agile approaches. They see what works and what doesn’t before starting to scale.
That was our situation at first. We had a project for a famous European OEM [later referred to as the OEM], where we had a team of about 25 people working on a specific product, two mobile apps. It was a sort of starting point at the OEM, with our guys utilising Agile – or Scrum, to be more specific. It went on like that for a couple of years.
After a certain point the management of the OEM started to shift their business strategy.
“They realised they had to be more flexible and listen to their customers more closely. The company needed to change something within itself to give people a relevant product.”
Internal transformation was kicked off when the guys decided our team won’t be the only one working with Agile. They wanted to spread it to other adjacent departments that worked on software and hardware, so they began to integrate Scrum in other teams.
Eventually, when several teams had switched to Scrum, the company decided to go for a tried-and-true framework – SAFe, or Scaled Agile Framework. It organises the work of multiple Agile teams in a way that ensures they produce deliverables within certain timeframes, while aligning everything with the business goal of the enterprise.
SAFe starts from top management and follows a chain down to the team level. We couldn’t know what was going on at the top exactly, but we felt that all of them had begun to gain an understanding. Before our team was an outlier, but now a common strategy began to emerge across the whole company.
Moreover, the company started to coordinate delivery plans and inform teams about their current business goals. We held so-called Program Increment (PI) planning meetings. These were usually 2-3 day sessions where a lot of people and teams received input from the management and heard what the company wanted to achieve in the next 3 months, planning that timeframe accordingly. So our SAFe progressed in 12-week increments.
They conveyed that information to us, after which the planning took place within individual teams based on the stated goals. There were a bunch of different teams: there was ours, which was responsible for mobile apps, there was the backend team, and other adjacent ones.
“We weren’t alone anymore, we received inputs from the top all together and on the same day. If before we were flying solo, now we regularly took part in huge product events with stakeholders. They knew what we would be doing, we knew why we would be doing it.”
After the planning was done, everyone worked as usual for the next three months. That meant two-week sprints, bi-weekly demos, and so on. So PI planning was the main artefact brought to us by SAFe.
And the top began to prioritise based on that planning. For them it was a kind of push to review their goals every three months, considering how trends never stand still in the Automotive industry.
Do you know why the management came to the decision of broadening this practice to the whole company? Did you play a part in pushing the idea?
Bamboo wasn’t the only party involved, we supplied around 17 people, and the client had their own team members, too. Plus all the product management was on the client side. Together we were a single, standalone team that worked following the Agile methodology.
From what I heard back then, the OEM used us as testing grounds for Agile practices. They told us how impressed they were with our work and wanted to spread this approach to the entire company.
New people appeared, the teams were expanded. Instead of the former two teams working on one product, we became five. Our collaboration with the backend team became tighter. Before we worked in a somewhat isolated manner: they did something for us, then we received that deliverable and worked with it.
But now we started to collaborate more closely. We basically got access to other teams, since they also started working in the same style.
And which of the practices the company implemented to broaden the Agile methodology seemed the most effective to you?
Well, again, PI planning can be highlighted as its own separate thing. It has a couple of components: transparency between the management and the teams in terms of corporate strategy and the ability for anyone to raise a question to the management, propose something.
“It’s a collaborative session of sorts. And there is a lot of value in that, because the team, the developer feels like they’re part of something big and important. It’s awesome.”
The second is the system demo. That was a demo held every 3 months, where a large group of people gathered to see what all the different teams had done for the project. Before, our two teams used to just show each other the demo at the end of each sprint – and that was that. But here it was more global.
This was part of the Agile Release Train, or ART for short. It’s when a long-lived team of Agile teams incrementally develops, delivers, and operates one or more solutions in a value stream. So now all the teams working on the solution were on the same “release train”, with the same cadence of sprints and plans. We became more synchronised.
It was also in part thanks to the so-called Team of Teams. This is when the representatives of each team (Product Manager and Agile Coach) gather on a weekly call and talk about their blockers. For example, one team does the interface for the car fueling, another does the My Account section, and so on. All of those people share their current status and can immediately ask for input from another team if necessary.
You’ve just answered the question I was going to ask about organising cross-functional collaboration between different departments. You know, setting up communication, knowledge sharing.
Yes, that just about answers that question.
There’s one more good thing SAFe gave us I want to note. It aligned our delivery timelines. So now teams working the Agile Release Train, that is, teams working on the mobile app and the backend, had the same start and end points to their operations. If we all started our PI period on Monday, we all ended it on Monday three months later.
And we considered all of the dependencies between our teams during planning. For example, the backend would deliver certain functionality in sprint number three, meaning we would be able to begin working on it a little later.
This alignment of timelines and milestones really helps with setting up a delivery period.
So everything is built on good communication.
All on communication, yes. But behind all that is a strong decision from the management, a kind of, “Okay, guys, let’s all gather together and make a plan. Let’s work at the same tempo and in the same direction, without everyone being all over the map.”
Then let’s continue the topic of communication a bit. Not with the team, but with the client. How do you make it so that the client actively participates in the process and provides feedback throughout the whole development?
The ideal option is when the client attends daily team standups. But obviously, not all clients are ready to invest their time into that, they have other tasks. They gave us money to do something and they want to see the result.
In that case we suggest at least attending a weekly or a bi-weekly call, where we could share updates on the project: dependencies status, what has been achieved over the last period, if we need anything extra from the client. We call it “governance call”. That’s when we can also discuss the budget, if the situation demands it.
Another important moment is us making a demo for the client at the end of every iteration, so that they see what we did exactly. For example, a demo of the feature we developed in those 2 weeks. A representative of the client’s management has to attend this demo (whether it’s upper or lower is for them to decide), because that’s who we’re making the project for.
A developer, a designer, or a tester shows them the fruit of their labour via screen sharing, launching an emulator, and demonstrating how the application works at that point in time. We share a visual result of what we’ve done. We also share what we haven’t managed to do – those tasks carry over to the next sprint.
“Demonstration is a very important thing, because the client can provide immediate feedback. Then we’ll take note of it, and add it to the next iteration. And the client will see that their money isn’t wasted, that the team is actually doing its work. So this kind of communication is crucial.”
Plus it’s an opportunity for the team to once again highlight the fact we’re expecting certain information from the client, which is halting our progress. We can point to it. Like, see, we don’t have anything displayed here yet, because we’re still waiting for you to give us the necessary information.
I see. Then let’s do a segue from clients to client requirements. The quality of crucial safety systems is an extremely important point in big – really, any – automotive projects. What do we need to consider in order to find the right balance between development speed and following all the necessary security standards?
First of all, the team of Bamboo Apps closely follows the ISO 27001 ISMS standard, and is certified accordingly. We also use the recommendations of ISO 26262 as a basis, in particular its Part 6 – Product development at the software level.
Right at the start of the project, we determine where and how different information will be stored together with the client. For example, whether we will use our or the client’s repository, if files will be stored on our servers or the client’s. More often than not, big clients prefer to store everything on their side, following our recommendations on where to do it.
We preemptively assess some other necessary services, such as libraries and API, internally. We use libraries because they reduce development time, you don’t need to do everything from scratch.
Let’s say we want to use a library to develop an authentication feature. It undergoes a review from our CTO. As in, our iOS and Android guys discuss the library between each other and pass it to the CTO for approval or disapproval based on how trustworthy it is. So we don’t just pull something off the internet and integrate it.
If the client has preferences of their own, big ones usually hold an audit at their own security department. Or they can come to us. “I’d like to use this library to add authorisation, could you please take a look at it?” Then our tech lead or even CTO joins in and gives his final verdict.
So this is more about cybersecurity, data. And what about the development of vehicle systems, where maximum quality is very important? Could you suggest some strategies for equating the speed and quality of delivery in Agile without accumulating too much technical debt?
I think the so-called pre-development phase plays a big role at the initial stage of the project. That’s when our tech team representatives, like the CTO or the Tech Lead, develop the solution architecture, as well as choose and agree on an appropriate tech stack. It’s applicable to all kinds of products: mobile, web, backend.
We develop the architecture first and decide which third-party services will be used there, so that we don’t suddenly realise we need to rework things or that something is unsafe late in production.
“Basically, you need to use solutions that have already proven themselves to the industry. It may not be the hottest new thing, but people and companies across the world trust it and use it.”
That’s point one.
Next we of course use code review during development. Every time a developer writes a piece of code, another developer checks it. So there’s always a review by at least one other pair of eyes.
On top of that, we employ uninterrupted iterative testing throughout the whole development process. Each development iteration includes the testing of all the newly made features. And a couple iterations later, we also do regression testing to double check that the functionality developed earlier is still working as it should.
Additionally, we always offer our clients test automation services, getting maximum code coverage with a maximum number of automated tests whenever appropriate. This allows us to perform non-stop tests automatically.
All these approaches help us get rid of a lot of bugs which may appear during the production stage, which is critical for automotive development. That’s point two.
Point three. This doesn’t completely dissolve technical debt, since we do occasionally delay things for later to prioritise speed. So during estimation we add a time gap for the stabilisation and bug fixing phase. If we know we can omit certain things at the moment, we put them off until the end of the project. And then we can begin to cover the technical debt and bugs when we have free time.
And point four. We give developers the right to make independent decisions, but if they have any doubts, the whole technical team will gather and give feedback about the choice of some library or service. When the feedback has been collected, we hold a kind of vote, where we choose which technology will be best to use.
So it’s not a subjective choice of just one person, but of several colleagues, some of which may be more experienced.
And what if the company is working on a project and its scale suddenly changes? How do you adapt to this turn of events? For example, the client suddenly writes to you, “We’ve decided to upscale the app and add the following array of features”. How do you adapt to such an abrupt change in the amount of necessary resources, the shift in timelines?
Yes, of course any request for scaling can affect the project drastically.
Let’s say we’re on the final stage of the project, where we are about to release a quick MVP solution. It’s meant for a small group of people to test and give feedback on, which we would then use to start full-on development. But then the client comes and says that we need to redo everything and make a fully-fledged product.
First of all, you need to cool down and ask the client what they want to achieve with this scaling decision. Why are they doing it now? What’s the goal? What number of users are you aiming for, 100 thousand or a million? Once we know that, our technical team can think through how much effort will be required to bring the project to that state.
There are two paths here. We may decide that it’s better to release the current MVP as is instead of reworking it. It’s already finished, at this point it will be easier to write things from scratch. We can then agree to release the MVP as was originally planned, and start working on the full scalable product on a separate track.
Again, we will build its architecture to be scalable and to support a huge number of users. We estimate the effort and time necessary for it with the client, decide which functionality we should add to it, and gather a team accordingly.
After all, these kinds of changes can completely change the stack. Maybe the client realised they don’t want a simple backend on Firebase, but a .NET solution. This completely changes the team’s composition. So it’s best to separate the projects.
If the changes are insignificant, for example, if we’re already using a scalable enough approach on the MVP, we can just broaden certain parts of it. This might not even take a lot of time.
“The first thing you need to do is know the client’s reasons for scaling. Because they might talk about scaling, but in reality everything they need can be achieved with small modifications on our end.”
Of course this will extend timelines regardless. So we offer the client to at least release some working part of the product and then continue to scale and tweak it until it meets the new requirements.
Let’s go back a bit to the question of balancing quality and quality in general. What KPI would you say are especially useful on automotive projects, aside from the typical Agile metrics?
Well, of course there’s the number of defects. How many defects there were, how many there are now. Let’s say, roughly speaking, we carry out the first regression testing, and see we got 20 bugs, then 30 on the second, 40 on the third. So the number of bugs keeps increasing. This rings an alarm bell: we’re probably doing something wrong, perhaps the code is not very good.
When you have a lot of different teams, there’s also a velocity metric. Ideally, it should always increase, because as the project matures, the team should be able to cover more tasks within one sprint. But it can’t always be like that, because there’s this thing called external factors.
“If we’re tracking velocity and see that it regularly dips or falls, we need to look for the factors at play. Those can be particular teams or the lack of people due to the project becoming more and more complex with every iteration. And if the project becomes harder and harder for developers, the quality of code can also decrease.”
There’s one other metric. You can launch automated tests and see how many of them crash. The more of them crash, the bigger the sign that something is off with your development. So if the project has integrated automated tests, don’t forget to ensure that the number of crashing tests constantly reduces.
Maybe there was a particular case where analysing metrics like that helped you out? Like you saw that something was off, analysed it, fixed it accordingly, and the project went on a lot smoother.
We had a moment like that in a sense.
A new iteration starts, a new sprint. We’re planning work for the team and don’t take on more than the team can do based on previous metrics. But even so, by the end of the iteration we fail to finish everything and this continues for several iterations in a row.
Of course that’s a sign to at least talk to the team during the retrospective, to highlight this moment. Why can’t we finish the scope we’d completed before in the same time frame? There can be a ton of reasons: team exhaustion, being very dependent on other teams, which don’t give us something we need on time, or a lack of testers, for example.
It was a real case, by the way. We kept butting into our 5 teams having only 2 testers, and those testers were also involved in the client’s other activities. Developers did their work, but tasks were taken into testing only by the end of each sprint, because the testers didn’t have any time prior.
Basically, the developer had completed the task way in advance, but received feedback on it a lot later. As a result, the task had to be finished at the start of the next sprint. Things became desynchronised.
Once this issue became known, we got more testers to help us with it, and it sped up the development process a fair bit.
How has Agile changed, if at all, over the course of your work at Bamboo Apps?
For me, scaling became the main criteria, that is, the appearance of scaled Agile. I’ve already mentioned SAFe, but there are other scaled Agile frameworks, such as LeSS, Agile at Scale, and so on. And this idea started to get integrated into enterprises right before our eyes.
If before we were like, “Let’s do this with Agile,” and they responded, “Eh, do as you please,” then now they ask for it themselves. The client can come to us and say, “Yes, we’re a big, large company, but we already know how to work with this”.
“Big clients have gained more awareness. We don’t need to spoon-feed who does what to them, because they already know from their own company experience.”
Scaled Agile has existed for quite some time, but big companies started to actively integrate it within themselves only in the past 2-3 years.
If we’re talking about Automotive, which isn’t the most cutting-edge, they’ve only started coming around to it now, and it’s happening in front of our eyes, and this topic is being boosted. When we offered things like that before, it wasn’t taken too seriously.
So the industry has woken up a bit.
Yeah, yeah. Exactly.
And can you tell us what can be done to ensure that Agile practices don’t lose their relevance and adapt to the modern market and technologies?
First of all, you should ask the following question in regards to any practice: are we doing this because it says we should or because the team really benefits from it? You should always apply specific approaches based on the needs of the team and project.
“That’s the whole point of Agile, that you don’t need to copy everything from the textbook. You’re supposed to take and adapt the things relevant to your team. There’s no shame in ditching things that most of your team consider unnecessary. ”
And there’s no shame in acknowledging your mistakes. “We’ve always done it that way, so we’ll keep doing it that way,” don’t be like that. If you did something before and realised it didn’t work, don’t be shy, change it or throw it away.
At the end of the day you always have a team you communicate with. That’s what retrospectives are for, where we decide what’s good for us and what isn’t. This is the second factor – it’s important to adapt approaches to the team.
Of course, monitoring the industry remains a truism. There’s a lot of information these days in the form of Youtube videos, articles, and analytical articles, where you can learn which practices are currently gaining traction in the industry.
But again, refer to my first point, always think how applicable that is to your team. Because that’s who we do it for first and foremost, the team and the client. If the team is happy, the client will be happy too. So everything should be applicable not just on paper, but in real life.
In general, management support plays a big part in whether Agile works or not. If the client is a corporation, support from its top management or at least some stakeholders is very important. So that they understand how it works and don’t reject certain practices. Then everyone feels comfortable and understands they’re working using methods everyone is familiar with.
Maybe you’d like to add something about Agile as a conclusion?
This may be an obvious thing, but Agile is first of all designed to get feedback from the client. As in we make something, get feedback from the client, and return it to the team.
But that’s just one side of Agile. The other side is also getting feedback from the team in just the same way. So Agile is not just done for brownie points, these are in fact practical approaches that help improve the atmosphere and speed of delivery within a team. And outside the team, they help deliver the value the client needs.
So I’d say that Agile is not about clear written rules, but about flexibility of thought and adaptability. It’s about everyone being comfortable, flexible, and always able to replay or play something back. Agile gives the opportunity and right to change things mid-game.
About Bamboo Apps
Bamboo Apps delivers cutting-edge solutions for the Automotive sector from one of Europe’s brightest innovation hubs, Tallinn, Estonia. The team excels in HMI design, car connectivity, shared mobility, and automotive ML technologies.
Bamboo Apps’ commitment to excellence has been recognised by major OEMs and Tier-1 suppliers, including Mitsubishi Electric, Škoda Auto, Jaguar Land Rover, Rinspeed, Osram, Gentherm, and others.
