1. ENGLISH
  2. News
  3. Stories
  4. 2017
  5. 05
  6. Agile Working at the IT City

We use cookies (our own and those of third parties) to make our websites easier for you to use and to display advertisements in accordance with your browser settings. By continuing to use our websites, you consent to the use of cookies. Please see our Cookie Policy for more information on cookies and information on how you can change your browser's cookie settings: Cookie Policy Accept

Agile Working at the IT City

Volkswagen employees are benefiting from modern approaches to teamwork at the company’s new site

The Scrum Master has spoken. It’s time for the planning meeting, one of the agile rituals. Every fortnight at Volkswagen’s new IT City, Simone Prösch musters a group of Delivery Managers together, seasoned project managers for top IT projects. This ritualistic meeting is part of the “agile working” approach that the department has adopted. As the Scrum Master, Prösch has a specific role to play. She is a Method Coach in a process which has been revolutionizing project and product management since the Noughties, in particular in the area of software development: the scrum. It’s similar to the forward-driving offensive tactic you see in rugby matches. Just a lot more civilized. 

The Method Custodian

An attentive group of Delivery Managers are huddled in a semi-circle in one of the new scrum corners of the IT City. In front is a wall covered in lots of colorful notes, behind is a glass wall, to the right is a large monitor, the area to the left is open and in the middle is a tall, bar-style table – this is the ritual site of the modern worker. The majority of the team members are wearing jeans, a shirt and glasses. You won’t find any ties here. “I’d like to start by making a plea”, Simone Prösch begins, fulfilling her role as Method Custodian. She asks her colleagues who are huddled around the tall table to get even more involved and take on additional tasks on top of their work as Delivery Managers as part of so-called “sprints”. Sprints are timeboxed efforts which, despite their swift-sounding name, last two weeks, during which the team members can work on tasks with complete freedom. 

Managers who aren’t Managers

The Managers who allocate these tasks out amongst them are now stood before them but in a different role. Dagmar Tenfelde-Podehl and Dirk Bisanz do manage the Delivery Managers in terms of the company organigram, but for the purposes of agile working they remove themselves from their roles as managers and adopt a new role according to the rules of the scrum. As Product Owners they assume the technical responsibility for the product. They tell the team WHAT needs to be done and prioritize the tasks. HOW the team completes the tasks is up to the team itself, provided that team members are prepared to take them on. These are not optional topics but integral components of the work. However, there is no pressure exerted on anyone to take on additional responsibilities. The Product Owners also cannot force anyone to accept the “user stories” for the aforementioned tasks. The team takes it upon itself to look at the topics, in accordance with the order of priority set out by the Product Owners, and decides how much capacity it has for them.

There are seven user stories to be allocated today, and as soon as Dagmar Tenfelde presents the first one, up shoots a hand: “I’ll do it.” Check! Next point: “Creation of a Scrum Master Guild”, an association that could appoint its own Scrum Masters without any input from above. “We’ll do that”, say two colleagues without hesitation. Check! Then Dirk Bisanz presents another couple of tasks: “...would anyone be interested?” After just 20 minutes, all the tasks have been allocated, all without any forcefulness or pressure from above. Check! 

The empowered employee

Employees in relaxed meetings quite happily saddling themselves voluntarily with work? This is clearly not a rarity in scrum-style agile working, as team member Ingo Reichelt explains: “This way of working empowers me”, the Delivery Manager says. “It gives me much more of a say in what gets done and how it gets done. We help with the organizing and everyone is always involved.” This new way of dividing up powers, which companies like Google and Facebook have been implementing for a long time already, ensures more creative leeway and greater commitment – and this in turn yields better results.
“The IT City also helps to promote these new ways of working”, says Reichelt: short corridors, lots of potential meeting points and discussion corners, conference rooms that are always available and monitors everywhere. “I like the way that the work and break-out areas are more intertwined here” he says. 

Baking cakes in the kitchen

What he means is areas like the kitchen where Bisanz, Tenfelde and Prösch have just managed to squeeze in a quick discussion with Delivery Manager Christian Hillemann: Who are the right people for an upcoming meeting? The room is flooded with light, has light gray linoleum, a large Ikea-style seating booth, a tall table with bar stools and a sweeping view of fields, a forest and residential areas.

