Agile working is quite a buzzword at the moment – how would you explain its principles to a layman?
Alexandra Eicher: In the agile working model, the responsibility for a feature lies with the team. The team decide for themselves how a task should be solved. Decisions aren’t made by the management or larger bodies, as is often the case in other models, which makes a huge difference for me as a feature team member. All feature teams work on the basis of a common task pool – the backlog. Here, all items, i.e. work packages, are collected. We define the content of these packages as a feature team, as we develop the customer function and know which tasks have yet to be solved. In a two-week sprint, we work on these items in our feature team. Before that, we prioritize the tasks together with the product owner, the voice of the customer, in our working model. We start each sprint by discussing which obstacles have to be eliminated and which questions need to be clarified in advance. From my observations, this well-planned procedure means that we can implement our items faster in the feature team because we are not blocked by unknown obstacles ‘suddenly’ coming our way.
If the team is the boss – what does your team look like? How is it composed and who, if not the ‘boss’, ultimately makes the decisions?
In the agile working model, we as a feature team develop the customer functions assigned to us independently. In order for us to be able to make good decisions on our own responsibility, we work together in cross-functional teams, where the team members have different technical backgrounds. For example, in my feature team there are experts from the fields of digital mapping, artificial intelligence, serial development, software architecture, etc. We are no longer organized in separate departments and hierarchies, but work together across departments. This creates a lot of synergies and learning effects for each team member, because everyone contributes their specific technical know-how. This allows us to incorporate many different aspects into our decisions. There is, of course, a need for coordination between the feature teams. We all sit very close to each other on the campus, so it is easy to approach the other teams in person to eliminate any ambiguities or to assign tasks.
Making decisions is always associated with responsibility. Especially when mistakes happen. Who is responsible for you and how does the company deal with mistakes? Do you see them from the perspective of the learning effect?
People learn from their mistakes, and that’s no different with us. When an error occurs, we find ways and means to eliminate it. We are also responsible for this as a team. It seems to me that the new working model, with its cross-functional teams and joint decision-making, will result in fewer – or less serious – mistakes. In addition, our two-week intervals allow us to be aware of this more quickly and to take action. This principle is also used in software development: we often program in pairs or threes on a computer, the so-called Mob programming. As a result, bugs are noticeable earlier and an additional learning effect is created for all programmers involved. But regardless of this, personal responsibility is part of our corporate culture at the BMW Group and can be applied and experienced directly in the agile working model.
Agile teams are said to be able to make decisions more quickly and thus present results faster. What are your experiences with speed?
At the beginning of a sprint we all come together and think about the abilities we need to solve the items and which hurdles may have to be removed. This means that in the sprint itself, we can actually concentrate on development and achieve results more quickly. Again, we benefit from the different competencies in our team. However, speed is not the only reason for using the agile working model: we also need it to master the complexity of our tasks. Autonomous driving is an unprecedented technology that requires thinking beyond one’s own professional boundaries and finding joint solutions with the interface partners from other specialist areas. Our cross-functional team, for example, is a consequence of this. If our team needs additional skills to process an item, we will ask a so-called traveller from another feature team to support us with know-how for a sprint. Conversely, a member from our team can also be requested as a know-how carrier. This exchange creates learning effects on both sides: for the feature team as well as for the traveller.
Apart from fast decision making, what other advantages can an agile team (or structure) offer to a company?
For me as a developer, it means that I can actually concentrate on developing, as I’m no longer engaged in constant coordination loops and meetings. The self-responsible decision about what task is next creates variety, expands individual skills and motivates each of us again and again. Every day, we take responsibility for our work, and we learn about the results of our work every other week. It helps enormously with direct communication and allows us to respond flexibly and quickly to changes and new challenges that come with the complexity of the task. In our ‘daily’, for example, we discuss which appointments are scheduled for the day and how the individual team members split up on the tasks involved. This creates transparency.
Does your team have different spatial requirements? Are your workplaces or even workspaces designed differently?
Our feature team consists of eight members and we are sitting in one common area – our personal workplaces are right next to or opposite each other. Thus, we can communicate really quickly. In addition, we have two team rooms where we hold our ‘daily’, define our items and do our mob programming. Depending on the upcoming tasks, the other team members on the floor can continue to focus on their work without distractions while we use these rooms. We also have so-called Dev Spaces – larger open spaces in which we come together across feature teams, e.g. for working out the next sprint. There are no fixed desks, instead we sit on stools and chairs that can be arranged flexibly to work in small groups. In each room we have large, sometimes mobile whiteboards, which we use to visualize concepts and ideas or to plan our sprints.
Can you see yourself working in a company with strong hierarchies again?
The choice of working model heavily depends on the problem to be solved. The agile working model, as applied in our field, is not used throughout the BMW Group and it certainly wouldn’t make sense everywhere. But others follow our example. If I’ll be working in an area that does not operate according to the agile principle, I’m confident that I’ll be able to adapt. At the moment, however, I enjoy working in a new, innovative working model, helping to launch highly automated driving.
Alexandra Eicher
Alexandra Eicher studied Business Computer Science at the University of Applied Sciences Munich and completed the BMW Fastlane Master’s program. She started her career at the BMW Group as a function developer for partly automated driving (‘Process Chain for Speed Limit Information’). Since March 2019, she has been part of the feature team ‘Chomsky’, developing ‘Adapt Speed’ for highly automated driving.
