Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Nach 3 Tagen rings um Medien und Kommunikation, nun die Case Study diese Woche – Scrum bei den Experten für (Marken)Kommunikation.

Die Münchner Agentur P//MOD – ein Ableger der renomierten Agentur Publicis, die sich vor allem mit digitalen Medien befasst, arbeitet seit nunmehr fast einem Jahr mit Scrum.

Klar, nicht so einfach, schliesslich kennt man Anwendungsbeispiele von Scrum viel eher aus der Softwarebranche. Dennoch funktioniert Scrum auch hier sehr erfolgreich. General Manager Joel Flammann hat sich trotz dichtem Terminplans auf einer morgendlichen Autofahrt viel Zeit für ein ausführliches Gespräch genommen – wie ich finde, wirklich aufschlussreich. Ein Muss für alle, die glauben, Scrum ist eben “bloß” der Gegensatz zu Waterfall in der Softwareentwicklung. Irrtum. Lesen!  100721_casestudy pmod münchen

Nochmal herzlichen Dank!
Katrin Dietze
Hands on Design. Webteam

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Als Coach und Trainer werde ich immer wieder von Unternehmen gefragt, ob ich nicht ScrumMaster für sie hätte, und gleichzeitig fragen mich ScrumMaster nach Unternehmen, die ScrumMaster suchen.

Das hat mich schon vor drei Jahren auf die Idee gebracht eine Stellenvermittlung zu gründen. Nach einer kleinen Ewigkeit ist es endlich gelungen diese Idee wahr zu machen - Scrumjobs.com, nimmt ab sofort seinen Betrieb auf.

Wir können nun endlich die Brücke zwischen agilen Unternehmen und agilen Mitarbeitern schlagen.

Möglich war das nur, weil ich mit André Häusling einen Vollprofi im Thema Personal gefunden habe. Wir haben bereits bei WEB.DE erfolgreich zusammen Talente gesucht und gefunden. André hat sich u.a. auf die Beratung von IT-Unternehmen und IT-Profis spezialisiert und kennt die agile Welt seit langem.

Mit unserem neuen Unternehmen scrumjobs Boris Gloger und André Häusling GBR in Wuppertal bietet nun den Unternehmen viele einzigartige Vorteile:  Unternehmen profitieren von einem Netzwerk aus mehr als 3000 ScrumMastern, und vielen anderen Scrum Profis. Aus diesem Netzwerk wollen wir in Zukunft qualifiziert offenen Stellen besetzen. Stellen und Talente zusammenbringen ist dabei das Ziel.

Als Scrum-Talent bietet dir Scrumjobs: Den Kontakt zu vielen innovativen Unternehmen, die bereits mit agilen Methoden arbeiten.  Wir bieten aber vor allen ein kostenfreies, professionelles Feedback zu deinen Bewerbungsunterlagen und eine außergewöhnliche Karriereberatung, die dich ganzheitlich als Talent fördern will.

Wer mehr wissen will erreicht André direkt unter andre(dot)haeusling(At)scrumjobs.com oder per Telefon über: +49-177-4040661. Aktuelle Jobangebote findest du unter www.scrumjobs.com.

Boris Gloger

P.S.: Am 11.10.10 wird von uns erstmals ein Training zum Thema „Karriere als ScrumMaster“ angeboten. Trainingsort Wien.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Heute möchten wir euch ein paar weiterführende Links zum Thema Kommunikation als wesentliches Element im kreativen Prozess präsentieren:

1. Cirque du Soleil: The Spark (John U. Bacon, Broadway Business, 2006)

Dieses hochinteressante Buch beschreibt den kreativen Prozess als gemeinschaftliche Anstrengung anhand des erfolgreichsten Zirkus-Unternehmens der Welt (mit insgesamt mehr als 3.800 Mitarbeitern, davon fast 1.000 Artisten!) . Sehr lesenswert.

Hier auch ein kleines Youtube-Video zum Thema:

2. ABC Nightline – Ideo Shopping Cart

Dieses Youtube-Video zeigt die wohl einflussreichste Produktentwicklungs-Firma der Welt, Ideo (unter anderem der Entwickler der ersten Computer-Maus für Apple), bei der Entwicklung eines völlig neuen Einkaufswagen-Prototypen.

3. Catmull Ed (2008) How pixar fosters collective creativity (Harvard Business Review)

Ed Cutmull beschreibt in diesem Artikel die Prinzipien anhand derer das Animationsstudio Pixar die Arbeit ihrer hochkreativen Teams organisiert. Ein Muss für jeden, der verstehen möchte, wie Scrum Teams arbeiten.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Kaum eine andere Branche spiegelt die Veränderungen in der täglichen Arbeit, die durch neue Technologien, neue Informationskanäle und die Beschleunigung unserer Arbeitswelt entstehen, stärker wider als die Medien-Branche. Eng gesetzte Deadlines von Projekten extrem kurzer Laufzeit, gleichzeitig sich rasch ändernde Anforderungen und hohe (und steigende ) Qualitätsansprüche seitens der Kunden sind weniger die Ausnahme denn vielmehr Normalzustand. Darüber hinaus ist der Anteil an kurzfristig für Einzelprojekte hinzugezogenen externen Fachleuten und Arbeitskräften in dieser Branche besonders hoch.

All diese Aspekte stellen höchste Ansprüche an die beteiligten Personen. Nicht eingehaltene Termine, hohe Überstundenzahlen und in der Folge ständig sinkende Mitarbeitermotivation  - und damit Produktivität! – scheinen unabwendbare Konsequenzen. Kein Wunder, dass sich diese Branche durch eine besonders hohe Mitarbeiterfluktuation auszeichnet.

Dennoch kann Scrum genau hier seine spezifischen Stärken ausspielen.

Einen wichtigen Stellenwert nimmt dabei das Thema Kommunikation ein – nicht nur im Rahmen der zahlreichen “standardisierten” Meetings (Estimation, Sprint Planning, Daily Scrum, Review und Retrospektive), sondern auch generell durch seine Betonung des Team-Gedanken, der sich durch den Fokus auf ständigen Austausch, gemeinsames Arbeiten an einer Story und gegenseitiges kollegiales Unterstützen im Dienste des Gesamtergebnisses auszeichnet. Die Förderung der Eigenverantwortung des Einzelnen bewirkt die Stärkung der Identifikation mit dem Team und führt, gepaart mit einem möglichst hindernisfreiem Arbeitsumfeld, zu einer Steigerung der Motivation und der Freude an der Arbeit.

Kommunikation ist nicht nur innerhalb eines Teams von Bedeutung, sondern auch zwischen mehreren Teams, die, wie es in der Medien-Branche häufig vorkommt, gleichzeitig für einen großen Account arbeiten. Damit dies optimal funktionieren kann, kommen die Methoden der Skalierung zum Einsatz [1].

Ein zentrales und offen geführtes Company Backlog als strategisches Planungsinstrument zur Priorisierung der User Stories anhand des jeweiligen Business Values eröffnet jedem Einzelnen den Blick auf das große, gemeinsame Ziel, die Bedeutung des eigenen Handelns innerhalb dessen und gegenseitige Abhängigkeiten – gerade bei Agenturen wichtig, wo einzelne Stories durchaus ein gesamtes Projekt ausmachen können.

