‚Gleichrangigkeit und Ebenbürtigkeit‘ im Team-Dynamik-Seminar bei Armin Poggendorf

Am kommenden Wochenende werde ich wieder eines der Seminar von Prof. Dr. Armin Poggendorf  in der Rhön besuchen.

Das Thema des Seminars ist ‚Gleichrangigkeit und Ebenbürtigkeit‘, ein Thema, das bei Scrum einen sehr großen Stellenwert hat und das man als Scrum Master nicht unterschätzen darf, vielmehr, auf das man einen starken Fokus legen sollte.

Warum?

Weil in Firmen und Konzernen nicht alle gleichrangig sind. Es existiert eine Hierarchie und damit gibt es ein Oben und ein Unten. Die oben sind sagen denen unten, was und oft auch wie sie etwas machen müssen. Diese Manager sind eher Vertreter des ‚Command and Control‘ – nicht immer.

Ein Scrum Master ist ein ’servant leader‘. Er unterstützt das Scrum Team in einer Führungsrolle. Das kann zu Überschneidungen mit Rollen führen, die aufgrund der Hierarchie des Unternehmens festgelegt sind. Diese ‚Hierarchen‘ können sich eingeschränkt, im extremen Fall sogar bedroht fühlen. Dies umso mehr je erfolgreicher ein Scrum Master mit seinem Team ist.

Deshalb ist es wichtig sich intensiv mit den Hierarchien des betreffenden Unternehmen zu beschäftigen. Mehr noch, es ist wichtig sich über die Macht-Strukturen klar zu werden, die vorherrschen. Insbesondere bei großen Firmen oder Konzernen geht es um Einfluss, Status und Macht.

‚Command and Control‘ ist nicht die Art und Weise mit der ein Scrum Master sein Team führt. Wie bereits erwähnt hat er eine unterstützende Funktion, z.B. indem er Hindernisse für das Team aus dem Weg räumt. Er sorgt sich um die gute Stimmung im Team, überlegt wie er die Team-Mitglieder motivieren kann ihre Arbeit mit Freude zu machen. Dazu gehört, dass sich die Team-Mitglieder gegenseitig blind vertrauen können, weil sie von einander abhängig sind, aufgrund der Verteilung der verschiedenen Skills.

In dem Seminar erhoffe ich mir Impulse, wie diese beiden Welten der Führung einen modus vivendi finden können. Letztendlich geht es beiden darum, dass das Unternehmen, für das sie arbeiten, erfolgreich ist.

IT & Media 2017 erfolgreich

Ich war am 23.2.2017 mit meiner Firma SMK Software Management Kommunikation GmbH auf der IT & Media als Aussteller auf dem Gemeinschaftsstand von IT for Work vertreten.

Die Resonanz war sehr gut, d.h. wir hatten ständig Interessenten auf dem Stand. Ich wurde nach sehr unterschiedlichen Themen gefragt:

  • Wir machen Scrum, aber der Erfolg stellt sich nicht so richtig ein.Wie sagen Ken Schwaber und Jeff Sutherland: Scrum ist
    • leichtgewichtig
    • Einfach zu verstehen
    • Schwierig zu meistern. Das heißt, dass man nicht vom Scrum-Rahmenwerk abweichen sollte. Das Scrum Rahmenwerk besteht aus Scrum Teams und den mit ihnen verbundenen Rollen,  Ereignissen, Artefakten und Regeln. Jede Komponente des Rahmenwerks dient einem  spezifischen Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg
  • Was ist der Unterschied zwischen dem Product Backlog und dem Sprint Backlog.Das ist eine essentielle Frage vor allem im Hinblick auf den Scope, den das Scrum Team bearbeitet. Diese Scope wird im Sprint Backlog verwaltet. Dieser sollte während des Sprints nicht verändert werden, wenn es das Team nicht will.
  • Mein Scrum Team ist manchmal größer als zehn Personen.Das kann funktionieren. Die Kommunikationsbeziehungen nehmen aber zu je mehr Team-Mitglieder im Team sind und die Kommunikation wird damit schwieriger.
  • Wir lassen die Retrospektive weg.Die Retro steht bei Scrum für die Reflexion, d.h. das Team überlegt gemeinsam, was im letzten Sprint nicht so gut gelaufen ist und überlegt sich Maßnahmen. Deshalb ist die Retrospektive sehr wichtig, wenn man Scrum richtig machen will.

What is the purpose going agile ?

What is the purpose going agile ?

We embrace Change !

In contradiction to classic software project management changes are accepted during the agile software development.

This means that between waterfall or V-Modell and Agile Project Management there are many differences. Not only for the team who is developing the software but also for other parts of the software house and the customer the software house is working for.

The customer can be another department within a company. It can also be another company which orders the software.

If the software house creates potential shippable increments during a short iteration and asks for feedback at the end of the iteration the customer has to follow the progress in a similar velocity. In consequence it enables the customer to react much faster to changes in his market. As a result the customer could be one step faster than its competitors.

But not for nothing: he is asked to give feedback after every iteration and this leads to closer connection to the software house (supplier). 

 

 

 

Self-organization

It's no self purpose.

There is nobody in the team who knows all. Therefore the team members need to collaborate. Sharing knowledge with others works only in an atmosphere of trust.

 

Inspect & adapt

Requirements are changing leading to user stories which change. After every iteration this needs to be inspected. Prioritizing user stories after every iteration is adapting to the changing requirements.

This is important and one essential mechanism doing agile.

Continuous improvement

The teams reflects how it was working during the last iteration. The team members think about what was good and what needs to be improved.

This is done during the retrospective. There are many different ways to execute a retrospective.

The Scrum Master needs to have a collection of retrospective exercises for different purposes and goal of a retrospective.

Scaling agile

There are different ways for scaling large software development projects i.e. projects involving more than one Scrum team:

  • SAFe is based on Donald Reinertsen’s principles he describes in book ‚Product Development Flow‘ adapted to software (product) development. SAFe stands for scaled agile framework and the it’s possible to see how it’s working on scaledagileframework.
  • ScALeD Agile Lean Development supported by it-agile GmbH follows principles. Agile product development first was focused on small projects and the principles worked and still work well.  How can those principles be adapted to larger projects ? An explanation can be found on scaledprinciples.

What do you think about these ? Do you have experiences using one of these approaches ?

Conflict Navigator

Conflict within a Scrum Team can happen. Lyssa Atkins describes in her book ‚Coaching agile teams‘ five levels of seriousness of the conflict:

  • Level 1: Problem to solve
  • Level 2: Disagreement
  • Level 3: Contest
  • Level 4: Crusade
  • Level 5: World War

She recaps Speed Lea’s framework which helps to become more objective. Lyssa also says that determining the level of conflict present on a team is no rocket science. It’s observation, conversation and intuition.

What makes is so fascinating that team member is experiencing the conflict from different levels.

What are your experiences ? Is it like Lyssa describes ? Is it helpful to categorize it in the way like Speed Lea did ?

Your comments are greatly appreciated !

What skills of new teams members are most important and how to find out ?

I’m asked to setup a new Scrum team. The software development project is very ambitious with a high demand of technical knowledge. Also it’s embedded within a great company where the requirements are defined from various departments. Some skills I already know: to engage accountability, to be team-minded and willing to improve oneself and to address improvements towards the team. Are there other skills ?

More important I ask myself how to find people with the appropriate skills ? I want me to be happy but also the other person.

What skills of new teams members are most important and how to find out ?