Software development with agile teams means that teams organize their work themselves and manage the upcoming tasks independently. In an ideal scenario, these are teams that take the tasks at hand seriously and in which everyone is happy to take responsibility. The team members help each other, always having the sprint and project goals in mind, and weigh up their decisions against this background in their day-to-day business. Problems are discussed objectively and solved pragmatically. The quality of the delivered software is good, everyone in the team is aware of the quality requirements. Stories are completed every 2 days and are always delivered well before the planned deadline.
The reality is unfortunately different in the vast majority of cases. The teams we work with in companies often stumble over 'getting things done'. Problems that arise are discussed for a long time, but no decision is made at the end. At the end of the sprints, many things remain "almost finished". Release dates are postponed or only kept with poor quality. Everyone involved suffers from the unsatisfactory situation.

A View from the outside

With an outside perspective, the impression could arise that nobody in the teams is willing to get involved or take responsibility for the results. The conclusion of the project managers is quickly: "With those people on the team you cannot succeed in such a project.

If you start helping teams in such situations as a Scrum-Master or Agile Coach, a completely different picture often emerges: The people in the teams make a competent impression, are technically experienced and respectful in dealing with each other. Nevertheless, it is clearly noticeable that the cooperation does not work well and that the people in the team are dissatisfied with or even tormented by their work situation.

So what exactly is going on here?

The outside conditions

In such a situation, it is interesting to turn one's attention to the outside: What are the general conditions under which the team operates?

  • Are the project goals clear to all team members?
  • Is there transparency about which decisions the team is allowed to make?
  • Can the team itself decide on quality measures and improvements?
  • Do the team members have the necessary skills to implement the project requirements?
  • Does this apply not only to the technical but also to the communicative requirements?
  • What happens when mistakes happen?
  • Is there room and time for improvements in the work process?

All these things have nothing to do directly with the members of the team, but rather with the general conditions under which the team works. When it comes to the question of how these framework conditions come about, leadership plays a decisive role. Because even if the respective manager answers all the above questions clearly in a positive way, the team's assessment may differ enormously from this:

If you, as a manager, regularly talk to the customer about the project goals, these are very present and completely clear to you. It is easy to forget, however, that the team is not aware of the discussions with the customer and is therefore often unclear about the current goals.

Many of the above points are also decided in inconspicuous subordinate clauses:

The question "Does everyone have enough to do?", asked in the daily of a team, destroys in a few moments the motivation of the team to want to finish things in a concentrated way in pair programming.

The statement "We don't have time for this now" as an evaluation of the results of a retrospective destroys any motivation for process improvement in the team.

Often the reasons for missing information flows, not addressed topics and missing clarity about decision possibilities are not clearly identifiable either for the manager or for the team.

Much remains altogether implicit, unspoken and leads to a latent dissatisfaction on both sides.

 

Voraussetzungen für Selbstmanagement in Teams

Voraussetzungen für Selbstmanagement in Teams

From our observation, self-management and assumption of responsibility fail in most cases due to at least one of the following four factors:

  • Skills - Does the team have the technical and social-communicative skills needed to implement the project?
  • Information / Clarity - Are the project objectives and business framework sufficiently clear to all team members?
  • Trust - Are the team expected to make responsible decisions? And how are mistakes and learning situations dealt with?
  • Power - Which decisions can the team make itself? And is there clarity between the team and the manager about the type of delegation?

 

All new, but how?

If teams in agile software development are to take on more responsibility, make more decisions themselves and "manage themselves", this requires appropriate framework conditions. The task of leadership in this context is then no longer to steer the team and to weigh up and make all important decisions. The task of leadership in this context is much more the creation of suitable framework conditions under which teams can work independently.

Legitimation von Führung

Legitimation von Führung

The focus of the executive's tasks thus shifts from "managing, deciding, instructing, controlling" to "moderating, coaching and advising". Methods and attitude of leadership differ very clearly from the previous understanding of leadership, which is essentially influenced by Taylorism.

The path to new, indirect and supportive leadership is therefore not easy. It does not only need a completely different set at guidance tools but additionally also a reflection of the own attitude: To see itself less as Entscheider but rather as Wegbereiter, falls to many humans in guidance positions heavily. While there is for the methodical part already much supporting literature and training further gives, the examination and adjustment of the own attitude are by far more difficult to accomplish.

However, elements from systemic coaching, solution-focused consulting and self-management provide a good basis for this continuous process. Supplemented with a set of methods from Management 3.0, Management Y, and Co., it becomes a solid tool to support agile teams in leading them for the future. We offer suitable further training for managers to support this change process.