“Being a Product Owner isn’t all that easy”, Bisanz openly admits. Old “managerial interfering tackles and controlling approaches” are not permitted in this role. Once the tasks have been allocated, the matter cannot be discussed again until the next sprint. “But we have noticed that we get brilliant results when we’re prepared to acknowledge that often the employees are the experts and not the Managers”, says an enthusiastic Bisanz. Dividing everything up into smaller sections, sprints and user stories is extremely helpful in that regard. Bisanz likens the classic, longstanding approach to software development to baking a large cake, layer by layer from the bottom up. “With agile working, however, we can focus on a thin slice of cake which we serve up as quickly as possible to the hungry customer, i.e. our user.”  

Between a retreat room and a meeting place

Even beyond the realms of the kitchen, the IT City proves that it was planned with these new ways of working in mind. Retreat rooms provide employees with somewhere to work alone and really concentrate. And instead of the usual printouts, self-made posters full of hand-written post-it notes in bright neon colors hang everywhere between the open, friendly offices – even the two Product Owners’ target agreement is openly on display.

Simone Prösch will soon invite everyone back to this very scrum corner for the “stand-up”. As usual, she will focus in particular on the two values that are the most difficult to abide by in the scrum: “Keeping your focus, and having the courage to speak openly”, says the Scrum Master. 

Agile working at Digital:Lab: “All the people in our teams are equals”

The Volkswagen Group has been operating Digital:Lab in Berlin-Friedrichshain since July 2015. There around 40 Group employees from various specialties and experts from US software specialists Pivotal are currently collaborating on new mobility services and other services relating to networked vehicles. The workforce includes software developers, UX designers, product managers, data scientists, design-thinking experts, and platform developers. They use the same agile working methods as in e.g. Silicon Valley. Stefan Gotthardt is the ambassador for Digital:Lab.

Hi Stefan, Digital:Lab is a classic example of agile working ...

Two points first of all: for a start, as agreed with the Works Council, we have fixed working hours, from 8.30 am to 5 pm. We need that because of our pairing method, which I will explain later. We also have no wish to reinvent the wheel when it comes to the “agile working” methodology we use in our lab, so the colleagues from our partner company Pivotal Labs are currently helping us to import their best practices into our team.

So you use what are called “scrum rituals”. What do they involve?

After breakfast at 8 am, our day begins at 8.30 with our “office standup”. Here we generally spend five minutes going through four general questions: who is new to the team or visiting us, who needs help, what seems interesting and what has happened. Immediately after that is the “team standup”. Here the product teams discuss product-specific questions, who is currently working on what aspect and who is perhaps in difficulties and needs help. After that we begin our day-to-day software development work. On Mondays there is also the “iteration planning meeting”, which is when the team meets up to agree on the new tasks scheduled for the following two weeks – which we call “user stories”. On Fridays each team meets for a “retrospective” to look back over the previous week. This is a constructive dialog where we discuss what went really well, what was average, and what went badly. We aim to become more aware of positive aspects and progress and to address or eliminate things that could be improved.

What are the roles that make up your teams, and why?

Our focus is on the future of mobility, which means that we are currently developing digital services such as native apps and web-based applications. A product team usually consists of from 8 to 12 people with the roles product manager, developer and user experience designer.

At Digital:Lab, two people often sit side by side – how does this “pairing” concept work?

A pairing workstation consists of a computer with a mirrored display, two keyboards and two mice. This is e.g. where two developers work together on the same “piece of code”. One sits in the “driver’s seat”, i.e. has the active role, while the other looks on, makes suggestions and points out any mistakes. This makes for extremely low error rates and hence very high quality software, and always ensures a high level of knowledge transfer. But this arrangement is flexible and used as appropriate – if it does not suit the current task, for instance when research is called for, then the pair can split up for a time.

One noticeable thing at Digital:Lab is the team islands with their partitions and their many colorful post-it notes. What is their function?

Each of our teams is entirely responsible for its own product and organizes itself to a very high degree. They communicate and visualize a great deal, which is where the whiteboards and post-its are helpful. Each of our teams is organized according to the “balanced team” approach. For example, although our product managers are called “manager”, they are not at the head of the team. In our teams, everyone is equal and can contribute their ideas at any time.