bor!sgloger » Deborah Weber

Warum Obama nur graue und blaue Anzüge trägt: Von Stabilität in Veränderungsprozessen

Deborah Weber — Thu, 21 Feb 2013 06:13:37 +0000

Wenn wir zu unseren Kunden gehen, dann immer mit der Absicht, etwas zu verändern. Wir implementieren Scrum, was einhergeht mit einer Veränderung der Rollen, Prozesse und Werte der Zusammenarbeit. Und wir möchten am liebsten, dass alle Mitarbeiter freudig aufspringen und rufen: „JA! Wir wollen uns verändern!“ Stattdessen jedoch sind viele Mitarbeiter erst einmal verhalten: „Ja, die agile Idee ist klasse und wir haben schon viel von Scrum gehört und gelesen, aber ich bin mal gespannt, wie ihr das hier machen wollt.“

Und dann starten wir mit ersten Trainings und damit, die ersten Teams auf Scrum umzustellen. Das bedeutet für die Mitarbeiter viel Veränderung: Die Teams werden neu gemischt, Mitarbeiter bekommen andere Rollen, wir implementieren Regelmeetings, alles wird transparent gemacht und wir sprechen plötzlich offen mit allen über Hindernisse in der Organisation. Uffz! So anstrengend haben sich die Mitarbeiter die Umstellung gar nicht vorgestellt. Plötzlich spürt man in den Teams den Gedanken: „Och, eigentlich war es doch immer ganz gemütlich hier. Können wir nicht wieder zurück?“ Dann bekommen die Consultants eine anstrengende Aufgabe, nämlich die angestoßene Veränderung konsequent weiter aufrecht zu erhalten. Die Veränderungen müssen im Verhalten der Mitarbeiter und den Prozessen im Unternehmen verankert werden.

Nicht zu früh abweichen!

Aber das Zurückrudern meinen die Mitarbeiter nicht böse – für diese Reaktion gibt es eine rein biologische Erklärung. Professor Gerhard Roth, Neurobiologe an der Universität Bremen sagt: „Für unser Gehirn gibt es kaum etwas schwierigeres, als Gewohnheiten abzulegen.“ Wir haben uns bereits an Verhaltensweisen gewöhnt und können sie automatisch anwenden. Das ist gut so, denn wir müssen selektieren, worüber wir uns Gedanken machen, sonst läuft unser Arbeitsspeicher im Gehirn voll.

Barack Obama trägt nur blaue und graue Anzüge. Warum? Er sagt: „Ich will mich nicht entscheiden, was ich anziehe oder esse, weil ich zu viele andere Entscheidungen treffen muss.“ Gewohnheiten und Routinen sind wichtig, um uns Luft zu verschaffen und sie geben uns Sicherheit. „Das Gehirn versucht unentwegt, so viele Handlungen wie möglich in Routinen zu verwandeln,“ sagt Professor Roth. Und daran arbeiten wir mit der Einführung unseres Scrum-Flows: eine neue Sicherheit und Routine herzustellen. Ja, ich weiß, das dauert ein paar Sprints, aber es funktioniert! Dazu müssen Mitarbeiter und Consultants großes Durchhaltevermögen beweisen und konsequent zusammenarbeiten.

Viele Teilnehmer in Trainings fragen mich: „Was ist der größte Fehler, den man bei der Einführung von Scrum machen kann?“ Und meine Antwort darauf ist: „Das zu frühe Abweichen vom Scrum-Flow und den Scrum-Grundlagen. Oder den vermeintlich nervenden Consultant zu früh nach Hause zu schicken.“ Mindestens die ersten drei Sprints sollten wirklich nach Lehrbuch umgesetzt werden. Da muss man sich durchbeißen, und konsequent sein. Das ist hart, aber danach wird der Scrum-Flow zur Routine und wir können uns stärker auf andere Dinge konzentrieren, wie z.B. Teamentwicklung oder Steigerung des Levels of Done. Jetzt beginnt also die Kür der Veränderung und damit der eigentlich spannende Teil. Daher lautet mein Rat zu Anfang: „Haltet durch! Land ist in Sicht“

Angelehnt an den Artikel “So besiegen Sie schlechte Gewohnheiten!” (Elke Hartmann-Wolff) im Focus 02/13 vom 07.01.2013

Warum Scrum und BI so gut zusammenpassen

Deborah Weber — Fri, 08 Feb 2013 06:42:19 +0000

