Das Teamwork-Blog

Erinnern Sie sich, zu welcher Musik sie so richtig ausgelassen tanzen konnten? Stellen Sie sich die digitale Transformation Ihrer Organisation als eine große Tanzinszenierung vor: Unterschiedlichste Rhythmen und Stilrichtungen treffen aufeinander - die Heavy-Metal-Fans auf die Diskofox-Queens, die Raver auf die LineDancer. Diese Vielfalt führt zwangsläufig zu Konflikten. Doch was, wenn wir sie als kreative Impulse für Fortschritt nutzen? Wie Führungskräfte diese Konfliktenergie effektiv nutzen, zeigt dieser Artikel. Konflikte verstehen: Warum sie unvermeidbar und wertvoll sind Konflikte - formwandelnde Begleiter Konflikte entstehen überall. Führungskräfte erleben Konflikte häufig in Form von unklaren Verantwortlichkeiten, unterschiedlichen Erwartungen oder Widerständen gegenüber neuen Arbeitsweisen. Während einige bereit sind, neue Schritte auszuprobieren, vertrauen andere auf vertraute Abläufe. Konflikte begleiten die Tänzer:innen auf eine Reise zwischen unterschiedlichen Bühnen. Jed...

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.

Eine hierarchiefreie Organisation in einem bürokratischen Umfeld ist reine Utopie?  Ein freier Träger der Kinder – und Jugendhilfe in Berlin hat es gewagt: Wir arbeiten hierarchiefrei! Eine Erfolgsgeschichte - mit knapp 40 Mitarbeiter:innen. 

In den letzten Jahren durfte ich verschiedene Kunden auf ihrem Weg in die Agilität begleiten, führen oder komplexe Produkte mit ihnen gemeinsam gestalten. Industrieweit nehme ich den folgenden Trend wahr: Ihr wollt mehr Effektivität? Dann braucht ihr mehr Teamautonomie! Wie viel Autonomie brauchen wir genau? "Je mehr desto besser." 

... zumindest das Letzte, was Ihr in diesem bewegten Jahr von uns zu lesen bekommt, liebe Leserinnen und Leser. Auf dass es uns im kommenden Jahr ein bisschen leichter fallen mag!

Leaders, coaches, trainers and consultants work very often as lone warriors. Since we are highly paid, everybody expects expert knowledge and performance from us. This can lead to excessive work hours and toxic work habits. What can we do to take care for ourselves?

Kürzlich unterhielt ich mich mit meinem Kollegen, Thomas Brinkmann, über das Thema Agilität im Vertrieb. Hier das Gespräch.

I would like to write briefly about a common situation in teams: The lack of direction. Though many teams know it might be helpful for them to agree on a common shared vision they have a hard time finding this vision. The consequences are, that the team is lost in the daily business and it’s not as passionate and happy as it could be. This blog post is about two simple techniques finding a team purpose.

Dieser Artikel handelt von Projekten außerhalb der Softwareentwicklung - also außerhalb des Bereichs, für die das "klassische Scrum" (welch merkwürdige Wortkombination!) konzipiert wurde. Zum Beispiel bei Projekten der internen Organisationsentwicklung. Bei manchen Projekten lohnt es sich, die Anwendung agiler Methoden ins Auge zu fassen. Und dabei ist wiederum Scrum im Prinzip gut geeignete agile Methode. Im Prinzip. Denn für die hier angesprochenen Projekte muss die Methode angepasst werden.

Das Forum Agile Verwaltung ‚FAV‘ wurde im Februar 2016 gegründet. Seine Mitglieder möchten Wege untersuchen, agile Methoden und öffentliche Verwaltung in Kontakt zu bringen, ohne Dogma und Mission, als Austausch- und Experimentierplattform, live und auch im Internet. Seit März 2016 ist das FAV online unter www.agile-verwaltung.org . Jetzt lädt es für Anfang nächsten Jahres zu seiner ersten Konferenz ein.

Das Thema „Widerstand gegen Changes“ steht (wieder einmal) hoch im Kurs. Die Mitarbeiter und ihre mangelnde Veränderungsbereitschaft seien eines der Haupthindernisse, wenn Unternehmen neue agile Arbeitsmethoden einführen wollten. So zum Beispiel der Befund der Zeitschrift „Harvard Business Manager“ /1/, aber auch anderer Experten. Aber wie so oft sagt eine Beobachtung genauso viel über den Beobachter aus wie über die Beobachteten.

Die IT und hier wiederum der Bereich der Entwicklung ist zur ständigen Quelle neuer Ideen und neuer Rollenmuster geworden. Hier wurden zuerst die agilen Methoden wie Scrum, Kanban entworfen, erprobt, verbreitet. Kein Grund, diese Methoden hier einzusperren. Die Übertragung auf andere Bereiche bis hin zur Agilisierung ganzer Unternehmen ist eine spannende Vision. Das Wort „Übertragung“ aber trifft es nicht ganz: einige Konzepte zum Beispiel von Scrum müssen dabei sorgfältig angepasst werden.

Damit ist gemeint: Jedes IT-Projekt muss einen Wert liefern, aus dem heraus es sich rechtfertigt. Aber was verstehen wir unter dem Begriff „Wert“? Und kann man diesen Wert immer messen? Vorgestern bin ich dieser Frage anhand von X-Unternehmen nachgegangen – also traditionellen, gewinnorientierten Unternehmen. Heute will ich auf Y-Unternehmen eingehen. Dabei stoßen wir auf die Frage, ob es sich beim „Wert“ immer um Geld handeln muss.

„IT-Projekte werden nicht genehmigt, sondern finanziert“, ist eine unserer Kernaussagen. Im Teamworkblog haben wir schon öfter darüber geschrieben. /1/ Damit ist gemeint: Jedes IT-Projekt muss einen Wert liefern, aus dem heraus es sich rechtfertigt. Aber was verstehen wir unter dem Begriff „Wert“? Handelt es sich immer um Geld, oder kann es auch etwas anderes sein? Und kann man Wert immer messen?

In agilen Projekten wird iterativ gearbeitet. Alle Anforderungen stehen in einem Product Backlog, werden priorisiert und in den einzelnen Sprints schrittweise umgesetzt. Dabei wird bereits geschäftlicher Nutzen erzeugt und die jeweils neu erzeugten Funktionsbausteine soweit irgend möglich schon in den Echtbetrieb genommen.  Aber kann dabei nicht auch großer Murks erzeugt werden? Kann es nicht vorkommen, dass man nach dem 25. Sprint feststellt, dass man sich in eine Sackgasse entwickelt hat? Können sich die neuen Anforderungen Nummer 94 und 95 nicht mit  den schon realisierten Funktionalitäten 1 bis 93 widersprechen? Wie sichert man eine konsistente Gesamtlogik des Projekts über all seine Sprints hinweg?  Eine Antwort darauf heißt „Domänenmodell“.