Die Zusammenstellung der Teams erfolgt interdisziplinär (auch um jedes einzelne Team unabhängig von Experten zu machen, die einem anderen Team angehören), ständiges gemeinsames Arbeiten an einer Story reduziert Wissensmonopole einiger weniger Schlüsselpersonen, die bei Agenturen oft externe Personen sind, die nur kurzfristig für spezifische Aufgaben hinzugezogen werden.

Alle Teams arbeiten in zu einander synchronisierten Sprints, intensive Abstimmungen zwischen den Teams (am Planning Tag und während der Sprints im Scrum of Scrums) wenden Missverständnisse ab und fördern das Erkennen von Synergien. Ständiger Austausch mit Kunden und Usern verhindert, dass an den Anforderungen eines sich in ständigem Wandel befindlichen Marktes “vorbeigearbeitet” wird.

—

[1] Das Thema Skalierung in Scrum wird in der Summer School in der Woche 6 ab 9. August intensiv behandelt.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Danke für den Dialog, in den ihr mit uns eingetreten seid. Die Summer School ist bereits jetzt ein voller Erfolg. Diese Woche schreiben wir über Kommunikation und Moderation,  in einer Case Study aus der Medienbranche wird gezeigt werden, wie effektiv Scrum in Unternehmen eingesetzt werden kann.

Man kann Nicht-Nicht Kommunizieren und doch Nicht-Kommunizieren.

Es ist doch spannend. Da reden alle immer davon wie wichtig Kommunikation ist, damit Teams miteinander arbeiten und dann sitzen Software-Entwickler mit Kopfhörern vor ihren PCs, so als wollten sie die Welt ausschließen und bloß mit niemandem Reden.

Ich denke: “Das ist absurd!” Combat-Teams und Sondereinsatzkräfte beispielsweise sind mit Permanent-Funk ausgerüstet. Alle wissen im Einsatz ständig, wer wo ist und was er gerade macht. Hocheffektive Teams kommunizieren ständig miteinander.

Der Unterschied zwischen einer Gruppe und einem Team besteht darin, dass bei einem Team die Teammitglieder ein gemeinsames, klar definiertes Ziel verfolgen; bei einer Gruppe jedoch gehört man zusammen, verfolgt aber kein gemeinsames Ziel. Nach dieser Definition sind die meisten Teams in der Industrie, vor allem in der Software-Entwicklung keine Teams. Teammitglieder, die sich in ihren Rechner vergraben, lieber im Home-Office vor sich hin arbeiten, und möglichst für sich abgeschlossene Aufgaben erledigen wollen, sind Einzelkämpfer in einer Gruppe.

Die neuen Arbeitsbedingungen der Moderne haben das Arbeiten in der Gruppe gefördert, nicht aber das Denken in Teams. Der Manager war Supervisor und sorgte dafür, dass in einer Gruppe jeder effektiv und effizient arbeitet. Mag das in einzelnen Branchen gängige Praxis sein und dort sogar sehr effizient und effektiv sein, so gilt das allerdings sicher nicht für  Software-oder Produktentwicklungs-Teams. Hier sind die Teammitglieder auf einer Mission und sollen so schnell und flexibel wie möglich das Produkt-Inkrement am Ende einer Missionsphase (=Sprint) liefern.

Für ein Team auf einer Mission gilt: Entscheidungen müssen schnell fallen, es braucht Klarheit über die zu erledigenden Aufgaben, es herrscht Vertrauen und jeder springt für den anderen ein. Das Missionsziel hat Vorrang vor Eigeninteressen. Das geht nur, wenn Teammitglieder ständig miteinander kommunzieren: Über Zielerreichung, Werte, Probleme, über ihre Ideen und Lösungen. Dabei ist Kommunikation nie Selbstzweck, sondern Medium des Austauschs von Status, Emotionen, Ideen und vielem mehr. Das letztendliche Ziel der Kommunikation ist das Selbstverständnis des Teams über sich selbst, über den Entwicklungsgegenstand, über Ergebnisse und über die zu erreichende Vision.

Menschen kommunizieren gerne, aber wieso verschwinden sie dann hinter Kopfhörern und Pflanzen? Weil Menschen nur dann miteinander reden, wenn es einen Zweck erfüllt. Wir reden auch nicht mit unserem Gartennachbarn nur weil er da ist. Sondern das Miteinander-Reden muss einen Sinn haben: Einen sachlichen und einen emotionalen Sinn.

Ob ein Scrum-Team eine Gruppe oder ein Team ist, zeigt sich spätestens in der Kommunikation des Teams bei Daily Scrum. Helfen sie sich, sind sie daran interessiert, was der andere tut? Oder “reporten” sie an den ScrumMaster? Sind sie eine Gruppe oder ein Team?

Die Aufgabe eines ScrumMasters ist es, solche Beobachtungen durchzuführen und nun dafür zu sorgen, dass a) die Kommunikation in Gang kommt und b) diese Kommunikation effektiv durchgeführt werden kann. Für beide Aspekte der Team-Kommunikation gibt es das Mittel der Moderation um den Kommunikationsprozes effektiv durchzuführen. Anstatt zum Beispiel bei Konfliktsituationen  die Team-Mitglieder miteinander reden zu lassen, wird durch Moderationmethoden der Konfliktgegenstand externalisiert und versachlicht.

Statt in Sprint Planning Meetings die Teammitglieder sich kommunikativ im Kreis drehen zu lassen, wird durch gelungene Moderation aus diesen Meetings kreative Brainstorming-Sessions. Statt bei Estimation Meetings die Teams zum Reden zu zwingen, entsteht durch gelungene Moderationstechniken das Gefühl, dass man miteinander Informationen austauschen kann, ohne sich “blamieren” zu müssen. In Gruppendialogen tendieren einzelne Personen dazu, sich hervorzuheben um den Dialog zu beherrschen. Das zu verhindern ist ebenfalls Teil der Aufgabe eines ScrumMasters. Wieder gilt es, durch geeignete Moderationstechniken dafür zu sorgen, dass jeder Einzelne gehört wird und sich durch die Gruppe gewürdigt fühlt.

Man kann nicht nicht kommunizieren, und doch nichts sagen.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Das war nun die zweite Woche unserer Summer School 2010, die sich mit Change Management auseinander gesetzt hat.

In der nächsten Woche befassen wir uns mit dem Thema Kommunikation und Moderation: Was macht aus einer Gruppe von Leuten erst ein funktionierendes, agiles Team? - mit vielen Denkanstößen, Tipps und Berichten aus der Praxis mit Scrum – diesmal aus der Medien-Branche.

Schönes Wochenende!
Wir sehen uns am Montag!

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Wird in Unternehmen Scrum eingeführt und etabliert, ist das verantwortliche Management auf allen Ebenen in besonderer Weise gefordert. Dies wird häufig zu wenig oder zu spät erkannt und dann zu wenig Management- und Führungsenergie in die Prozesse eingespeist.

Um diese spezifischen Herausforderungen zu meistern, bietet sich Management-Coaching in hervorragender Weise an. Damit kann situativ, zielgerichtet und praxisgerecht an strukturellen, methodischen und persönlichen (Entwicklungs-) Themen zum Umgang mit Führung im Allgemeinen und mit Scrum-Dynamiken im Besonderen gearbeitet werden.

Ein Beispiel aus der aktuellen Coachpraxis kann dies verdeutlichen:

