“It is they who drive the transformation of companies and industries: courageous lateral thinkers, risk-takers who are different and visionaries. Every change, every innovation needs people who think beyond borders, question the status quo and convince others of their ideas. We call them thought leaders, rebels, or drivers“so Haufe in the invitation to the latest blog parade with the hashtag organizational rebels. I would like to participate in this and have set myself to answer the following questions on this topic:
- What are my very personal experiences in my life as a rebel?
- What best practices can I share – and what have been my biggest mistakes that others can learn from?
In the first step I would like to tell my very personal story about a change in which I was involved for a whole year. From this story I derive best practices that can help an organizational rebel in everyday life. The following story happened during the last 3 years in the course of my consulting activity. I don’t want to give any time periods because the company is supposed to remain anonymous. In the following, some details have been changed so that the company cannot be traced. Hired as a consultant, I found myself there in an environment of tradition and change.
Reading tip: SMEs between tradition and change
My very personal experiences
One day I received an exciting project. I was supposed to support a company for a year, to restructure a department and, in addition to consulting, also tackle the change with management and employees.
From one day to the next to a rebel
Change is difficult – hardly anyone likes it. Especially not in a group with fixed structures. But changes are essential to move a company forward. So I was called by a company to restructure a department with almost 100 employees. In 50 percent of my time, I helped the managers responsible to change the organization – the other 50 percent I took on important projects using agile methods. So I had come to change something – an organizational rebel – which perhaps not all employees received with open arms at first.
Planning, planning, planning and shut up
A very well-known agile mind and book author once gave me the tip a few years ago: “If you come in somewhere new, shut up and take a close look at everything.“That’s exactly what I did. In the first few weeks I was busy getting used to it, understanding processes and getting the seniors to explain the company to me. Together with the manager and his team leaders, we met regularly for one-day workshops on planning the new department. Especially at the beginning I listened carefully. I didn’t bring my own ideas to the table, but rather thought about how I can put the manager’s visions into concrete terms. Before I came up with an idea, I usually discussed it personally with one of the team leaders. By the way, if you want to read some theory, you can click on my article on organizational development.
Reading tip: Organizational development
The target image was created!
After a while, we had defined the target image for the department. We had to observe the following framework conditions:
- Compliant with the certified standard
- Compliant with processes in other departments
- Lots of people who don’t all want to work in an agile manner
- Different customers, not all of whom were enthusiastic about agility either
- highest flexibility with maximum stability
There were currently very large teams in the company that worked according to traditional methods. This should be changed. We had the idea to appoint two new team leaders and to form four teams from two teams. These are:
- Internal IT: automation and operation – Kanban
- Project team – large customer projects – complete self-organization and autonomy
- DevOPs: For medium-sized projects and agile (Scrum) customers – Scrum and DevOps
- Classic unit: small customers and customers with standard tasks – ITIL
Challenge accepted! To do this, we came up with a four-step model. Some of the employees were supposed to continue to work in the old organization, the other part slowly moved with the customers. It was important to us that the stability of the department was maintained. I created a graphic for this – I will go into the individual phases in more detail later. To explain: DevOps is an artificial word that is made up of the words Development and Operations.
With full force against the wall
After a few weeks I got into my first project, which I was supposed to do in 50 percent of my time. I was a project manager for a large client. There was a program manager above me and two sub-project managers below me. So I did what I had learned in the target picture and organized this project as agile as I could.
One aspect of this agility was to give the sub-project managers a high degree of freedom and autonomy in their task execution and to keep their backs free as Scrum Masters. I also saw myself more like a lawyer in front of the client and the program management. Unfortunately, it only occurred to me too late that my project was completely out of line with the ITIL-oriented line of the program and, despite its success, was perceived by the program manager as uncontrollable and chaotic. ITIL is a way of organizing IT and is often not easy to combine with agile methods.
Better: Unfortunately, it wasn’t until much too late that I realized that two worlds were colliding. Agility paired with an ITIL-oriented line of the program let my project step out of line. Despite the success, the program manager perceived the change as uncontrollable and chaotic.
In order to protect his project, after three months I was suddenly allowed to put on my hat and “go” – the unit was again organized in the classic way. So I did it! I was kicked out of my first project after three months. Fortunately, the manager of my department was behind me and decided to just give me a new project. There was just me as a project manager and a team. The predecessor should train me. By the way, if you want to read more about the establishment of Scrum in traditional companies, then I have a free whitepaper for you here!
Reading tip: Agile in the Waterfallworld
Networking can help – the Change Board
However, two months passed between the old and the new project and I was able to devote myself to the change. After I got home quite early on the day of the exclusion, I was in the office all the earlier the next day. I used the next time to have a short one-on-one conversation of 15 minutes with 40 of the 60 employees and made notes. I formed clusters and had roughly summarized the wishes and suggestions of the department at a glance for the manager. Now we formed the change board, which consisted of the following types of employees:
- Strong skeptic against change
- Knows a lot of people
- Is very committed and has lots of ideas
- Team leader of other departments
At the first attempt, we presented a plan to the change board and the new teams. Together with the board, we filled a backlog with tasks. A sprint took place every two weeks and every employee was allowed to take tasks from the change board. Each of the ten participants helped. Team leaders from related departments were invited to provide feedback. After four sprints, we had completed all preparations and could start the change. Each phase was represented by exactly four sprints of two months each.
With a new approach and classic methods
Now I started my new project, which I was supposed to carry out alongside the change. It was another big customer with an innovative technology stack. This time I adopted the same method as the previous one and continued the project in exactly the same way for the time being. I wanted to achieve exactly the status quo. I apparently managed to do this and slowly gained the trust of the team – including that of management. So I devoted 50 percent to change and 50 percent to classic project management.
Persevere and do marketing
Now it was time to persevere and continue the sprints of change. Every week there was a status meeting and every two weeks there was a review and retrospective. Participation in the Change Board was voluntary and I saw my job in motivating people to keep going. We worked our way forward sprint by sprint.
In the course of my project, in addition to the change, I moved more and more from the classic project system to Jira and we carried out the first small sprints. I now had more trust in the company and was slowly able to make the project a little more agile.
Every change also has an end
Every change has to be completed at some point. The first phases were mostly a technical changeover as well as the move to the new offices and the relocation of the employees. Later on, coaching and finding your way around in the new roles came in particular. It was also possible to volunteer for a team. However, the last 25 percent of employees had to be persuaded to switch to the new organization. I accompanied each and every one of them individually and tried to help.
It goes on: After agile comes virtual
Now the change is over and I have to say: It was fun and we all think we did a good job. The change is also officially completed and other departments may follow. I didn’t pack my things afterwards, as might have been expected, but instead took on another mission for the manager: the company set up two new locations. I was supposed to coach the company’s first virtual team, which is spread over three locations. But this should be a topic for a new article.
Conclusion: best practices for the organizational rebel
The change was a lot of fun and I was looking forward to the next task. Now I derive my do’s and don’ts for organizational rebels from my experiences. First and foremost, a change agent should see himself as an advocate of change, i.e. defend it again and again, instead of preaching like a priest. Networking is also important in order to attract the opinion leaders in the company. Furthermore, work should be done on the status quo, because a classically run company will not become Google or Spotify overnight.
It is also important, especially at the beginning, to first listen and gain the trust of the employees. As a rebel, you shouldn’t realize your own ideas, but see what the company management really wants to achieve. Of course, it doesn’t always have to be 100 percent agile. ITIL organizations can also be agile and are very important for certain customer projects. Always remember that you are between tradition and change. Much that rebels want to change may even have guaranteed the success of the last few years.
Let’s get to the Dont’s. It is important not to polarize, but rather to stay in the background. You should also not pursue your own goals, such as wanting to make everything agile. Of course, I wanted to try out the LeSS framework, but that just didn’t make sense for our customers. Incidentally, the LeSS Framework is a method of scaling Scrum. If you want to read more about agile scaling, go to the article here. A change is also not a matter of a few days and takes time. We invested a year in the change. It is also important to pick up all employees and take them with you, otherwise you will lose the opinion leaders of the company and you, like me, will be thrown out of a project. A great saying that I have used again and again in Change is: Grass doesn’t grow if you pull on it. People need time to slowly adapt to the new situation – because the job means securing livelihoods for everyone. I have summarized my findings in the following figure:
