Agility has become popular across many industries. In IT where it has originated it is de facto standard. However, we also experience many Banks claiming they run more or less successfully an Agile transformation. Let’s hear a story from the Engineering – REHAU.
Briefly about REHAU
Rehau was founded in Germany and has been active in furniture, industry, construction and automotive since 1948. Now it is a global company with more than 20.000 employees. Our first cooperation in the automotive field was VW Beetle. VW group is still our big customer, next to it we supply main premium brands like Porsche, Audi, BMW or Daimler where we deliver mainly painted exterior parts on a polymer basis. We deliver bumpers and other exterior parts just in time and just in sequence in 16 different factories from the Republic of South Africa (RSA) across the whole Europe to the USA. In the Czech Republic, REHAU has an automotive development centre in Cestlice and three production plants in Moravska Trebova, Jevicko and Mlada Boleslav.
In the beginning
REHAU group started its Agile transformation in 2018 to become more flexible, faster with less friction between customers and REHAU teams. Lukas Kalal (Head of Engineering Design & Services CZ/IN, Praha – Ceslice) participated in excellent Agile training in the US which awakened in him a desire to incorporate some Agile principles into our daily work in our factory.
After this inspirational training, we were looking for a partner who would guide us through the topic of agility. We got a clear recommendation that RainFellows should be our first choice.
First step
Any organizational change requires people to change their habits – they make up the real processes of a company. It sounds simple but in reality, you face all possible layers of resistance. Although we are well aware of the problems, we invent thousands of good reasons why we must stick to “old good ways” and everything else is extremely dangerous. It is our core beliefs that create a very powerful fear to change that creates such a strong resistance attitude like:
- “New things always break and are dangerous!”
- “This will never work for us because we are special! (We are not IT, we are a big company, we have rigid customers, we have distributed teams, etc.)”
- “We tried this already in the past and it didn’t work… Name one company where Agile works!”
We often hear reactions like this.
To change something costs energy and brings less stability. People have fear of the unknown – new things. We often forget that our success is based on our ability to adapt.
To change any habit (a.k.a. processes) requires making it conscious first including their negative impact and safely letting people change their core beliefs. That minimizes the level of fear and the layers of resistance as a consequence.
In order to create a safe environment for such reflection and gaining first-hand experience with Agile, we organised a full day Agile workshop. It included a half-day (!) simulation of a traditional project and an invention of Agile. Since it was just “a simulation” and participants even to some extent invented the Agile way of working themselves as a part of it (from that moment on they owned it!), everybody felt more relaxed and open to change in the end. The workshop allowed participants to realise current habits (a.k.a. processes), their negative impact, need for change and let their core beliefs safely change. Once we changed the core belief (e.g. “It’s a new thing and it’s dangerous”), the real change in our organization could happen.
Benefits of initial (“initiation”) workshop:
- People got hands-on Agile experience in a safe environment that allowed them to learn from their mistakes
- Answers to important questions from trustful experts and learning how other companies implemented Agile
- Resistance attitude changed from “it will not work” to “let’s give it a try”
- Ownership of the change moved to people
- Energy and excitement for change
Kaizen workshop
After we let the team process experiences from the first workshop, there was time for the next one. The objectives of the workshop were:
- Map existing processes
- Identify major issues and bottlenecks
- Co-create new ways of working
- Compile an implementation road-map
The whole team participated. Everybody could have their say which created a sense of ownership of the new way of working. It was really great to see everybody’s energy and excitement to contribute. As a result of full-day teamwork we came up with a proposal of Kanban Board, a scheme for items, and a new process around it.
Due to the nature of our work (Engineering), we decided to use the Kanban technique instead of the popular Scrum framework.
Why Kanban:
- Exact specifications from our clients
- Two weeks Sprints would mean an artificial milestone without building an incremental value
- Need for whole process visualization
- Incremental step from the current way
- Kanban suits us better
As a final step we agreed following implementation road-map:
- Ready physical board and presentation to the team (two weeks after the workshop) – collecting feedback, final changes
- First pilot use (after one week)
- Retrospective and improvements (after one month of use)
- Retrospective and improvements with RainFellows (after 6 months)
Implementation of Kanban, Daily stand-ups and Retrospectives
First, we created an environment that wouldn’t stop people’s enthusiasm by not working or missing equipment. We quickly bought magnetic whiteboards and used tape to define the agreed process layout – swimlanes. The whiteboard was equipped by post-its with different colours and magnets. The most important thing was to get started as quickly after the workshop as possible. We knew that the first board wasn’t optimal but everyone was aware that it would evolve and we would optimise it on the go.
We were happy that we made a change pilot team. The pilot team showed the way to the other teams and they were following. Some didn’t accept it at the beginning and considered it a waste of time. But the active ones pulled the rest.
Now everyone shares the same level of information and gets a complete overview of all projects. The speed of decision making has convinced even the sceptical ones. And now we are even helping other departments to start their Kanban Board.
Benefits we observe:
- After few months, we had made a survey. The result surprised us all – it was very positive!
- “An overview” was named by everyone as the top benefit. The same level of information, even workload shared by everyone in the team.
- Easier cooperation and freedom to choose a task were other common answers from the team.
- From an outside perspective having a team spirit definitely increases transparency and the level of shared information across people.
- On top of all of that, the team naturally moved in a self-organising mode without any special steps.
Implementation of Jira
We had a good reason for moving from physical boards to Jira. We had to improve our cooperation with our office in Detroit and our new office in India. Coordinating capacity in far locations without a shared capacity platform costs a lot of communication.
So like with a physical board, we created an environment that was working without any interruption from the start. We studied Jira and tested basic functionality like filters and different card layouts for better work organisation.
We found the Indian team as an optimal pilot for Jira. The brand new small team needed to get onboarded anyway. Why not to show them the new process right away. They accepted it as a part of onboarding, not as a change. We provided one week of personal support in India and let the team test Jira. After this successful test, we did a kick-off meeting in Prague. To keep the possibility of personal meetings we decided to use a projector next to the physical board and we did parallel visual support of our daily meetings. In the second meeting we revealed that everyone was looking at the projector instead of a physical kanban board so we have been using Jira only since then.
Home office
Fortunately, we started with Jira before the forced home office era. In fact, it was just two weeks prior to the pandemic. So it was more an adaptation to the situation. Our meetings are now longer, instead of 5 minutes it takes 30 minutes. Mainly because we need to compensate for isolation and people like to talk about other stuff then issues or capacity.
Benefits of Jira:
- The possibility to add information directly to the card. Having everything in one place and reachable for all team members
- We cannot imagine handling the current situation with anything else than this platform with shared information
- Digital Kanban Board opens the possibility for statistics and show areas where we can improve
Plans for future
We are still in the development phase and there is still a lot to do. We need to study Jira even deeper and also ask more feedback from the team.
On top of that we would like to start cooperation using Jira with our headquarters in Germany and help other departments across the company with this way of cooperation. Later it would be great if we used Jira for all project information without e-mails so the complete information was closely connected to the tasks. Looking more ahead, we would like to e.g. track hours and control the budget according to the Jira report or run projects with our customers in Jira.
Wrap up
Agile was originally invented in IT to successfully manage projects in highly turbulent environments. However, many ideas originated in Toyota’s product development, in the work of the famous Czech entrepreneur Tomas Bata, and many others. Currently our global economy enters an unprecedented situation. We can expect unexpectable events and changes to happen as a consequence. Agility is therefore a logical instrument to successfully drift through high waves of the unknown.
What we have experienced in REHAU is that teams have changed during the transformation: they are more “fresh”, active, self-managed and respond faster.
Co-authors
Lukáš Kálal, Head of Engineering Design & Services CZ/IN, REHAU
Jakub Gurecký, Internal Agile Coach, REHAU
Needless to say, it is very difficult to define these customer requirements. And often these really critical requirements are even missing.
And that is not all. Let’s pretend for a while that we are able to define all the requirements for the product/service. Next obstacle is we simply cannot understand them without ambiguities. Do you know the 
Imagine yourself as a supplier who is bound with a restrictive contract that penalizes deviations from delivery. Imagine things getting more complicated (and they usually do). What will you choose – deliver what is needed and risk penalization or deliver what is exactly prescribed? Most people choose the second option, and there we go – lose-lose situation. The customer does not get what he needs and the supplier is blamed for not delivering it. Rework and error corrections can actually multiply the price of the final solution.
So what shall we do? Simply put, do not contract detailed result requirements. Rather, focus on how both parties, customer and supplier, shall cooperate in order to achieve the best possible result together. This might be a heretical idea to some of the people living in these stories, since common sense says: “If it does not work, we must be even more strict and restrictive”. But being stricter of course does not solve the root cause and just makes the problem worse.