Mit dieser Frage beginnt bei mir jede Zusammenarbeit. Seit 2010 arbeite ich mit Teams, Führungskräften und Geschäftsleitungen, wenn etwas feststeckt: erst verstehen, worum es wirklich geht, dann gemeinsam lösen.
In über 25 Jahren im Projektgeschäft und in Organisationen habe ich zu oft dasselbe gesehen: Etwas läuft nicht, und schon liegt eine erste Maßnahme auf dem Tisch. Ein Training, eine neue Stelle, ein neues Tool. Alle bringen sich ein, mit viel Energie und guter Absicht. Nur hat vorher niemand gefragt, was das eigentliche Problem ist.
Also arbeitet man am Symptom, und das Problem bleibt, wo es ist. Und so hangelt man sich von Symptom zu Symptom, von Maßnahme zu Maßnahme, ohne ersichtlichen Erfolg. Nicht aus Mangel an Einsatz, sondern weil die eigentlichen Probleme nicht aufgedeckt und angegangen werden.
Deshalb stelle ich am Anfang zwei Fragen:
Welches Problem soll gelöst werden?
Und warum glauben wir, dass die aktuelle Maßnahme darauf einzahlt?
Die Antworten sind nicht immer angenehm, aber notwendig.
Warum man mich anruft und worum es dann wirklich geht
Fast jeder Anruf kommt schon mit einer Idee, was zu tun wäre. Dann stelle ich ein paar Rückfragen, die oft zu einem anderen Bild führen. Hier ein paar Beispiele:
Führung & Entscheidungen
Die Anfrage
Ein Training, damit sich ein Bereich intern besser im Gerangel um Kapazitäten durchsetzt.
Das eigentliche Problem
Es fehlt eine verbindliche Priorisierung auf Portfolio-Ebene, die ein solches Gerangel unnötig macht.
Was dann hilft
Mit Führungskräften und Führungskreisen kläre ich drei Dinge: Was ist das Problem, wer sind die betroffenen Parteien und wie wird über Maßnahmen entschieden, damit wir ins Rollen kommen. Als Sparringspartner, Moderator oder im Einzelcoaching.
Teams & Menschen in Bewegung bringen
Die Anfrage
Das Team arbeite zu langsam und ich solle es schneller machen, indem ich Scrum einführe.
Das eigentliche Problem
Das Team war nicht langsam. Es musste nur permanent auf Menschen warten, die zum Abschluss ihrer Aufgaben gebraucht, aber nicht eingeplant oder nicht erreichbar waren. Es fehlte an einem klaren Abhängigkeitsmanagement, nicht an Scrum.
Was dann hilft
Häufig helfen schon Transparenz und klare Schnittstellenformate: Das Team lernte, sich vorher zu holen, was es braucht. Die Wartezeiten sanken. Alle sahen dasselbe und sprachen über die Ursache statt über Schuldige.
Agile Arbeit, die wirklich funktioniert
Die Anfrage
Man arbeite seit einiger Zeit agil und wünscht sich ein kurzes Review mit kleinen Anpassungsvorschlägen, weil sich der gewünschte Erfolg nicht einstellt.
Das eigentliche Problem
Rollen wurden umbenannt, Meetings eingeführt, aber Arbeitsweisen sind gleichgeblieben. Die alte Arbeit im neuen Kleid verursachte mehr Probleme, als sie half. Es bedurfte eines kompletten Neuaufsatzes statt kleiner Anpassungen, da es keinerlei Basis gab.
Was dann hilft
Offen zeigen, was ich sehe, und ein kleiner Pilot mit Freiwilligen, der die Arbeitsweise so ausprobiert, wie sie gedacht ist und für das jeweilige Umfeld passt. Erst wenn der Pilot trägt, wird ausgerollt, angepasst an Ihr Umfeld.
Die andere Hälfte ist, das Problem mit den Menschen zu lösen, die es betrifft. Drei Dinge sind mir dabei wichtig.
Mit denen planen, die die Arbeit machen.Pläne über die Köpfe hinweg scheitern an der Praxis. Mit der Führung kläre ich den Rahmen und halte sie auf dem Laufenden; gearbeitet wird dort, wo das Problem sitzt.
Kleine Schritte, die man sehen kann.Eine neue Spalte im Ticketsystem, ein kleiner Prototyp, ein neues Meetingformat. Was korrigierbar ist, darf mutig von den Betroffenen entschieden und umgesetzt werden, für eine Kultur, in der entschieden und nachgebessert wird, statt sich vorher endlos abzusichern.
Werte vor Framework.Die Werte und Prinzipien modernen Arbeitens stehen für mich über jedem Framework. Das Framework passt sich dem Umfeld im Rahmen dieser Werte und Prinzipien an, nicht umgekehrt. Ob das am Ende Scrum heißt, Kanban, SAFe, Flight Levels oder gar keinen Namen hat, ist zweitrangig.
Wer ich bin
Nach vier Jahren als Game Designer, Programmierer und Softwareentwickler habe ich 2005 mit einem Gründerstipendium meine eigene Firma gegründet: syncRage. Fünf Jahre, zehn Angestellte, über 15 Spiele für PC, Konsolen und Smartphone. Erst habe ich selbst programmiert, designt und getestet, dann kamen Projektmanagement, Kunden, Finanzen und Mitarbeiterführung dazu. Seitdem kenne ich die Perspektiven vom Team bis zur Geschäftsleitung von innen; das hilft mir heute, alle Seiten an einen Tisch zu holen.
2008 haben wir Scrum eingeführt, und die Idee hat mich sofort überzeugt: gemeinsam planen mit denen, die die Arbeit machen, und Probleme früh erkennen. Die Wahl fiel mir nicht schwer, als ich mich danach als Scrum Master und Agile Coach selbstständig machte. Seit 2010 begleite ich Teams, Product Owner und Management in ganz unterschiedlichen Firmen und Projektgrößen, vom einzelnen Team bis zum Großprogramm, vertikal wie horizontal.
Profil auf einen Blick
25+Jahre in Softwareprojekten und Organisationen
seit 2010als Change Manager, Agile Coach und Scrum Master
7Zertifikate, von Agile Leadership bis SAFe
8Branchen, vom öffentlichen Sektor bis Aerospace
Kurz gesagt
Schwerpunkte
Change Management, Coaching, Beratung
Ebenen
Teams und Mitarbeitende, Product Owner, Scrum Master, Führungskräfte, Geschäftsleitung
Es gibt keinen Standardablauf, aber einen klaren ersten Schritt.
Orientierungsgespräch
Kostenlos, etwa 30 Minuten. Sie schildern die Situation, ich stelle Fragen. Am Ende wissen wir, ob und wie ich helfen kann. Manchmal ist das Ergebnis auch: Sie brauchen mich nicht, sondern etwas anderes.
Vertiefung
Wenn wir beide tiefer einsteigen wollen, nehmen wir uns ein bis zwei Stunden, als Workshop oder im Vier-Augen-Gespräch, je nach Thema. Auch das ist kostenlos.
Vorschlag
Danach bekommen Sie einen schriftlichen Vorschlag mit Optionen. Sie entscheiden.
Schreiben Sie mir, auch wenn Sie noch nicht wissen, worum es eigentlich geht
Dafür ist das Gespräch da. Ich melde mich in der Regel innerhalb eines Werktags.