Der CTO eines Versicherungsunternehmens führt Scrum auf breiter Basis in seinem gesamten Bereich ein. Er sieht inzwischen diesen Prozess als eine Change Management Maßnahme, die eine große Herausforderung an seinen gesamten Verantwortungsbereich darstellt. Trotz relativ schneller Erfolge ist er noch unzufrieden mit den Scrum Teams und anderen an den Prozessenbeteiligten. Er kann diese Unzufriedenheit jedoch nicht genau verorten und bringt dies als Thema in die Coachingeinheit ein. Sein individuelles Coaching als CTO sieht er als eine unterstützende Maßnahme in seiner Rolle als Change Leader.

In der Einstiegsphase der vierten Coaching-Einheit setzt er sich das Arbeitsziel “Klarheit über die Ursachen seiner diffusen Unzufriedenheit zu gewinnen und effektive Handlungsimpulse zur Verbesserung der Situation zu erarbeiten”.

Unter Einsatz verschiedener Coachingtechniken (untern anderem Skalentechnik und Einzel-Systemaufstellung) gewinnt er die Perspektive, dass in seinem Prozess der Scrum-Implementierung deutlich zu wenig Führungsverantwortung übernommen wird und spürbar ist. Dies sieht er sowohl bei sich, als auch bei den ScrumMastern der Teams und z.T. auch bei den PO’s. Er reflektiert intensiv die Spannungsfelder Autonomie und Führung/Hierarchie sowie Freiräume und Kontrolle und kommt für sich zum Ergebnis, dass ein Mehr an kompetenter Führung von allen Ebenen gebraucht wird.

Konkret nimmt er sich vor, die aktuelle Führungsthematik mit den ScrumMastern neu zu definieren und upzudaten (Rollen-Update). Feedback- und Kontrollelemente wird er gezielter vereinbaren und steuern. Er erwägt ein Seminar zum Thema Führungskompetenz für verschiedene Beteiligte an den Scrum Prozessen.

Der Geschäftsführer fühlt sich nun energievoller und handlungsfähiger, sieht, wo es nun lang gehen muss und wo er neue Prioritäten setzen will, und erlebt die Coachingeinheit für sich und sein System als sehr erfolgreich.

Dieses Beispiel zeigt auf, dass Change Management-Dynamiken auf unterschiedlichen Ebenen wirken und bearbeitet werden sollten. Dynamiken des Gesamtsystems von Teams oder beteiligten Individuen bilden eine Ganzheit, die die Prozesse beeinflussen.

Übrigens: in der nächsten Einheit will er sein individuelles Wertsystem erkunden und reflektieren.

Dieter Rösner
Executiv Management Coach
bor!sgloger Head of Training

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Für die vorliegende Case Study aus der Versicherungsbranche trafen wir in München Robert Weidinger, Leiter Bereich Informationstechnologie der Lebensversicherung von 1871 a. G. (LV 1871), zum Gespräch.

Neben der Präsentation, in der er die Geschichte von und mit Scrum in der LV 1871 darstellt, wollen wir vor allem Robert Weidinger selbst hier zu Wort kommen lassen. In seiner sehr offenen und direkten Art schildert er im Gespräch aus der Praxis mit Scrum. Es finden sich darin, wie wir meinen, viele hilfreiche Denkanstöße und Erfahrungen mit Scrum.

Danke für das Gespräch und die gewonnenen Einblicke!
Case Study als PDF hier herunterladen: casestudy_lv1871.pdf

Die vollständige Präsentation von Robert Weidinger können Sie hier als PDF herunterladen.

Jürgen Margetich
Head of Sales bor!sgloger

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Ihnen vertrauen wir unser Geld an: Banken und Versicherungen. Diese Branche muss uns allen ständig beweisen, dass sie solide, stabil und sicher ist. Als Kind verbinden wir die Bank noch mit dem Tresor, als Erwachsene vertrauen wir der Allianz, weil sie unsere Alterssicherung garantiert.

Dann, vor zwei Jahren, die Katastrophe. Giganten der Branche kommen ins Wanken und sterben. Das, was so sicher war, entpuppte sich plötzlich als ein von Menschen gemachtes System, das so fehleranfällig war und ist, wie jedes andere von Menschen gemachte Business. Sicherheitssysteme griffen nicht, weil das Unerwartete geschehen war.

Diese Krise hat auch dem letzten Gutgläubigen sehr klar gezeigt, dass auch die Banken und mit ihnen die Versicherungen von einem extremen Wandel betroffen waren und gegenwärtig noch sind. Die Finanzmärkte sind in den letzten zehn Jahren rapide zusammengewachsen und heute regiert der elektronische Handel über die Grenzen hinweg 24 Stunden am Tag die Geldflüsse. Das Frankfurter Börsenparkett, dass noch vor 15 Jahren existiert hat, wo man die Händler in Frankfurter Cafés sehen konnte, existiert nicht mehr.

Für uns kleinen Leute hat sich auch einiges getan. Erst gab es die Geldautomaten, vor 25 Jahren die Sensation, und dann das E-Banking, aus dem über einen Zeitraum von ca. zehn Jahren ein komplett neues Bankverhalten resultierte. Versicherungen werden heute ebenfalls von Direktversicherer im Web verkauft.

Wo die Abwicklung von Geldflüssen in jeder Hinsicht elektronisch geschieht, braucht es hoch effektive und effiziente, sichere und verlässliche IT-Infrastrukturen, logisch. Zunächst mit allem Geld der Welt von den Banken und Versicherungen mit gigantischen Investitionen bei den großen IT Beratungsfirmen eingekauft, wurde dort schnell klar, dass sich das nur bedingt rechnet. Nicht jede kleine Änderung darf gleich in die tausende gehen.

Eine deutsche Bank fragte uns bereits 2005, ob wir ihr Software Entwicklungsteam in Prag mit Scrum effektiver machen könnten. Dann gab es einige super innovative Banken in Dänemark, die rasend schnell ihre gesamte Entwicklungsabteilung auf Scrum umstellte. Dann hörte man 2007 plötzlich, dass die Allianz in München damit begann, Scrum zu machen.

Warum nur?

Meine Antwort darauf ist sehr einfach: die Versicherungen und Banken stehen unter einem enormen äußeren Druck. Dieser Druck ist viel höher, als wir vermuten. Erst als mir klar wurde (durch einen Kunden, der Trading Software entwickelt), mit welcher Geschwindigkeit gerade der Umbau der Börsen in Chicago und Singapur stattfindet, wurde mir deutlich, dass Geld und Manpower nicht ausreichen, um ganz Vorne mit dabei zu sein. Time-To-Market ist das große Problem der Banken und Versicherungen. Prozesse, die wie bei Versicherungen über 100 Jahre gewachsen sind, sind plötzlich viel zu langsam. Sie passen nicht mehr. Ein Konkurrent, der mit einer etwas besseren IT-Infrastruktur z.B. seine Makler bedienen kann, macht schnell Boden gut. So schnell, dass es dieser Industrie schwindlig wird.

Planung in instabilen Märkten, also auch jetzt im Banking- und Versicherungs-Business, wird unhaltbar. Es dauert zu lange auf Veränderungen zu reagieren. Schon greifen tradierte Planungs- und Investitionsmodelle, wie das viel zitierte Wasserfall-Modell, nicht mehr. Der Change in diesen Industrien hat bereits angefangen, erst unbemerkt von vielen, jetzt in einigen Teilen rasend schnell. Scrum ist meiner Meinung nach die Antwort: Hocheffektives (re-)Agieren mit einem Prozess, der zertifiziert und dokumentiert werden kann.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

