Agile engineering

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: 

  1. Map existing processes
  2. Identify major issues and bottlenecks
  3. Co-create new ways of working
  4. 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.


Lukáš Kálal, Head of Engineering Design & Services CZ/IN, REHAU

Jakub Gurecký, Internal Agile Coach, REHAU

Fixed price contract for R&D project? Highway to failure

Sometimes, no matter how exceptionally you do, a development project fails. And even if you apply the best practices in this area. Whether you are customer or supplier, a fixed-price contract most likely sends you on the highway to failure.

Tension source

Customers need effective and user-friendly product or servie. Suppliers want to build it. But in most cases they both fail. And it does not matter what domain we are talking about.

Do you create marketing strategy for your client? Do you develop new weather sensors? Or do you build software? Watch out – your project will most likely fail – at least statistically.

There are many factors causing this failure, but one of the main root causes is the contract – an interface between the customer and the supplier. Everything starts there, and at the end of the day it is the contract that is evaluated. Let’s take a closer look at what is the evil of fixed-all contracts that we sign nowadays and what is the way out.

Most development projects fail

Let’s take look at software development area since all the risks and problems are visible here. The alarming fact is that the success-probability of Software Development (SWD) projects is pretty lousy. It is about 37% according to the Standish Group [Chaos report 2010, 2012, 2014, 2017]. Does it mean that IT guys are silly or not competent? No, the problem is that we use inappropriate tools and methods for such a task. Most customers and suppliers approach software development the same way as making products (houses, cars, phones). But the fact of the matter is that it is not the same. Let’s take a look why.


As you can see in the picture above, chances of repeatability and reuse of knowledge while designing custom software is much lower as compared to building a car.

Approaching them similarly would be like making the Apollo program (man on the Moon), comprising of research and brand new technologies, in the Waterfall way – describe, design, build just one rocket for the first time and on the release date launch its crew to the Moon. I am convinced this has all possibilities of being a disaster. It was the 11th Apollo mission which finally landed on the Moon with the people onboard. Imagine how many millions try-fail-learn loops needed to be done with the module prototypes and subsystems before they eventually succeeded.

Success in these creative/innovative industries, where SWD belongs, requires quick learn-adapt loops in order to build something as complex as a software based on customer needs. The problem is that we approach it like it was predictable. We try to fix everything inside the contract in the moment when we actually miss critical knowledge.

House of your dreams

house of dreamsNeedless to say, it is very difficult to define these customer requirements. And often these really critical requirements are even missing.

If we ask people “Imagine your dream house… everything is possible… what would you like to have in it?” We usually get answers like a swimming pool, a big television, self-cleaning, big living room, etc. But no one says roof, walls or windows! Have you ever wondered why? Because it is obvious that every house has those. Each architect should know it right? And now imagine a customer refusing to accept software because it is obvious that each banking system must also take care of invoicing which was not mentioned in the requirements. Business analyst should have known that…

Mary had a little lamb

mary had a little lambAnd 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 “Mary had a little lamb” rhyme? If we take it out of context – which requirements usually are – what does this sentence actually mean?

  • Did Mary take care of her pet lamb?
  • Did she eat a whole little lamb?
  • Did she eat a small portion of lamb?
  • Did she give birth to a lamb?
  • Did she have a sex with a lamb?
  • Did she trick a naive individual of no consequence? (stock broker’s slang)

As you can see, the requirement sentence can be interpreted in many different ways. Even the ones you would never believe. Imagine thousands of sentences written inside a requirement specification document. Does a reader see the same resulting product/service as the requirements writer?

Why fixed-all contracts then?

So if we…

  • need to apply learn/adapt loops that change functionality during product creation
  • cannot define clear requirements upfront
  • cannot understand them properly
  • and thus cannot estimate them

…why do we still use contracts that are trying to estimate and fix everything upfront? Scope, time and price at the same time? I suppose that’s because people who make these contracts do not realize these specifics of R&D projects, or simply they do not know any better alternative. But this restrictive contract has very negative consequences.

cage bars lock closed fixed contract birdImagine 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.

It is no surprise that we cannot predict the future and there are always nasty surprises waiting on the way – such as changing needs, technical difficulties and wrong assumptions. This happens especially when contract and estimates are forced very early, in project phase where we do not have much information. Also this restrictiveness introduces barriers into the customer-supplier relationship which precludes them from applying the most important universal practice – continuous improvement. Barriers make learning loops longer and inefficient.

Agile/Lean contract

air freedom options mountains sky free people man personSo 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.

What should be written in the contract then? Definitely a description of the process, how supplier with customer’s support is going to produce best possible result. We put there all the patterns we know that empirically work. What does it mean in practice? Long story short it should contain the following parts:

Process of production based on learn-adapt loops (iterations) including all project phases

  • Release preparation (vision, business objectives, major acceptance criteria, high level tests)
  • Release execution (iterations and partial acceptance)
  • Release delivery (deadlines, acceptance)

Supplier responsibilities

  • Cooperate to formulate requirements from user perspective
  • Commit to iteration input and have it ready for Demo

Customer responsibilities, where customer has to be present and for how long

  • Help to prepare iteration input
  • Support development within iteration
  • Attend Demo and accept/refuse produced solution increment

Learn adapt parts

  • Have common regular retrospectives to prevent issues
  • In case iteration fails, or there is significant negative feedback from customer – trigger special retrospective with customer

Consequences of not following the agreed process

  • Customer does not attend the demo? All demo functionality is accepted by default.
  • Any errors discovered? They have to be fixed in very next iteration by supplier.

Business model

  • What to pay for (capacity, per iterations, per requirement, per StoryPoint, …)
  • Bonuses and penalties

As you can see this kind of contract is then always unique since it reflects concrete capabilities and constraints of concrete partners, so it does not fit all. But the parts and ideas there can be easily reused.
We managed to develop and sign a couple of these contracts with different customers of our clients. And according to the results and feedback it really works! One of the examples was presented on couple of conferences already (e.g. Leanest 2012, 2013 conferences in Stockholm and Prague).

Let us know if you are interested in hearing more, we will gladly share what we have learnt.