Was macht Scrum in BI-Prozessen so interessant?

BI (Business Intelligence)-Systeme sind heute ein wichtiger Teil in Unternehmen geworden. Wo früher noch reine Datentabellen auf Papier oder elektronisch analysiert und in aufwändige Berichte gebracht wurden, helfen uns heute BI-Systeme, einen schnellen und aussagekräftigen Überblick über alle Geschäftszahlen zu bekommen. Warum ist dies wichtig für ein Unternehmen? Die Welt dreht sich – und zwar gefühlt immer schneller. Die Unternehmen hantieren mit Waren, Dienstleistungen und internen Kosten, die immer schneller zur Verfügung stehen müssen. Daher müssen Manager und Fachleute möglichst schnell wissen, welche Bestände sich aktuell im Lager befinden, welche Waren am häufigsten gekauft und daher häufig nachbestellt werden müssen oder wie hoch die Ausstände im Mahnverfahren sind. Wie schnell können wir als Unternehmen reagieren? Wie liquide sind wir? Was können wir für die Zukunft wagen? Wie hoch ist das Durchschnittsalter in den Abteilungen und wo müssen wir Nachwuchs rekrutieren? Viele unternehmerische Entscheidungen beruhen auf dem Ergebnis solcher Zahlen. Ob im Topmanagement oder in jeder einzelnen Abteilung. Was ist in der Vergangenheit gut gelaufen, worauf können wir bauen? Was lief bisher nicht optimal, was können wir verbessern? Welche Maßnahmen sind nötig, um Stabilität in das System zu bringen?

BI-Lösungen sollen genau für diese fehlenden Antworten eine Entscheidungsgrundlage liefern. Wobei wir jedoch beachten müssen, dass wir die Auswertungen immer nur auf Erkenntnissen der Vergangenheit aufbauen können. Es gibt nicht immer nur einen Ursache-Wirkung-Zusammenhang. Die Dinge sind oft komplex und jeden Tag kann etwas Unvorhergesehenes passieren. Wenn der Kunde für seine Produktion schon immer den gleichen Rohstoff gebraucht hat, wir der einzige Lieferant sind und der Kunde das Produkt auch in Zukunft produzieren wird, dann können wir mit großer Wahrscheinlichkeit sagen, was er in Zukunft bestellen wird. Welche Mitarbeiter jedoch wann das Unternehmen verlassen, krank werden oder eine Familie gründen, das ist für Führungskräfte nicht vorhersehbar. Auch, wenn wir das gerne hätten :).

So oder so geben uns die Zahlen eine Orientierung. Vielleicht stehen die Daten in Wechselwirkung mit anderen Ereignissen, die uns helfen, künftig besser zu reagieren. Daher sollte die Wichtigkeit von BI-Abteilungen im Unternehmen nicht unterschätzt werden. Auf Basis dieser Daten werden wichtige unternehmerische Entscheidungen getroffen. Die Fragestellungen in Unternehmen ändern sich jedoch ständig, daher auch die Anforderungen an die BI-Software. Um diese wechselnden Anforderungen des Anwenders zu erfassen, bietet sich Scrum ganz besonders an. Über User Stories wird der Nutzen für den Anwender sichtbar und kann anhand der Priorisierung bearbeitet werden. Zudem wird die Arbeit für die BI-Entwickler kanalisiert. Da die Anwender aus dem eigenen Unternehmen stammen, werden die Anforderungen oft häufig und mit Nachdruck an das Team gegeben. Ein guter ScrumMaster, der das Team vor ständigen Störungen schützt, ist hier eine ganz wichtige Voraussetzung. Zudem wird das Agile Mindset und das Verständnis für Scrum auch in kaufmännische Bereiche des Unternehmens getragen. Letztenendes profitiert also der Anwender unserer Lösung, das Entwicklungsteam und natürlich das Unternehmen, das mit den gewonnenen und dargestellten Daten letztendlich arbeitet und entscheidet. Probieren Sie es einfach aus, gerne auch mit unserer Unterstützung: Scrum im BI-Umfeld lohnt sich!

Nein! Es gibt keine BI-Projekte!

Deborah Weber — Fri, 14 Dec 2012 08:55:11 +0000

(Oder: Von der Vernachlässigung unternehmensinterner IT-Produkte)