In dieser Woche beschäftigt sich die Summer School mit dem weiten Feld des Change Managements, ein unerschöpfliches Thema. Wir versuchen dabei kontrovers zu diskutieren und wünschen uns euer Feedback. Auf eine heiße und sonnenreiche Woche!

“When we look around and see today’s companies and brands be set by distrustful customers, disengaged employees, and suspicious communities, we can link these problems to a legacy management style that lacks any real humanity,”[1, p. 4] schreibt Neumeier in seinem genialen Buch: “The Designful Company.”  Wir brauchen einen Weg, Unternehmen so zu verändern, dass Menschen in ihnen gerne arbeiten und ihr kreatives Potential nutzen können. Aber wie? Was können wir tun, damit nicht eintritt, was bei fast allen Change Initiativen eintritt: Das Versagen. Peter Senge, schrieb in “The Dance of Change”: “Most change initiatives fail” [2, p. 5] und zitiert mit Kotter, dass “…more than half did not survive the initial phase.” Das ist dramatisch.

Change Management funktioniert nicht?

Als ich in den letzten Wochen bei Teams und deren Managern war, bin ich immer wieder den gleichen Aspekten begegnet. Die Veränderung hatte angefangen. Es gab erste Erfolge durch die Einführung von Scrum, aber dann sind die Scrum-Initiativen ins Stocken geraten. Exakt das, was Kotter beschreibt. Die eigentlichen Erfolge – eine echte Produktivitätssteigerung – sind noch nicht eingetreten.

Ein Aspekt für den Stillstand ist sicherlich der, dass die DRINGLICHKEIT für die Änderung nachgelassen hatte. Bei einer großen Implementierung, die wir im letzten Jahr gemacht hatten, waren die Anfangserfolge derartig gut, dass das Top-Management erst einmal keine Veranlassung für weitere Verbesserungen gesehen hatte. Kotter nennt das Nachlassen der Dringlichkeit als Hauptursache für das Versagen der Change Initiativen [3]. Das Nachlassen der Dringlichkeit habe zwei Gesichter: Selbstgefälligkeit oder Selbstzufriedenheit (Complacency) und Aktionismus. Anstatt ernsthaftes, beständiges Arbeiten an dem nächsten wichtigen Problem wird viel Staub aufgewirbelt und mal schnell was verändert.

Wenn wir als Consultants aus Organisationen mit Dank entlassen werden, hat das oft genau diese Ursache. Wir sind zu erfolgreich in den ersten 8 Wochen und dann, wenn die eigentliche Arbeit erst anfängt, stoppt uns das mittlere Management.

Also lassen wir doch einfach den Change? Stoppen wir die Initiativen und machen einfach so weiter wie bisher? Vieles wäre einfacher und ich würde hier nicht sitzen und einen Artikel über das Versagen des Change Managements schreiben, sondern bei 30 Grad mit einem Aperol Spritzer am Donauufer sitzen.

Im Philosophie-Studium habe ich jedoch eine entscheidende Erkenntnis gewonnen: Wenn eine Frage immer wieder in eine Sackgasse oder zur gleichen Erklärung führt, die uns nicht weiterbringt, dann ist das Paradigma hinter der Frage falsch.

Welches Paradigma ist also falsch hinter dem Versuch die Veränderung herbeizuführen?

Meine Antwort darauf ist an diesem Abend, da ich diesen Post schreibe, sehr einfach: Die Idee, dass der Change beherrschbar sein könnte, dass man ihn managen kann. Der Grund dafür: Die Menschen, die von dem Change in irgendeiner Form betroffen sind, wollen nicht, dass man verändert. Sie wollen auch nicht selbst verändern. Warum auch? Eigentlich brauchen wir doch nur das freisetzen, was in ihnen steckt.

Wie man das macht? Meine verkürzte Antwort an diesem Abend: Indem wir alle, Menschen am Arbeitsplatz, in den Entwicklungsteams, in den Management-Etagen und in allen anderen Situationen im Arbeitsleben, beginnen, Hindernisse aus dem Weg zu räumen. Ganz pragmatisch und ohne große Change Programme.

Dazu braucht es nicht viel mehr als eine funktionierende Anfangsimplementierung von Scrum und einen ScrumMaster, der nicht aufgibt, existierende Hindernisse zu beseitigen.

Zu einfach? Stimmt … aber die Veränderungen, die dadurch geschehen, sind spürbar, signifikant und wirksam. Diese Erfolge erhalten die Motivation. Ein ScrumMaster kann dann Schritt für Schritt ein Problem nach dem anderen aus dem Weg räumen, bis hin zu einer Organisation, die den Mitarbeiter zuerst sieht und dann den Kunden. Change Management ist dann nichts anderes als kontinuierliches und beharrliches Verbessern hin zu einem neuen Status Quo.

[1] Neumeier, 2008, The Designful Company: How to build a culture of nonstop…

[2] Peter Senge, Nicholas Brealey Publishing: London, 1999

[3] John P Kotter, A Sense of Urgency, Harvard Business Press, 2008

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Das war die erste Woche unserer Scrum Summer School, die wir wie alle kommenden mit einem Cartoon ausklingen lassen.

Das Wochenthema “Warum Scrum?” hat offenbar einen Nerv bei euch getroffen, wie die zahlreichen Kommentare auf unserem Blog und direkte Gespräche mit euch gezeigt haben.

Wir werden daher im weiteren Verlauf der Summer School ganz speziell auch auf diese Frage immer wieder eingehen.

Die kommende Woche widmet sich nun dem Thema “Change Management“, das wir anhand der Versicherungsbranche mit zahlreichen Tipps, Praxisberichten und weiterführenden Informationen beleuchten werden. Stay tuned!

Aber für diese Woche ist’s genug! Ab ins Wochenende und viel Spaß am Strand, an der Bar oder beim Public Viewing, was immer ihr vorhabt!

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

An dieser Stelle: Donnerstags werden wir versuchen, das Wochenthema mit weiterführendem Material zu beleuchten. Hier sind Tipps für Bücher, Präsentationen und weitere Informationen zu finden. Dieses Material beansprucht keine Vollständigkeit. Wenn ihr noch mehr Quellen habt, wäre ich für die Info dankbar. Boris

1. Start with Why, ein Buch von Simon Sinek. Einfach gut geschrieben. Wer zum Lesen bei diesen Temperaturen zu faul ist, oder sein neues iPad ausprobieren mag, dem sei dieses Video ans Herz gelegt:

www.youtube.com/watch?v=qp0HIF3SfI4

2. Das Buch Re-Imagine von Tom Peters ist ein Must Read. Wer lieber themenbezogen liest, dem seien die Auskopplungen aus diesem Buch -- The Essential Series - empfohlen.

3. Die Präsentation von Salesforce.com “A Year of Living Dangerously” habe ich bereits erwähnt.

4. Das Buch: Niels Pfläging, Führen mit Flexiblen Zielen, Campus 2008, ist ebenfalls ein Quelle der Inspiration. Pfläging erklärt uns schonungslos, dass jede Form der Leistungsbewertung falsch ist. Dass Führung nur über Flexible Ziele erfolgen kann und muss und dass wir die Mitarbeiter vor die Kunden stellen müssen.

