Agile leadership - the most common fallacies and best tips

Agile is not a binary state. A person or a team cannot be completely "agile" or "non-agile". Agile does not only manifest itself in action - a Kanban board on the wall does not make an agile team. Rather, agility begins with the much-cited agile mindset, i.e. a certain basic attitude with which things such as collaboration, plannability and processes are viewed. The agile manifesto comprises a series of values and principles that are the cornerstones of an agile mindset. An agile manager is characterised by internalising and living this attitude, for example the focus on simplicity.

Changing ways of working often also change the processes in organisations and the way in which managers are involved. For example, certain meetings can take place without department heads or the board member addresses the workforce directly in town halls. This can give the impression that managers are less important. In our view, this is not the case - rather, management tasks are shifting and new focal points are being added. New or modified processes are therefore often necessary to help managers and their teams with this change. Freedom in the allocation of tasks and self-organised teams instead of rigid regulations are an important lever for processes that promote agility.

Agile working is particularly well described at team level. The fact that certain frameworks such as Scrum introduce additional roles such as Product Owner can be confusing. As a department head or division manager, it is not easy to directly recognise what your own role can contribute to the success of agile work at team level or what to look out for. This makes clear communication and role descriptions all the more important (more on this under tip no. 1). Only if it is clear what team members and managers can expect from each other will the team members have the security they need for self-organised agile work.

As a manager, are you completely convinced of the "agile way" and support every new idea from your team? Kanban, retros, sprints - you try everything out because the future is agile? Actionism can easily arise here and actionism is the opposite of focus. One prerequisite of agile working is to minimise the number of parallel tasks in order to complete the tasks started quickly. This includes not euphorically saying "yes" to everything, but consciously not doing things or not doing them yet. It is therefore better to try out one method first until you know exactly where your team's needs lie and then choose the next suitable element.

Whenever something unplanned happens or a plan is missing, do you motivate your team: "We'll do it in an agile way"? In uncertain and ambiguous situations, acting without a plan is not the best option. On the contrary, you should have already anticipated several possible scenarios. Your task as a manager is to always give the team a clear direction so that good decisions can be made even in uncertain situations. Agility is no excuse for constantly changing direction and lacking a plan.

Scrum, Kanban, SAFe, LeSS or Nexus? And would you prefer Trello, Confluence, Jira or Planner? The question of the right method and the right tool is not fundamentally wrong, but often comes far too early. It's better to start with this question: What do we actually want to do for which internal or external customers? What is the target image of the product we want to work towards? Then comes the question: Which people need to work on it for it to work well? And do we share the vision of what we want to achieve? Once you have worked this out and tried it out, you can ask yourself: don't we need a tool here? And: Do we want to work in sprints (and why) and what do we discuss in between? The method then often emerges of its own accord.

As an agile manager, do you eliminate all problems that could prevent your team from working? That's very laudable, but a cornerstone of agile working is the empowered team. As a manager, you should support your team in all tasks that they cannot solve on their own. However, always make sure that you also empower your team to solve these tasks themselves in the future. If not, the tasks will quickly pile up on you and you will become the bottleneck in the team.

Do you align everything you do with your customers? Do you use tools such as personas, customer journeys and other tools to map out as precisely as possible what their requirements and wishes are (or what you think they are)? But have you ever had a structured dialogue with your customers? One cornerstone of agile working is customer-centricity, another is empiricism. Together, they require the genuine involvement of real customers. You cannot rely on the fact that you are acting in the interests of your customers if you have not asked them. Focusing on empiricism brings you back down to earth and helps you to check the assumptions you have made.

As a manager, you remain responsible for results, i.e. you must ensure that your team members have the necessary skills and know the framework conditions of their role. In terms of competence, take on a coaching role and support your team wherever there are difficulties. You have various tasks when it comes to framework conditions. For example, a product owner can only manage the requirements well if both the overarching goal and the scope for decision-making are completely clear. Defining the overarching goal is your task as a manager, ideally together with your team. It is also your task to clearly negotiate the respective scope for decision-making. In agile frameworks such as Scrum, various new roles are introduced, e.g. the Scrum Master, the Product Owner or, in larger setups, Chapter Leads. The agile roles are assigned individual management tasks that were previously traditionally the collective responsibility of a manager. If you work with such roles in your department, it is advisable to create transparency as to who is responsible for which topics. In this way, you can avoid duplication of work, misunderstandings and possibly frustration if managers knowingly or unknowingly block each other.

Empowered and self-organised teams are an important pillar of agile working. They are based on the conviction that people and interactions are important and that employees know their availability, skills and processes best through daily collaboration. In an agile context, we speak of an empowered team when a typically small team is able to do everything itself for a defined area of responsibility without having to rely on external expertise. Self-organisation in an agile context means that the team has autonomy over finding solutions and the "how?" within a work process. It controls its own workflow. Agile teams act in a self-organised manner within the specifications and guidelines set by management. The Delegation Poker tool is well suited for the visualised and documented negotiation of decision-making scope with your team. Once you have defined the decision-making powers, stick to the agreements and encourage the team or authorised representatives to actually make decisions themselves within the agreed framework. Always ensure that the arrangements made are scrutinised and renegotiated at regular intervals.

Transparency is a cornerstone of all agile working methods. The following principle applies: a lack of transparency leads to unnecessary enquiries or misunderstandings and therefore always to extra work. For you as a manager, this means: Let's get it done, together! Don't hold back with information, but be as open as possible with your team and other teams. If you create a Microsoft Teams board, for example, then regulate the visibility so that everyone within the organisation has read access.

Whether you like it or not, to a certain extent you will always be a role model for your employees' behaviour. If you want agile values such as transparency and openness, focus and clear priorities as well as genuine customer orientation to be practised, you must also represent them credibly yourself:

• By holding regular retrospectives with your managers, you are signalling that it is desired that team leaders also allow time for reflection with their teams.
• If there are boards on which you plan certain milestones in the management circle, make this as transparent as possible. Show employees and managers that you trust them.
• Be a role model for agile values and principles and live the principle of "Inspect & Adapt".
• Communicate openly and encourage open communication and transparency.

In the VUCA world, no plan is irrevocable for years. But you can't work on a huge number of equally important priorities in parallel all the time either. It is therefore important that you, as a divisional or departmental manager, support your team leaders in courageously deprioritising topics. In this way, you emphasise the priority of another topic. If you regularly ask about all topics, it will be more difficult to prioritise them appropriately at other levels. Therefore, create a clear prioritisation list for the entire team that everyone can see and that is always up to date. It is best to involve your team in the development and regularly look at the list in team meetings. Use the MoSCoW prioritisation for this (see diagram). It is important to note that prioritisation means that one topic should be implemented before the others. If all of your topics are under "Must" in the MoSCoW prioritisation or all topics have priority 1, nobody can use this as a guide. In the end, those topics for which there is not enough time - and not those that have been deliberately put on the back burner - are left behind.

By translating the overall strategy for your area into objectives, you help managers and, indirectly, employees to categorise their contribution to the overall success. At the same time, however, you can also hand over the decisions on the organisation of certain options to the next levels. The objectives you specify should describe target states. By also explaining for each objective what added value it creates for which customers, you empower the team to find the best solution themselves. If you are not sure how many targets you want or need to set, discuss this with your managers: Again, a tool like Delegation Poker will help you to jointly determine what kind of direction you want to be involved in. This will also ensure that there are no misunderstandings and that someone is not waiting for your decision when they should actually be making it themselves.