„Natürlich gibt es BI-Projekte, allein 3 BI-Projekte fallen mir spontan ein: Einkauf, HR, Finance! Was schreibt Deborah da jetzt? Will sie die internen Unternehmensprozesse ignorieren, abschaffen, nicht wahrhaben wollen? Die Transparenz der Unternehmenszahlen ist äußert wichtig und deren nutzerfreundliche Darstellung eine Wissenschaft für sich!“

Ja, das stimmt: Business Intelligence, sogenannte BI-Themen sind für jedes Unternehmen absolut wichtig, das habe ich selbst bei meiner Arbeit in HR feststellen dürfen. Denn ohne das Reporting der Unternehmenszahlen kennt man weder den Status quo noch eine Tendenz für die Zukunft. Und die Nutzerfreundlichkeit bei der Erstellung der unterschiedlichen Berichte sollte dabei einen hohen Stellenwert haben – das alles stelle ich gar nicht in Frage, sondern möchte es gerne noch weiter unterstreichen. Oft sehe ich, dass Unternehmen das Thema in einem kurzen einmaligen Zeitraum abarbeiten möchten – und dann vernachlässigen. BI ist für mich kein Projekt! Ein Projekt hat per se einen abgeschlossenen zeitlichen Rahmen.

Ständige Weiterentwicklung

Interne BI-Lösungen jedoch befinden sich in ständiger Weiterentwicklung und selten gelingt es, sie irgendwann einmal abzuschließen. Der Wunschgedanke ist zwar da, aber kaum per Stichtag umsetzbar. Die Bedürfnisse des Nutzers, die Daten des Unternehmens und strategische Ausrichtung der Kennzahlen werden sich ständig ändern. Und was haben wir dann hinterher? Ständige Wartung und Anpassung der Software, Entwickler, die aus neuen „Projekten“ herausgerissen werden, um Nacharbeiten für die Lösung zu machen. Das könnten wir uns alles sparen, wenn wir BI-Themen als eine ständige interne Produktentwicklung sehen würden. Eine Aufgabe, die ein interdisziplinäres Team benötigt, das ständig auf die Veränderungen im Unternehmen reagieren kann. Prozessübergreifend: Entwicklung, IT und Fachbereich etwa. Wichtig ist auch, dass das Team die Anforderungen geregelt von einem Product Owner durch ein priorisiertes Product Backlog erhält und nicht durch Zuruf auf dem Flur. Ja, da prallen zwei Welten aufeinander: Der Fachbereich, der ständig neue Ideen hat und gerne schnell auf den Markt, den Kunden oder den Chef reagieren möchte und mit Anforderungen nur so um sich wirft und die Entwicklung, die gerne Ruhe und Stabilität erreichen möchte. Beides zu vereinen und die Kräfte zu nutzen: ja, das wäre DIE Lösung! Dem Entwickler etwas Zeit geben, sich für den Moment zu fokussieren und dem Fachbereich die Chance geben, Veränderungen einfließen zu lassen. Wäre das nicht toll? Ja, das wäre toll – und das wäre SCRUM…

Scrum in internen BI-Lösungen – mehr dazu in weiteren Beiträgen…

Eine Erleuchtung: Scrum als Coaching-Tool!

Deborah Weber — Fri, 23 Nov 2012 10:08:51 +0000

Und als ich hinauszog, die Welt zu bescrummen, so erkannte ich, wie vielseitig einsetzbar es tatsächlich ist. Jeden Prozess können wir mit Scrum optimieren und jedes Scrum-Team wird effizienter und hat Spaß bei der Arbeit. Mit strahlenden Augen sitze ich in jeder neuen Situation da, die ich als mögliches Scrum-Einsatzfeld erkenne. Und gerade las ich ein Buch über Coaching- und Interventionsmethoden, als ich plötzlich aufstehen, die Tür des Zugabteils aufreißen und rufen wollte: „Leute – ich habe etwas entdeckt! Scrum ist eine Coaching-Methode!!! Ja, wir machen Coaching und ja, wir machen Scrum. Und wir begleiten Menschen, die Scrum machen und nennen es Scrum Coaching. Das ist nichts Neues, das gibt es schon lange. Aber ich meine Scrum selbst als Coaching-Methode!”

Wissen, was man will

