Agility in the Team - Interview with Bernhard Rohrer
Agility in Teams
Bernhard, you agilized the way we work together at your previous employer. Why did you do that?
Well, the turning point was a conversation with a customer. He told me that he probably wouldn't be implementing a project with us anytime soon. He criticized the way we were doing our projects. The projects take too long, are too expensive, the results are rather poor and in general he misses transparency. He said he felt that he was not getting the service he was paying for. He is even more annoyed by the constant «watermelon effect»! The project is reported green from status meeting to status meeting. Until the watermelon falls on the table and then suddenly everything is red. «You must finally become more agile» was the message he gave me.
In the run-up to this conversation, I had already consumed quite a bit of literature on the subject of LEAN management, as well as enjoyed one or two training sessions in the areas of agility, complexity thinking, Scrum and change management. This is the perfect opportunity to try out the concepts in practice, I thought to myself. And the customer wasn't hard to convince of the idea either.
And how did you do that exactly?
At that time, there were three engineers in my team who knew the customer well. I talked to them about our plans and they were immediately taken with the idea, plus they had the right mindset. Looking back, that was probably one of the most important success factors. Together with an experienced Agile coach, we kicked off and named the project «Nordstern», wrote a working agreement and defined the roles. The customer was the product owner, this because the project had many stakeholders on his side and he had the better access to the stakeholders. As the provider, we provided the Scrum Master in return. His main task is to lead his organization and especially his team to excellence. If necessary, he also served internal company processes and cleared any obstacles. We omitted the role of the project manager on the provider side. Any gaps were filled by the Scrum Master.
It seems important to me: During the setup we made sure that all essential skills were represented in the agile team and were present with at least 60-80% of their workload. Smaller tasks, which required only temporary skills, were added as needed. The project went so well that in a second step we also ensured the operation from this team. For this purpose, we added additional operational staff to the team and supported further customers with this team.
How did this affect the team's performance?
The initial project was completed in half the usual lead time and at 30% less cost. A complete success! In the subsequent operation, after about half a year, the throughput of completed orders was also doubled. Due to the very direct communication and the interdisciplinarity, there were significantly fewer loops and therefore also lower process costs. At the customer interfaces, coordination meetings that had become superfluous could be dissolved.
Have you noticed any other effects on the team?
First of all, it had a positive effect on transparency. It was clear to every team member at all times who had to deliver what and where. This was also beneficial when working with the customer and created more mutual understanding and trust. Direct communication between the customer and the team made us more efficient, as information was no longer lost between order placement and processing. The «silent mail» effect was thus significantly minimized. As a result, there were hardly any management escalations. I was extremely impressed by how the employees developed in a very short time. We had set ourselves the goal of becoming «T-shaped». In other words, to acquire in-depth expertise, both in the specialist area (vertical line of the «T») and beyond (horizontal line of the «T»). Each employee was expected to bring his or her previous, specialized expertise to the team while developing in other areas of expertise. In this way, each team member could complete assignments in rather unfamiliar areas of expertise.
What did you learn from this process of change?
Many things! First of all, that it takes a lot more time and patience to change than you might originally think. In particular, I learned how elements of agile collaboration have a positive impact on performance and collaboration with customers. The pilot team had people, with the right mindset, right from the start. That may have been a lucky punch, too. But every change in the team, be it a new employee, an additional customer or otherwise changed conditions, had to be processed by the team members again.
The subsequent scaling phase was extraordinarily instructive. We wanted to transfer the success of the pilot team to the entire area. A program was set up to complete the agilization of the division by a certain deadline. I still have to smile a little when I say that out loud. In hours of discussions, the core team tried to draw the finished model on the drawing board, assign customers and employees to agile teams, and present the finished solution by a certain date. This was not at all an agile approach for an extremely complex project. On day X, the «new organization» was then communicated to the employees. The employees were only marginally, if at all, involved in the process. From my perspective, the effects of this change were underestimated, and most of the accompanying measures were not implemented. I would invest more in this area in the future and choose an iterative approach.
Now you have a similar task ahead of you with the WaaS product team at isolutions. Will you do everything the same way again?
My previous answer probably already gave it away a little. No, definitely not. Today we work iteratively. That means we test out elements and assess or measure what works well and what doesn't. We involve the employees very early on. We involve the employees very early on. Just as we did in the pilot team. In the end, it has to have positive effects on collaboration, effectiveness and customer satisfaction. And who can judge that better than the employees and the customers? If it has a positive impact on everyday working life and is appreciated and welcomed by the employees, then the change - and I am convinced of this - is much easier.
What performance improvements do you expect from the changeover at isolutions?
To be honest, performance is already very good. As a team, we have set ourselves the goal of providing the best customer experience. Recently, we came across a study that dealt with user satisfaction in terms of IT support. It found that feedback - for cultural reasons - is much worse in the DACH region than in other regions. The main reason, apart from unresolved problems, is that resolution times are too long. In contrast, users are always very satisfied when problems are solved quickly. Speed therefore seems to be an important core element of high customer satisfaction. Some of our customers have also complained that we are sometimes a bit slow. That's why we want to reduce interfaces within the team and keep decision-making paths as short as possible. Here I hope to become the best managed cloud services organization with the highest customer satisfaction in Switzerland through the targeted use of agile elements and principles.