5. Ich kann nur immer wieder betonen: Es ist wichtig dir Ursprünge von Scrum zu kennen. Das Lesen des ersten Buches von Ken Schwaber und Jeff Sutherland, Agile Development with Scrum, ist obligatorisch, wenn man sich mit Scrum auseinandersetzen will. Es erklärt die Ideen hinter Scrum und gehört zur Geschichte von Scrum.

6. Ein umwerfend gutes Buch ist Kimball Fischer, Leading Self Directed Work Teams. Grandios ist, wie er erklärt, was alles benötigt wird und wie man solche Teams tatsächlich führt.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Es freut mich sehr, dass unsere Summer School so toll angenommen wird. Das Feedback in den Blogs, die ihr alle schreibt, bestärkt uns darin, dass es wichtig ist, die Gründe hinter Scrum aufzuzeigen. Zu zeigen, dass tatsächliches Verändern ein gutes Stück Arbeit ist. Heute ist, wie jeden Mittwoch in den nächsten 8 Wochen, der Tag der Case Study. Also: Wie hat eine Firma Scrum erfolgreich implementiert.

Steve Green von Salesforce.com erklärte uns 2009 beim Scrum Gathering in Stockholm, dass sie nicht ein wenig Scrum gemacht hatten, sondern gleich aufs Ganze gesetzt hatten. Sie standen damals vor der Wahl, ihre Projektmanagement-Praktiken zu intensivieren, oder einen anderen, einen ganz anderen Weg zu gehen. Sie entschieden sich für den ganz anderen Weg, der hier sehr gut beschrieben ist:

Was sich in der Präsentation nicht findet, ist ein Gespräch, das ich mit Jodok Batlogg, ehemaliger CTO vom StudiVZ, Berlin letzte Woche hatte. Er hatte sich auf meine Vermittlung hin mit Steve Green getroffen und herausgefunden, wie die Wirklichkeit bei Salesforce.com aussah. Demnach hatte Salesforce, nach 2008 sogar noch viel massiver Scrum eingesetzt. Salesforce hat konsequent Teams aus jeweils 5 Personen eingesetzt, jedes dieser 5 Personen-Teams hat einen Product Owner. 5 Product Owner bilden ein PO-Team und jeweils 5 dieser Teams bilden gemeinsam eine eigene Business Unit. Salesforce bestehe aus 4 dieser Business Units. Spannend finde ich, wie konsequent sie sind. Sie betreiben nun ein firmenweites Scrum und haben alle Geschäftsbereiche in Scrum integriert.

Sie arbeiteten die Aspekte, auf die sie während der Scrum Implementierung gekommen waren, auf. Das lässt sich in der obigen Präsentation wunderbar sehen: Nach der initialen Implementierung von Scrum stoppen sie erst einmal, nachdem sie bemerkt haben, dass sie zu schnell unterwegs waren. Anschließend konzentrieren sie sich systematisch auf die verschiedenen Aspekte der Software-Entwicklung und bringen die Dinge nach und nach in Ordnung.

Ein Resultat, das sich aus der obigen Präsentation auch lesen lässt, ist, dass es Salesforce.com gelungen war, langsam aber sicher ihre technische Schuld abzuarbeiten. Ob sie damit schon fertig sind, weiss ich nicht, das spielt auch keine Rolle. Wichtig ist, sie gehen jeden Tag einen Schritt in die richtige Richtung.

Einer unsere Kunden versucht seine technische Schuld dadurch abzuarbeiten, dass sie 30% jedes Sprints für neue Architektur und Refactoring reservieren. Nein, sie machen das nicht, weil sie es toll finden, sondern weil sie wissen, dass sie diese Investitionen heute leisten müssen, wollen sie ihre Produkte am Leben erhalten.

Morgen werden wir euch an dieser Stelle vertiefendes Material zum Thema: “Warum Scrum”, zur Verfügung stellen.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Vielen Dank für das tolle Feedback auf meinen ersten Artikel “Warum Scrum?” gestern. Es freut mich sehr, dass ich euren Nerv getroffen habe. Heute möchte ich mit der Reihe über die Branchen beginnen. Natürlich beginnen wir mit der Software-Entwicklungsbranche. —-

Warum Scrum in der Software-Entwicklung? Ein Branchenbericht

Software ist allgegenwärtig. In Produkten, in denen man es nicht vermuten würde, ist heute Software drin. Oft stellt die Software den eigentlichen Mehrwert des Produktes.

So schön das iPad ist, ohne die  Software wäre es nur ein Stück Hardware, das auch andere Firmen so erzeugen könnten. Neue Software-Technologien und Software-Produkte: Facebook, Twitter, Navigationssysteme: all das verändert die Weise, wie wir Menschen kommunizieren und leben.

Die Branche Software-Entwicklung, also jene Firmen, die Software für andere herstellen, hat sich in den letzten Jahren massiv verändert. Sie ist gewachsen, und sie musste gleichzeitig damit umgehen lernen, dass Firmen ihre Aufwände für die  Entwicklung von Software massiv reduzieren. Heute gibt es kaum noch eine Software-Entwicklungsfirma, die nicht mit Outsourcing-Modellen arbeitet.

Diese so extrem schnell arbeitende Branche, die so vieles in den letzten Jahren geleistet hat, steht jedoch vor einem Dilemma. Wir brauchen einerseits verlässliche Aussagen darüber, was wir von einem Software-Entwicklungsprojekte erwarten können und gleichzeitig benötigen wir von diesem Entwicklungsprojekt Dinge, die es noch nie gegeben hat. Fast jede kleine Neuentwicklung in der Software-Entwicklung ist schlussendlich auch Forschungsarbeit.

Die traditionellen Methoden des Managements, des Projektmanagements und des Software-Engineerings sind für diese Herausforderungen nicht ausgelegt. Die Ideen, auf denen sie aufsetzen,  sind mehr als 50 Jahre alt und waren von noch älteren Prinzipien des Managements und den Ingineurwissenschaften abgeleitet.  Software-Entwicklungsprojekte werden heute mit Methoden erzeugt, die auf Prinzipien, die während des beginnenden 20. Jahrhunderts entwickelt wurden, beruhen.

Diese Methoden gehen von der Grundannahme aus, dass ein “Arbeiter” das tut, was man ihm sagt, und dass man seine Arbeit planen müsse.  Obwohl Peter Drucker bereits vor 40 Jahren geschrieben hat, dass dieses Modell des Arbeitens der Arbeit des Wissensarbeiters nicht adäquat ist, wird dieses Denken noch immer weitergeführt. Es führt im Bereich der Software-Entwicklung u.a. zu einem, meines Wissens in der Nicht-Software-Entwicklung unbekannten Problem: dem Technical Debt (der technischen Schuld). [1]

Die technische Schuld ist ein in der Software-Entwicklung immer wieder beobachtetes Phänomen. Da es oft nur möglich ist, alle gewünschten Funktionalitäten in einem Projekt zu liefern, wenn Teams etwas für die Güte des Produktes an sich Notwendiges nicht tun, entsteht ein Berg von Arbeit, die nicht getan worden ist. Dazu gehört sehr oft: 1. nicht geschriebene Dokumentation, 2. nicht durchgeführte Verbesserung der Architektur durch Code-Pflege und oft 3. nicht durchgeführte Tests.