Um ein glücklicher Mensch zu sein, muss ich wissen, was ich will, das Ziel positiv formulieren und mir auf dem Weg zu meinem Ziel immer klarer werden, wie es denn tatsächlich aussehen wird. Je klarer meine Vorstellung von dem Ziel heute schon ist, desto leichter erscheint mir der Weg dorthin. Genau das ist es ja, was wir in Scrum erreichen wollen. Liebe Leute, wenn ihr ein Produkt entwickeln wollt, braucht ihr ein Ziel und eine klare Vorstellung davon. Sprecht ganz viel darüber, macht euch zunächst klar, was ihr wollt und überlegt euch dann, wie ihr es erreichen könnt! Dann, wenn Klarheit herrscht, geht die Umsetzung fast wie von selbst. Wir merken das in den Sprint Plannings – je klarer der PO die Story an das Team kommuniziert, desto einfacher wird die Bearbeitung. Heruntergebrochen auf einzelne Schritte kann ich dann nachvollziehen, wie nah ich meinem gesteckten Ziel schon gekommen bin und kann meine Anstrengungen am Taskboard sehen.

Scrum-Coaching bekommt für mich nun eine ganz andere Bedeutung, wenn ich meine Entwicklungs- und Lebensziele damit erreichen möchte. Als Selbstcoaching-Tool beispielsweise. Also nicht IN Scrum, sondern MIT Scrum coachen. Ich meine damit: ob ich eine Software entwickle oder ein anderes geistiges Produkt – mit Scrum sollte das doch funktionieren. Angenommen, ich setze mir als Ziel, mehr mit meiner Familie zusammen zu sein. Dann stelle ich mir die Frage: “Was will ich eigentlich genau, was will ich erreichen, was sind Rahmenbedingungen, die mich einschränken? Und wie finde ich am Ende heraus, dass ich mein Ziel auch tatsächlich erreicht habe?” Ich gehe also einmal im Geiste oder auf Papier die PO Checkliste durch. Und dann überlege ich mir, welche Schritte nötig sind, was muss ich tun: Mit meinem Chef über neue Arbeitszeiten sprechen, einen Homeoffice-Platz einrichten, etc. Mit dem Unterschied, dass ich selbst mein eigener PO und Teil des Umsetzungs-Teams bin. Zusammen mit meinen Kollegen, meiner Familie und Freunden, die mir bei der Erreichung meines Ziels helfen können. Aber ich brauche einen ScrumMaster, meinen Coach, der mich daran erinnert, dass ich an meinem Ziel arbeiten muss. Wenn ich einen Coach habe, der mich unterstützt, ist das wunderbar. Wenn ich selbst auch noch mein eigener Scrum Master sein muss, wird es schwierig. Da stecke ich in zu vielen Rollen gleichzeitig und muss sehr diszipliniert bleiben. Aber dann kann ich mir mit Scrum Artefakten oder Tools helfen. Zum Beispiel kann ich an einem Taskboard die Umsetzung organisieren und mich fokussieren. Am Ende kann ich dann reviewen, ob ich mein Ziel erreicht habe und den Prozess reflektieren.

Heureka! Scrum ist überall!

Von einem Häuptling, der sein Land verteidigte

Deborah Weber — Fri, 09 Nov 2012 05:45:42 +0000

Gestern Abend habe ich den Film „Geronimo – Eine Legende“ gesehen. Ein Film über einen Apachen-Häuptling, der jahrelang den Kampf gegen die „Weißaugen“ nicht aufgegeben hatte. Jahrelang dafür gekämpft hatte, in seinem Land bleiben zu dürfen und auf seine bisherige Art und Weise weiterzuleben. Mit Büffeln und Pferden in einem Land mit Ackerfläche und Bergen. Viele andere Stämme hatten sich bereits ergeben und die Amerikaner hatten die Neue Welt bereits vollständig besetzt. Nur Geronimo – der wollte einfach nicht kapitulieren. Ein Unterfangen, das viele Menschenleben kostete. Jene von Indianern und „Weißaugen“ gleichermaßen. Wenn ich auch immer viel Sympathie und Mitleid mit den Indianern und ihrem Schicksal hatte, so wurde dieses Bild gestern Abend ein wenig aufgeweicht. Ich überlegte mir, wie sinnvoll es wirklich war, in einem sinkenden Schiff sitzenzubleiben und anderen Menschen den Rettungsweg zu versperren. Den Frauen und Kindern des Stammes, den Kämpfern und allen, die sonst involviert waren. Wie sinnvoll ist es, die eigenen Vorstellungen auf Biegen und Brechen durchzusetzen? Wie sinnvoll ist es, an Altem festzuhalten? Und wann muss ich mir eingestehen, dass ich keine Chance mehr habe, gegen die große Welle anzukommen?

Kämpfen oder einlenken?

Das Bild des kämpferischen Indianers, der für das alte System kämpfte, mit einer Hand voll Stammesmitgliedern ließ mich alsbald an meine Arbeit denken. Ich dachte an Unternehmen, in denen der Change schon weit vorangeschritten war – unabwendbar – und in denen immer noch Häuptlinge für das alte System kämpften. Ja, auch mit ihnen fühle ich ein Stück weit mit. Haben sie doch so lange ihre Abteilung erfolgreich verteidigt und geschützt vor den Cowboys, die das System ändern wollen. Wirklich erfolgreich? Ein Blick in die Gesichter der Mitarbeiter zeigt ein anderes Bild. Die Kraft hat sie längst verlassen, einen Grund, das Alte zu verteidigen haben sie schon längst nicht mehr. Sie folgen stumm den Anweisungen ihres Häuptlings, wenn sie denn überhaupt noch Lebenszeichen zeigen. Und auch der Häuptling leidet unter den Anstrengungen und der geringen Ausbeute, die der Kampf gebracht hatte – wollte es jedoch nicht wahrhaben. Aber der verbissene Blick, die tiefen Falten und der ausgemergelte Körper verraten, dass es ihm nicht gut geht. Die anderen Stämme hatten es besser: sie waren vereint mit ihren Familien, ihnen wurde Land zugeteilt (nun ja, mehr schlecht als recht) und sie hatten zu essen. Wer zuerst ging, hatte die besten Plätze bekommen.

OK. Moralisch gesehen war der Sieg der Neu-Amerikaner über die Indianer keine wirklich schöne Geschichte. Aber sie zeigt auf, wie Wandel (nicht) funktioniert. Ein gut umgesetzter Change war das nicht wirklich. Die Indianer hatten kein Mitspracherecht, der Nutzen für sie war nicht sichtbar und auch sonst war alles ziemlich einseitig gestaltet. Dass sie das nicht widerstandslos annehmen würden, war von vornherein klar. Sonst hätte die Regierung Botschafter und keine Soldaten geschickt. Aber wo ist die Grenze in einem solchen Konflikt? Wo muss ich anhalten und mir eingestehen, dass gegenseitige Zerstörung nicht die Lösung sein kann? Dazu bedarf es die Sicht einer neutralen Person, die dies zu erkennen weiß und die beiden Parteien zur Vernunft aufruft oder gar voneinander trennt, um Schlimmeres zu vermeiden. Denn komplette Zerstörung kann nicht die Lösung sein.

Damals hatte niemand die Geduld, das Wissen oder auch die Freiheit, nach einer passenderen Lösung zu suchen. Heute haben wir das jedoch. Und heute geht es zum Glück nicht mehr um Menschenleben, wenn wir einen Change umsetzen. Dennoch sollten sich Change Agents, also auch ScrumMaster, im Voraus mit allen Parteien auseinandersetzen. Was sind deren Bedürfnisse, wo können sie einen Nutzen aus der Veränderung ziehen, wo können wir sie abholen? Und damit vermeiden wir, dass sich einzelne Gruppen abspalten und ihr Revier bis aufs Blut verteidigen, obwohl die Erfolgsaussichten miserabel sind.

Change Management und Konfliktmanagement gehören daher eng zusammen und jeder ScrumMaster sollte das Wissen darüber haben, wie und warum Konflikte in einem Change entstehen und wie man damit umgehen kann.

Wir haben dieses Wissen und geben es gerne weiter: Beim Training “KonfliktManagement”.
Termine und Informationen gibt es hier.

Streiten, lernen, wachsen

Deborah Weber — Fri, 26 Oct 2012 07:38:38 +0000