Das führt nach einigen Jahren dazu, dass die Geschwindigkeit, mit der die Software in einem Projekt erstellt wird, langsamer und langsamer wird. Anders ausgedrückt: es werden vom gleichen Team immer weniger Funktionalitäten im gleichen Zeitraum erstellt. Dieses Phänomen kann man wunderbar an dieser Folie [2] erkennen:

Die Features Delivered per Team (gelbe Kurve) zeigt kontinuierlich nach unten.

Dieses Phänomen kennt jeder Software-Entwickler, der mit Legacy Code konfrontiert wird. Den Code seines Vorgängers zu lesen ist oft sehr schwierig und oft ist es nicht möglich, alle Abhängigkeiten des gerade zu verändernden Software-Codes zu erkennen. Der vielzitierte Spaghetti-Code hat dann in die Software Einzug gehalten.

Scrums Forderung, dass ein Team die Qualitätshoheit hat, war von Anfang an der Versuch dafür zu sorgen, dass keine technische Schuld aufgeladen wird. Die Forderung nach potentially shippable code war nicht zuletzt die Idee, dass die Entwicklung immer so durchgeführt werden müsse, dass alle Arbeiten getan worden sind, um das Projekt am Ende eines jeden Sprints prinzipiell abbrechen zu können.

Durchführbar ist dieser Anspruch allerdings nur, wenn man den Leuten, die die Software schreiben, vertraut – dahingehend vertraut, dass diese am besten wissen, wann ein Stück Software soweit ist, tatsächlich potentially shippable zu sein.

Vertrauen ist aber dabei in unserer Industrie genau das Gegenteil von dem, was gelebt wird. Fest-Preis/Fix Date-Projekte, Kunden, die auf klare Lieferungen drängen, bevor sie wissen, was sie wollen, auf der einen Seite und auf der anderen Seite Software-Entwicklungsfirmen, die aus Zeitdruck die Features liefern, obwohl sie wissen, dass sie nicht stabil entwickelt sind, sind immer noch an der Tagesordnung. In diesem Umfeld darauf zu vertrauen, dass mir mein Lieferant ein hohe Qualität liefert, ist oft fatal und wird häufig auch mit teuren Nacharbeiten bezahlt.

Wie Scrum dabei helfen kann, wieder Vertrauen zu erzeugen, sehen wir morgen am Beispiel von Salesforce.com und eigenen kurzen Beispielen.

—–

[1] http://en.wikipedia.org/wiki/Technical_debt

[2] Quelle: Salesforce.com, A Year of Living Dangerously. Scrum Gathering 2009

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

I found a wonderful article written by Jurgen on his blog: NOOP.NL about the ideas behind agile [1].

Ideas, concepts, beliefs, theories, ideologies, fads, and fashions are often called memes. People copy these units of information from each other through mimicry, interaction, correlation, teaching, and learning. Santa Clause is a meme; the Christmas tree is a meme; putting presents in stockings (or in shoes as we do here in Holland) is a meme; Rudolf the Red-Nosed Reindeer is a meme; the birth of Jesus Christ is a meme; and angels and elves are all memes.

and further: It is the same with rules, procedures, and practices for software development. They are ideas, concepts and beliefs that people copy from each other through mimicry, interaction, and learning. Stand-up meetings are a meme; pair programming is a meme; refactoring is a meme; iterative development is a meme; and user stories are a meme. Memetics is the study of evolutionary models of information transfer, often in a cultural context. What he say in the later of the article is ….

[1] http://www.noop.nl/2010/02/the-success-of-the-agile-memeplex.html

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Tom Peters schreibt im Vorwort seines Buches “Re-Imagine”[1] er sei wütend. Er habe versucht die Manager weltweit darauf aufmerksam zu machen, dass das traditionelle Verständnis zu Mitarbeiterführung und Management falsch sei. Aber allem Anschein nach sei das vergebens gewesen.

“So why am I sitting inside, scrunched over a makeshift writing desk … cranking out Book Number 11? Because I´m pissed off. (…) My overall rant, in brief: People … in enterprise, in government … are by and large well intentioned. They´d like to get things done. To be of service to others. But they´re thwarted … at every step of the wary … by absurd organizational barriers … and by the egos of petty tyrants (be the corporate middle managers, or army colonels, or school superintendents).”

Ich bin auch wütend. Wütend darüber, dass die Ideen, mit denen Scrum einmal – von den Begründern und der ersten Scrum Garde: Mike Cohn, Jeff Sutherland und Ken Schwaber – gestartet wurde, 2010 in den Hintergrund treten.

Wir haben ein Problem. Scrum wird selbst zum Establishment. Die Scrum Alliance verhält sich langsam aber sicher wie jede andere Organisation und hat mit Scrum.org ihre Konkurrenten bekommen. Mit Scrum.org greift Ken Schwaber massiv die Organisation an, die er mit uns allen 2004 in Boston aus der Taufe gehoben hatte, um die Welt zu verändern. Jetzt schreibt Ken Schwaber aber, es ginge ihm nur um die Professionalisierung der Software Entwickler [3], und vergisst, zumindest in diesem Paper, dass er einmal die Welt ändern wollte.[4]

Was ist passiert, dass plötzlich Mike Cohn in einem seiner letzten Posts schreibt, dass Stundenschätzungen vollkommen in Ordnung seien. Ich meine, wir versuchen seit Jahren von dem Fluch der Aufwandsschätzungen weg zu kommen. Es gelingt uns langsam und dann schreib er: “So, story points are about the effort involved. Feel free to adjust your estiamte of effort based on things like risk and uncertainty, but point-based estimating is about the time the work will take. It’s what our clients, bosses, customers, and stakeholders care about.” [2] Das ist in meinen Augen Aufgeben vor dem Establishment.

Ich nehme die großen Scrum Gurus als Hinweis dafür, dass sich in der Scrum Community etwas verändert hat. Scrum wird von mehr und mehr Zuschauern als geschlossenes System betrachtet. Mehr und mehr Blogs greifen uns an und behaupten, dass Scrum nur ein Business sei, dass einige wenige reich mache.

Schaut man genauer hin, hat die Scrum Community das selbst verschuldet. Die Scrum Trainer haben es jahrelang nicht geschafft, ein transparentes System zu erstellen, nach dem Trainer zertifiziert werden. Die Scrum Alliance reagierte und hat nun mit Hilfe von Tobias Mayer dafür gesorgt, dass es tatsächlich einen neuen Prozess gibt. Doch diese Organisation beginnt sich, wie schon oben erwähnt, als “Organisation” zu verhalten. Prozesse werden etabliert und es wird nun nicht mehr geschaut, dass das Richtige getan wird, sondern, es sieht immer mehr so aus, als würde es wichtiger sein, Dinge richtig zu tun.

Das Obige und noch vieles mehr hat mich in den letzten Wochen dazu veranlasst darüber nachzudenken, warum ich Scrum 2002 angefangen hatte und weshalb ich so fasziniert davon war. Ich habe mich auf die Suche nach den Gründen für Scrum gemacht. Das Warum wollte ich finden. Auf der Suche danach bin ich natürlich auch auf das gestoßen, was Mike Cohn in seinem neuen Buch für das “Warum Scrum?” dazu schreibt. Basierend auf der Story von Salesforce.com und dem  Agile Chronicle Report von Version One (der ist selbstverständlich objektiv und wissenschaftlich abgesichert), nennt er aber meiner Meinung nach die Resultate, die entstehen, wenn eine Firma sich mit Scrum diszipliniert auseinandersetzt.  Vergisst aber dabei die eigentlichen Gründe für Scrum zu erwähnen. Gründe, die uns 2003 auf der ersten Agile Development Conference nur zu deutlich bewusst waren. Sicher ist es gut, wenn mal jemand deutlich aufzeigt, dass die Einführung von Scrum für viele viele Firmen erhebliche Verbesserungen gebracht hat. Es ist auch gut, wenn Mike endlich einmal diese fünf Verbesserungen qualifiziert und zumindest versucht sie zu quantifizieren:

1. Höherer Produktivität und geringere Kosten
2. Verbesserte Mitarbeiterzufriedenheit und -engagement
3. Schnelleres time-to-market
4. Höhere Qualität
5. Verbesserte Stakeholder-Zufriedenheit [5]

Aber – wie immer, wenn man die Ergebnisse und nicht die Motive betrachtet – findet man nur die Erscheinung, nicht das Wesen.

Die Beschäftigung mit der Gestaltung meiner drei Unternehmen in diesem Jahr, führte mich zurück zum Kern meiner Beschäftigung mit Scrum. Hilfreich bei dieser Reflexion war das sehr empfehlenswerte Buch von Simon Sineks “Start with Why” und sein extrem gut gemachter TED Vortrag.[6] Sinek erinnert daran, was es wirklich zu finden gilt: Die Antwort auf das Warum.

Warum machen wir Scrum?

Was ist der Traum hinter dem Gedanken, sich auf Scrum einzulassen? Es geht nicht darum zu sagen, dass wir Scrum machen, weil wir bessere Software schreiben wollen. Allenfalls erzielen wir bessere Ergebnisse, weil wir so arbeiten, wie es erwachsenen Menschen entspricht.

Warum also gerade Scrum? Wir befinden uns in einer Zeit extremer Veränderungen. Wie vor 100 bis 120 Jahren verändern sich gerade unsere Lebensumstände vollständig. Neue Technologien, tiefgreifende Umwälzungen der globalen Wirtschaftsstrukturen und das Bedürfnis der Menschen nach Sinn, Zugehörigkeit und dem Willen etwas zu erreichen, führen zu vollkommen neuen Aspekten des Zusammenlebens.

Die Grenzen Europas werden offener und offener, die Grenzen der USA schließen sich mehr und mehr. Die Vermischung der Kulturen wird in Europa zur Regel. Wir arbeiten mit Afrikanern, Osteuropären, Skandinaviern und vielen anderen ethnischen Gruppen in Teams zusammen. Interkulturelles Arbeiten ist heute in wissensbasierten Berufen Tatsache des Arbeitslebens. Gleichzeitig wird der War for Talents stärker und stärker. In Europa fehlen mehr und mehr qualifizierte Menschen, die diese Veränderungen bewirken und tragen können.

Wir brauchen in diesen Zeiten eine Art zu Arbeiten und eine Organisation von Unternehmen, die menschenzentriert ist. Es geht um Organisations- und Arbeitsformen, die:

1. Orientierung schaffen
2. Zugehörigkeit vermitteln
3. Das Gefühl von Stolz vermitteln, etwas erreicht zu haben
4. Freiheiten in Rahmenbedingungen setzen
5. Klarheit erzeugen
6. Freude und Sinn schaffen.

Ken Schwaber hat das mal gewusst. Er hatte uns in den ersten Trainings immer wieder erklärt, was seine Beweggründe für die Beschäftigung mit Scrum waren:

1. Er wollte die amerikanische Software-Entwicklungs-Industrie retten.
2. Er wollte allen zeigen, dass es wesentlich produktiver und effektiver sei, die Produkte im eigenen Land, nahe am Kunden zu entwickeln, nicht weit entfernt und outgesourced.
3. Er erklärte uns einen weiteren Grund für Scrum: Seine Tochter, erzählte er, hätte ihm nach einem Praktikum in der Software Industrie erklärt, dass sie nicht in einer Branche arbeiten wolle, in der ständig gelogen werde, in einer Industrie in der sich niemand auf niemanden verlasse.
4. Er wollte errreichen, dass die Software Entwickler qualitativ hochwertig arbeiten und fertige Produkte liefern.

Alles in Allem: Er wollte die Industrie retten.

Die agilen Ideen, die von allen Vertretern der Agile Community im Jahr 2003 auf der Agile Development Conference in Salt Lake City vertreten wurden, hatten mich damals begeistert. Der Versuch den Status Quo zu ändern war ein lohnendes Ziel.

Mir war zu diesem Zeitpunkt nicht klar, dass wir es schaffen könnten, aber es ist gelungen, oder?!

Ich schreibe diese Zeilen mit gemischten Gefühlen. Ja – auf dem Papier ist es gelungen: 90.000 Certified ScrumMaster, hunderte Firmen, die mit Scrum begonnen haben. Mehr und mehr Menschen strömen in meine Trainings und immer mehr Firmen rufen mich an, weil wir ihnen helfen sollen, Scrum richtig zu machen.

Doch haben sich die Organisationen schon geändert? Hat sich die Idee einer neuen Arbeitskultur schon durchgesetzt? Ich bezweifel es. Die Antwort lautet, denke ich: Nein!

Die neue Art und Weise miteinander zu arbeiten ist noch immer ein zartes Pflänzchen, die sich zwar sehr tapfer hält, und man kann diese Pflanze vielen Firmen finden. Diese haben die Zeichen der Zeit erkannt und wollen ihre Mitarbeiter anders behandeln. Sie setzen dort an, wo man ansetzen muss, am Paradigma des Managements ihrer Firma. Sie werfen überholte Ideen über Bord, verlassen die Pfade der traditionellen Unternehmensführung und hören nicht hin, wenn ihnen die großen Unternehmensberatungen erklären, wie es sein sollte. Sie haben erkannt, dass es um eine neues Paradigma geht. Ein Paradigma, das noch nicht 100% erforscht ist.

Erich Harsch, Vorsitzender der Geschäftsführung dm-drogerie markt, Karlsruhe, sagte in der Brand Eins: ”Der Mensch steht im Mittelpunkt unseres Tuns und nicht die Gewinnmaximierung. Dazu gehören Transparenz, Vertrauen und dass wir aus Betroffenen Beteiligte machen. Nach unserer Auffassung sind die Menschen, die bei dm arbeiten, nicht für das Unternehmen da, sondern das Unternehmen für die Menschen, damit sie in einer Gemeinschaft einen aktiven Beitrag zum Wohlergehen aller Bürger leisten können. Darin unterscheiden wir uns von anderen Unternehmen: Denn für uns ist Ertrag nicht das Ziel, sondern die Folge unserer Zusammenarbeit.” [7] Eine Ausnahmehaltung, für die das Unternehmen mehrfach ausgezeichnet wurde.

Die Mehrzahl der anderen Firmen ist durch die Erfolge bei der Einführung von Scrum nur angefixt. Diese Firmen schicken ihre Mitarbeiter in Scrum Trainings, weil sie von Salesforce.com’s gigantischer Produktivitätssteigerung gehört haben. Sie sehen nur die Resultate und wollen den Quick Win, ohne die harte Arbeit zu tun, die es erfordert. Hier wird das Label Scrum aufgeklebt und dann mit dem neuen Mittel, agil, versucht, noch mehr aus den bereits überarbeiteten Mitarbeitern herauszupressen.