Wir Menschen erinnern uns beim Blick in die Vergangenheit an besondere Momente. An besonders schöne Momente, aber auch an schmerzhafte. In den schönen Erinnerungen verharren wir gerne, schwelgen darin und genießen den Moment. Denken wir zurück an schlimme Ereignisse, dann verdrängen wir oft den Gedanken und versuchen, das Thema zu wechseln. Natürlich, denn unser Schmerzgedächtnis bringt uns wieder zu dem Schmerz zurück, den wir damals erlebt haben – und das möchten wir ja nicht. Denken wir mal an einen schlimmen Streit mit dem Partner oder einem Kollegen: Der Puls steigt, der Ärger wächst und die Emotionen kochen hoch. „Ganz ruhig,“ sagen wir uns dann „es ist vorbei, reg dich nicht auf. Alles ist gut jetzt.“ Aber die Emotionen verraten, dass wir das Ereignis noch nicht verarbeitet haben. Wir haben den Konflikt nicht vollständig und für beide Seiten überwunden. Vermutlich hegen wir immer noch Groll, wenn wir den Kollegen sehen oder ignorieren ihn einfach. Aber die Situation holt uns immer wieder ein.
Daher ist es wichtig, Konflikte beiderseits gütlich zu lösen. In die Rolle des anderen schlüpfen, seine Reaktionen verstehen lernen. Vielleicht finden wir sein Handeln nicht gut, aber wir verstehen nun seinen Gedanken und seine Beweggründe. Das ist ganz wichtig. So oft versuchen wir, den anderen von unserer Sichtweise zu überzeugen und das Problem auf unsere Art zu lösen. Aber genau diese egozentrische Sicht verschlimmert den Konflikt zusätzlich.

Lösung aus der Wolke

Die Dilemma-Wolke, die aus der Theory of Constraints stammt, stellt bildhaft dar, wie man die Gründe für einen Konflikt systematisch erleuchten kann. Sie eignet sich als Tool, um die Konflikt-Situation zu reflektieren und bisherige Annahmen zu hinterfragen. Jede Konfliktpartei teilt ihre Bedürfnisse mit und man sucht zusammen nach einem gemeinsamen Ziel. Diese Theorie geht davon aus, dass es zu jedem Konflikt eine Lösung gibt, die für beide Seiten gut ist. Auf http://www.wandelweb.de/blog/?p=870 ist gut dargestellt, wie man über die Dilemma-Wolke einen Konflikt in der IT auflösen kann. Wenn wir zusammenarbeiten, haben wir ein gemeinsames Ziel, in jedem Fall den Unternehmenserfolg. Management und Entwickler haben allerdings unterschiedliche Sichteweisen zur Durchführung und geraten in einen Konflikt. Jede Partei hat Annahmen über die Situation und über das Handeln der anderen. Diese Annahmen sind jedoch nicht immer wahr, sondern eine subjektive Sicht, die wir durch deren Analyse auflösen können. Diese Annahmen also, auf die sich beide Parteien stützen, werden auf ihre Richtigkeit überprüft: „Ist es tatsächlich so, dass eine Terminschätzung eine Terminzusage ist oder gibt es Unterschiede in der Verbindlichkeit?“ Sobald eine solche Annahme als nicht richtig bestätigt werden kann, bietet dieser Punkt einen Ansatz zu einer Lösung.

Und vermutlich hat der Konflikt auch etwas Gutes. Ganz bestimmt sogar! Wir reifen an solchen Situationen. Wir lernen dabei viel im Umgang mit anderen Menschen und mit unangenehmen Situationen. Wir lernen, die Dinge aus der Sicht der anderen zu sehen und nicht alles, wovon ich selbst glaube, dass es richtig sei, auch als alleinig richtig ansehe. Daher stelle ich mir nach jeder Konfliktsituation die Frage: Was ist gut daran? Was kann ich Positives für mich aus der Situation ziehen? Und es finden sich immer genügend Gründe, wenn man nur seinen Blickwinkel ein Stück öffnet. Versucht es einfach mal – think positive :)

Tipp: Den richtigen Umgang mit Konflikten kann man lernen – im Training “KonfliktManagement” mit Dieter Rösner und Deborah Weber! Details dazu hier.

Wir leiden an Selbstüberschätzung – und das ist auch gut so!

Deborah Weber — Mon, 08 Oct 2012 05:28:44 +0000

Diagnose: Selbstüberschätzung! Wir alle leiden darunter, eine Volkskrankheit sozusagen. Wir finden uns selbst und unser Handeln gut und denken, wir können alles besser als die anderen. Die anderen nämlich unterschätzen wir gerne. Natürlich kann ich besser einparken als die Kleinwagenfahrerin da vorne. Natürlich weiß ich besser über meinen Gesundheitszustand Bescheid als der Arzt – ich habe ja schließlich gegoogelt. Der Kollege wird das Meeting nicht halb so gut moderieren können wie ich. Pah! So schnell wird mir keiner etwas vormachen! So oder so ähnlich sieht es in vielen Köpfen aus.