Es gibt Firmen, die sich der harten Arbeit stellen, die zum Beispiel mit einem Modell wie Scrum den einfachen aber sehr harten Weg gehen und sich nach dem neuen Paradigma des Zusammenarbeitens organisieren oder es zumindest versuchen. Diese Firmen haben heute schon extreme Wettbewerbsvorteile. Sie sind profitabler als ihr Wettbewerb: Southwest Airlines, Google, Svenska Handelsbanken, Toyota, Semco, dm-drogerie markt und andere tun es mit Scrum oder einem ähnlichen Ansatz.[8] Salesfoce.com, der StudiVZ, Immobilienscout24 und viele andere Firmen, Firmen, die wir zum Teil betreuen, haben sich auf die lange Reise mit Scrum gemacht. Die Manager in diesen Firmen haben erkannt, dass es nicht um den kurzfirstigen Erfolg geht. Sie alle haben ein Warum für sich erkannt, dass sie natürlich so schnell und effektiv wie möglich erreichen wollen. Sie setzen auf die Kreativität ihrer Mitarbeiter, versuchen ernsthaft Verantwortung dorhin zu delegieren, wo sie hingehört, und stellen sich den auch in ihren Unternehmen tradierten, überkommen Paradigmen der Moderne.

Scrum ist das einzige mir bekannte Werkzeug, das uns dabei hilft, die humanistischen Ideen darüber, wie Menschen in modernen Organisationen arbeiten sollten, in die Organisationen zu tragen. Scrum ist daran orientiert, worum es geht: Leistung und Vertrauen in die eigenen Fähigkeiten.

Dieser Artikel hat unsere Summer School eröffnet, denn ich möchte Euch in diesem Sommer nachdenklich am Strand vorfinden. Wie wollt ihr arbeiten, wenn ihr aus dem Urlaub zurück kommt? Was wollt ihr anders machen? Wo und wie kann euch Scrum, oder die vielen anderen Hinweise, die wir Euch in den nächsten acht Wochen präsentieren werden, helfen, selbstbestimmt zu arbeiten und zu leben?

—

[1] Tom Peter, Re-Imagine, Business Excellence in a Disruptive Age, DK Adult, 2006
[2] Mike Cohn, Mike Cohn’s Blog – Succeeding with Agile
[3] Das ist meine Meinung, die ich mir basierend auf mangelhaften Informationen gebildet habe. Es ist eine subjektive und vielleicht falsche Meinung. Aber es ist meine Meinung.
[4] http://www.scrum.org/originsofscrumorg
[5] Mike Cohn, Succeeding with Agile, Software Development using Scrum, Addison-Wesley, 2010
[6] You Tube
[7] Brand Eins, Ausgabe 06/210, Schwerpunkt: Auf Sicht. Was machen Sie in 10 Jahren? – Teil 1
[8] Nils Pfläging, Führung mit flexiblen Zielen, Frankfurt: Campus, 2008, S. 24

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Die Sommerpause ist für viele die Zeit des Abschaltens vom Alltagsstress. Wir finden Ruhe, tanken neue Kräfte und nehmen uns Zeit für unsere Träume. Oft reisen wir in ferne Länder, denn wir sind offen für neue Eindrücke. Wir suchen nach neuen Erfahrungen, wollen unser Leben bereichern.

Viele nehmen auf ihre Reisen leichte Sommerlektüre mit, um auch geistig mit Spass ein wenig Neues zu lernen. Diese Gedanken, entstanden auf einer Reise in Cornwall vor ein paar Wochen, führten mich zu der Idee, Euch in diesem Sommer eine kleine Summer School zu bieten. Vielleicht ist euch das viele Liegen am Strand ab und zu einfach zu langweilig, vielleicht probiert ihr euren neuen iPad aus, oder ihr wollt einfach ein paar amüsante und neugierig machende Gedanken lesen.

Die Motivation für meine Summer School ist vielschichtig und facettenreich, aber im Kern ist mein Wunsch, euch die wunderbare Welt des Scrum mit anderen Paradigmen zu zeigen. Einen großen Teil dieser Überlegungen mögt ihr schon kennen, vielleicht wart ihr in einem meiner Certified ScrumMaster Trainings, oder kennt mein Buch. Viele Ideen sind aber so sicher noch nicht aufgeschrieben worden.

Was wird euch beim Lesen dieser Summer School erwarten?
Ein Ausblick auf die nächsten acht Wochen.

Die erste Woche ist dem Versuch gewidmet, einen Blick auf das eigentliche „Warum?“ hinter Scrum zu werfen. Ein Warum, dass sich von dem unterscheidet, was derzeit durch viele Manager, viele Bücher und unzählige Artikel im Netz verbreitet wird.

In Woche 2 geht es um das Thema Change Management. Wie verändert man mit Scrum ein Team, eine Organisation und ein Unternehmen?

Woche 3 widmet sich dem Team. Wie steuere ich die Kommunikation im Team? Wie führt man Meeting effektiver durch?

Woche 4 beschäftigt sich mit der Teamentwicklung. Wie motiviere ich ein Team, geht das überhaupt?

Woche 5 befragt einen Anwalt, der uns zeigt, wie man einen agilen Software Development Vertrag aufsetzen könnte.

Das große Thema Skalierung, wird uns in Woche 6 beschäftigen.

Woche 7 bringt dann die Überlegungen zum Thema Scrum und Festpreis und in der abschließenden Woche 8, werden wir über die Gesellschaftsutopie hinter Scrum sprechen. Über das Menschenbild und die Ideale, die erreicht werden könnten.

Viel Spass mit der Summer School 2010 wünscht euch
Boris Gloger

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Scrum Master (m/w), Standort Frankfurt/ M. — Für einen unserer Kunden suchen wir zum nächst möglichen Zeitpunkt in Frankfurt  einen Scrum Master.Verantwortung:- Du übernimmst die organisatorische und methodische Verantwortung für ein Scrum Team- Dank Deiner Einsatzbereitschaft und ausgeprägten Lösungskompetenz führst Du das Team in enger Abstimmung mit dem Product Owner und dem Management durch den Prozess- Du förderst eigenverantwortliches Arbeiten im Team und unterstützt die laufende Implentierung von Scrum im UnternehmenWeitere Informationen bekommst Du gerne auf Anfrage bei: Andre.Haeusling AT scrumjobs.com

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Senior Java Developer (m/f), Location Munich, Pforzheim or Cologne — for one of our customers, an innovative and technology oriented IT consultant, we are searching for an experienced Senior Java Developer.  Responsibilities:  project leadership for exciting software projects in the area of innovative Business-Systems-Conception and implementation of software architecture in Java-EE-area consulting and support of customers and colleagues in Software projects. More information available upon request at: Andre.Haeusling AT scrumjobs.com

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Scrum Master (m/w), Standort Hamburg — Für einen unserer Kunden, der im Bereich Online-Gaming sehr stark am wachsen ist, suchen wir einen erfahrenen Scrum Master.Verantwortung:- eigenverantwortliche Umsetzung von agilen Software-Projekten- Entwicklung und Planung der Projekte sowie die Aufteilung der Rollen- Koordination und Abstimmung der Works Streams mit anderen Scrum MasternWeitere Informationen bekommst Du gerne auf Anfrage bei: Andre.Haeusling AT scrumjobs.com