Selbstüberschätzung ist ein Wahrnehmungsfehler, eine kognitive Verzerrung, wie die Psychologen es nennen. Rolf Dobelli (in: Die Kunst des klaren Denkens, 2011) lehnt sich an die Arbeit von Alpert/Raiffa an, die dieses Phänomen den Overconfidence-Effekt nennen. Wir alle tragen diese Eigenart in uns, können uns nicht dagegen wehren. Aber müssen wir es denn? Ohne diese Überschätzung würden wir keinen einzigen Schritt vorankommen. Der erste Schritt ist immer ein Versuch, immer ein Risiko, immer ein Wagnis. Daher ist das sogar gut, dass wir uns selbst überschätzen. Trial and error kann nur so funktionieren. Wir lernen bei jedem Schritt etwas dazu und kommen dem Ziel ein Schritt näher. Und genau damit nähern wir uns einer realistischen Einschätzung an. Wenn wir aber nur eine Chance zum Schätzen haben, dann sollten wir uns an der pessimistischsten Variante orientieren. Mit dem Wissen, dass wir zu hoch gestapelt haben.

Was bringt uns diese Erkenntnis in unserem Scrum-Alltag, zum Beispiel den Product Ownern?

Zum einen: Schwankt das Team in seiner Schätzung, nimm den pessimistischeren Wert. Das Team überschätzt sich möglicherweise. Zum anderen: Gib deinem Team eine Vision, die es anspornt, einen Schritt weiter zu gehen. Eine Vision, die die Möglichkeit gibt, sich an hohen Zielen zu orientieren. Und gib ihnen die Möglichkeit, oft auszuprobieren. Je mehr Versuche in der Entwicklung, desto besser das Produkt. Je häufiger Schätzungen stattfinden, desto realistischer werden sie sein.

Selbstüberschätzung in kleinen Dosen und zielgerichtet angewandt, kann sehr gewinnbringend sein, eine Überdosis jedoch ist schädlich. Und seien Sie sich stets bewusst, dass sie immer bei uns ist. Männer sind davon übrigens häufiger betroffen als Frauen, die sich danach also realistischer einschätzen. Ein weiterer guter Grund für Diversity im Team.

Warum wir eigentlich alle Freelancer sind

Deborah Weber — Tue, 24 Jul 2012 06:06:37 +0000

Neulich beim Kunden fragte mich ein Teammitglied, ob der Scrum-Ansatz eigentlich von Freelancern stammt. Nach all dem, was er bisher gehört und erlebt habe, sei er sich sicher, dass der Ansatz von Freelancern stammt und auch für Freelancer gedacht ist. „Weswegen?“ fragte ich ihn. „Weil das Team seine eigenen Technologien verwenden darf. Hauptsache, der Kunde bekommt die gewünschte Funktionalität. Und weil jeder viel Verantwortung trägt und viel mit dem Kunden kommuniziert.“ Ich sagte ihm, dass der Ansatz tatsächlich die Eigenverantwortung und Loyalität so steigert, dass man sich auch als Teammitglied wie ein Unternehmer im eigenen Unternehmen fühlen kann. Und dass das auch gut so ist. Er fand das auch gut und war begeistert von seiner Idee. Er ließ nicht locker und sagte: „Und dass wir dann ein Review machen und Feedback vom Kunden einholen und das im nächsten Sprint Planning einfließen lassen. Das machen Freelancer doch auch! Wir kitzeln aus dem Kunden heraus, was er denn eigentlich von uns haben will und überlegen uns im Nachgang, wie wir es dann umsetzen werden.“ Obwohl Scrum nicht dezidiert für Freelancer und auch nicht von Freelancern entwickelt wurde, so gab ich ihm dennoch Recht, was die genannten Parallelen angeht.

Ziel von Scrum ist es ja, dass jeder innerhalb des Scrum-Teams sich stärker mit dem Produkt identifiziert und entsprechend wie ein Unternehmer handelt: Was will eigentlich der Kunde? Was bringt den höchsten Business Value? Wir müssen hohe Qualität liefern! Wir wissen, wo die Reise mit dem Produkt hingeht!

Ja, im Prinzip hat er Recht. Letztendlich sind alle Scrum-Team-Mitglieder wie viele Freelancer, von denen jeder Einzelne bemüht ist, seine Aufgabe bestmöglich abzuliefern, um ein gutes Produkt und eine hohe Kundenzufriedenheit zu erreichen. Nur mit dem Unterschied, dass letzten Endes die Gesamtleistung der Teammitglieder zählt und wir uns im sicheren Schoß eines Unternehmens befinden.

Scrum in allen Unternehmensbereichen – warum eigentlich nicht?

Deborah Weber — Thu, 05 Jul 2012 04:55:38 +0000

Dachtet ihr bisher auch: Scrum ist doch nur was für Software-Entwickler und andere IT-ler? Warum? Weil es seinen Ursprung in der IT hat. Ja, deshalb wahrscheinlich. Aber was können wir mit Scrum erreichen? Was ist der Nutzen von Scrum? Warum scrummen wir eigentlich? Wir möchten unter anderem die Qualität unserer Produkte und unserer Zusammenarbeit steigern. Und wir regen die Verantwortlichen in Unternehmen z.B. dazu an, crossfunktionale Teams zusammenzustellen. Weil wir die Abstimmung zwischen verschiedenen Wissensbereichen verbessern wollen, zum Wohle des Produkts. Damit Abstimmungen schneller ablaufen – oder damit sie überhaupt ablaufen. Schnelle Feedbackschleifen und kontinuierliche Verbesserung sollen die Prozesse verbessern und allen Beteiligten ein Stück Verantwortung übertragen.

Gemeinsam lässt sich alles umsetzen

Genau dasselbe macht Geschäftsprozessmanagement (GPM) auch in kaufmännischen Abteilungen. Alle Beteiligten sollen zum Wohle des Produkts und der Kundenanforderung an einem Strang ziehen und ihr Wissen in den Prozess einbringen. In Kontinuierlichen Verbesserungsprozessen (KVP) wird gemeinsames Feedback verarbeitet und in die künftigen Prozesse aufgenommen. Daher ist es ratsam, Abteilungen nicht mehr nach ihren Fachgebieten aufzuteilen, sondern nach dem Prozess, in dem die Beteiligten arbeiten, also interdisziplinär. Es wird angestrebt, beispielsweise Teams für Mitarbeitereinstellungs-Prozesse zusammenzustellen. Dazu gehören Führungskräfte, Personalreferenten, Administratoren, der Einkauf und sicherlich noch weitere Beteiligte im Unternehmen. Erst, wenn alle, die in einem Boot sitzen auch in einem Team sitzen und sich ihrer Verantwortung bewusst sind, kann der Prozess verbessert werden. Nur zu oft habe ich in der Vergangenheit erlebt, dass die Abteilungsgrenzen einfach zu undurchdringbar sind, um gemeinschaftlich an einem Projekt zu arbeiten. Das muss und kann sich ändern mit Scrum als Prozessmanagement-Methode in crossfunktionalen Teams.

Warum sollten wir nicht zum Beispiel den neuen Unternehmensauftritt in einem gemischten Team planen? Viele Bereiche sind davon betroffen und können ihren Beitrag dazu leisten. Zum Beispiel muss die IT die neue Website aufsetzen, die Grafiker neue Vorlagen erstellen, die Personalabteilung ihre Stellenanzeigen anpassen, und und und. In kurzen Abschnitten wird das Zwischenprodukt, beispielsweise ein erster Logo-Entwurf, vorgestellt und weiterentwickelt. Ein neues Employer Branding kann zusätzlich mit Kollegen aus dem Marketing, Führungskräften und den Ausbildern eines Unternehmens erstellt werden. Warum nicht? Was mit dem Deming-Cycle schon seit Jahren von Prozessabteilungen gepredigt wird (Plan – Do – Check – Act), findet nun in einer anwendbaren Methode, Scrum, seine Umsetzung: Gemeinsame Planung, abteilungsübergreifende Umsetzung, häufige Feedbackschleifen und anschließende Verbesserung des Prozesses.

Natürlich haben wir andere Herausforderungen als bei einer Entwicklungsmannschaft. Oft werden Mitarbeiter für diese Projekte nur teilweise freigestellt oder arbeiten teilzeit. Aber auch diese Hindernisse sind überwindbar. Die Meetings müssen vom Team entsprechend so gelegt werden, dass alle Beteiligten teilnehmen können, vielleicht auch über Videokonferenzen, sofern eine Präsenz nicht möglich ist. Vielleicht kann es das Management auch möglich machen, dass sich zum Sprintwechsel alle Teilnehmer an einem Ort treffen können. Verteile Teams erfordern ein Umdenken in der Zusammenarbeit und neue Prozesse – darauf müssen wir uns einlassen. Tun wir es!