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.

Ein guter Teamleader hält sein Team immer bei Laune, ist doch klar! Und dank der Scrumlies wissen wir jetzt auch, wie man die Sache richtig angeht! ;-)

Das war nun Woche Vier der Summer School, Halbzeit also. Nächste Woche behandeln wir das Thema “Scrum & Vertragswesen” das wir am Montag mit einem spannenden Leitartikel von Marcus Antonius Hofmann, Rechtsanwalt aus München, einleiten werden.

Ein schönes Wochenende, wir sehen uns nächste Woche!

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.

Unser Kunde, ein bekanntes und erfolgreiches WEB 2.0-Unternehmen, sucht am Standort in Berlin einen Product Owner (m/w).

Verantwortung: Du bist für die Entwicklung eines Teilbereichs verantwortlich. Dabei nutzt Du Markt- und Nutzeranalysen, um tragfähige Produktkonzepte zu entwickeln und bisherige Funktionalitäten auf Basis interner Analysen kontinuierlich zu verbessern.

Du übernimmst die inhaltliche Führung eines dedizierten Entwicklungsteams, mit dem Du, der Scrum-Methodik folgend, neue Funktionalitäten für die Plattformen umsetzt. Du bist Ansprechpartner für externe Entwicklungspartner sowie interne Kunden aus den Bereichen Marketing, Sales und Software Development.

Du solltest sehr gutes technisches Fachwissen mitbringen und ganzheitlich am Social Media Phänomen interessiert sein.

Deine Kompetenzen und Erfahrungen:

• Abgeschlossenes Studium im wirtschaftlichen oder technischen Bereich
• Mind. 4 Jahre Erfahrung im Internet Product Management oder in einer Agentur ausgeprägtes technisches Verständnis, insbesondere zu Frontend-Themen
• Tiefes Verständnis von Business Modellen im Internet
• Sehr gute Kenntnisse gängiger Analyse-Tools und damit einhergehend ausgeprägte analytische hervorragende Kommunikationsfähigkeiten und diplomatisches Geschick
• Hohe Durchsetzungsfähigkeit sowie hohe Belastbarkeit Scrum-Erfahrung von absoluter Vorteil

Bei Interesse bitte melde dich bei André Häusling von www.scrumjobs.com: andre.haeusling@scrumjobs.com

Dieses Posting ist eine Anzeige.

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.

Was macht eigentlich ein “gutes” d.h. effektives Team, z.B. ein Scrum-Team aus? Sicher sind es viele Faktoren, die vorhanden sein und zusammenspielen müssen. Ein wesentliches und erwünschtes Element “guter” Teams ist sicher das, was man allgemein als Teamgeist (manchmal auch Wir-Gefühl) bezeichnet. Teamgeist wird immer wieder regelrecht beschworen, und es wird an die Teams appelliert, doch (mehr) Teamgeist (im Sinne einer eher moralischen Kategorie) zu zeigen.

Jedoch, Teams haben keinen Geist, schon gar nicht in der Initialphase. Sie entwickeln, gestalten und pflegen ihn ganz handfest als permanenten Prozess und, wenn vorhanden, als positiv erlebtes, emotionales Phänomen. Teamgeist ist zum einen ein interner Zustand, der aus fundierter Kollegialität souveräner Individuen ent- und besteht.

Zentrale Basis für diesen erwünschten Prozess ist ein erfahrbares Wachsen von Wertschätzung, Respekt, Vertrauen, Zuverlässigkeit, Disziplin, Sicherheit und Aufeinander bezogen sein. Diese Teamgeist-Basis entwickelt sich durch gemeinsames Handeln, durch das gemeinsame Erbringen von Leistungen und konkreten Ergebnissen und zum zweiten durch dauerhafte kollektive und individuelle Erfolge und Erfolgsfeedback. Aber Achtung: oft wird dabei der individuelle Erfolg zu Gunsten des Teamerfolges geringer geschätzt oder bewertet.

Die Anerkennung individueller Leistungen und Erfolge im Rahmen der Teamleistung (durch die übrigen Teamkollegen) stärkt die individuelle Souveränität und damit die Komponenten Wertschätzung, Vertrauen ineinander und gegenseitiger Respekt. Im gemeinsamen Tun und Erfolgserleben realisieren sich Zugehörigkeitsgefühl, Zusammengehörigkeitsgefühl, Solidarität, Loyalität, Akzeptanz von Heterogenität, Dialogprozesse und Bereitschaft zu offener Auseinandersetzung und es gestalten sich Teamidentität und Teamgeist.

Teamgeist stabilisiert sich des Weiteren durch Zuschreibungen aus dem Team-Kontext.  Wenn einem Team direkt oder indirekt zurückgemeldet wird, dass es als spezifisches Team x/y wahrgenommen und erlebt wird, entsteht Identitätsfeedback. Dieses führt zur Klärung des Selbstbildes und zu einer für den Teamgeist zwingend notwendigen Grenzziehung nach außen. Laterale Teamführung, d.h. Teamführung ohne direkte disziplinarische Macht, sozusagen ”Führung von der Seite her”, unterstützt gezielt die beschriebenen Variablen zur Entwicklung von Teamgeist (z.b. im Daily Scrums, Retrospektiven, Impedimentprozessen, in der Kommunikation von Erfolgen nach außen, usw.) Sie macht Stolpersteine und Blockierungen für Teamgeist-Entwicklung (wie mangelnder Kontakt, zu wenig oder unangemessene  Kommunikation, nicht geklärte Konflikte, Egoismen, zu wenig Anerkennung, blindem Kollektivismus, etc.) transparent und unterstützt Teams dabei, sie gezielt zu bearbeiten.

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 der Woche über Leadership und Teams in Scrum eine ganz besondere Case Study. Der “Fall” ist in diesem Falle nämlich kalt. Diesmal nicht der aktuelle Blick auf die eigene Firma, sondern ein Resumee über Leasons Learned. Wir sprechen mit Jodok Batlogg über seine Erfahrungen mit Teams und Organisation als Leiter einer grossen Entwicklermannschaft, die mit ihm als CTO erfolgreich auf Scrum umgestiegen ist.

100728_case study jodok batlogg

Wir sind gespannt auf die Kommentare zu diesem Thema.
Trifft so agil denken  auch bei euch wunde Punkte?

Jodok, nochmal ein herzliches Danke für deine Zeit,
ich bin schon neugierig auf dein nächstes Wirkungsfeld!
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.

Soziale Netzwerke wie Facebook, XING, Linkedin und StudiVZ sind entstanden, weil eine Handvoll Leute begonnen hat, eine Vision sehr schnell umzusetzen. Sie waren erfolgreich und sind gewachsen und gewachsen. Plötzlich stehen diese Organisationen im Spannungsfeld von traditionellem Management und innovativer Führung. Entstanden aus einer Idee und einem Impuls heraus waren sie sehr erfolgreich, haben Neues ausprobiert und dabei alle Regeln über Bord geworfen. Mark Zuckerberg (Facebook-Gründer) scheint sich an Regeln absolut gar nicht halten zu wollen, wie ich seine Äusserungen zum Thema Datenschutz interpretiere.

Sind die social networks erfolgreich und haben ihren ersten Proof of Concept erfolgreich hinter sich, dann kommen die Investoren. Mit Ihnen kommen dann die traditionellen Business-Regeln und mit ihnen die traditionellen Kontroll-Systeme. [1]

Plötzlich sehen sich die Menschen in diesen Organisationen mit einer neuen Anforderung konfrontiert: es wird erwartet, dass man plant und Erfolge garantiert. Die Firmenspitze muss sich nun vor ihren Investoren rechtfertigen.

Dabei ist das in einem Spiel, das niemand beherrscht, in einem Business, das es vor zehn Jahren noch gar nicht gab, mit Technologien, die von den Menschen in diesen Organisationen gerade erfunden werden, doch im Wahrheit vollkommen illusorisch.

Gelingt es diesem Druck zu entkommen – bei Facebook hatte Zuckerberg sich geweigert zu verkaufen und blieb selbst an der Spitze – schlägt das Pendel dann zu innovativer Führung aus. Ein Führungsstil, der nicht von jedem gemocht wird, ist dieser doch oft sehr diktatorisch. Doch der Vorteil liegt auf der Hand: Hier werden Dinge ausprobiert. Zuckerberg verzichtet auf Roadmaps und kreiert neue Paradigmen für seine Architektur. Einerseits liegt die Verantwortung so tief wie möglich, andererseits setzt er einige Dinge auch einfach durch.

Bei anderen sozialen Netzwerken, die nicht das Glück hatten den Investoren zu entgehen, schlägt das Pendel in Richtung traditionellem Management aus. Hier werden zwar Innovation gefordert, diese aber in Gremien und Lenkungsausschüssen kaputt geredet. Es werden mittlere Management-Ebenen eingezogen, konzernartige Strukturen geschaffen und klassisches Berichtswesen etabliert.

Das Problem ist also, so wie Dieter gestern schrieb, dass es Führung geben muss, soziale Netzwerke aber eine andere Form von Führung erfinden müssen, als es die klassischen Management-Methoden lehren, wollen sie weiterhin in der Lage sein, innovativ das Neue zu erfinden.

Gerade sie wären dazu ideal geeignet, denn sie sind aus dem Paradigma des Netzwerks entstanden. Sie haben die Infrastruktur erzeugt, die es benötigt, um kollaborativ über Distanzen hinweg zu arbeiten, haben dabei jedem Individuum im Netzwerk eine Stimme gegeben und Bewertungskriterien geschaffen, die es der Gemeinschaft erlaubt, den Einzelnen hervorzuheben und die Einzelleistung zu würdigen. Ihre Bewertungsmechanismen sind nicht hierarchisch und sie erzeugen Führung durch Gefolgschaft. So wird eine Page oder eine Person zu einen “Meinungs-Hub” und damit zu einem Führenden. Seth Godin nennt diese Leute die Begründer von Stämmen.

Wie sähe eine Vision für soziale Netzwerke aus?

Es müsste den Netzwerken gelingen, diese Mechanismen innerhalb ihrer eigenen Strukturen zu leben. Das könnte bedeuten, dass die neuen Features nicht von oben bestimmt werden, sondern sie von den Mitarbeitern und den Usern eingebracht werden. Welches Feature als nächstes käme, bestimmten dann die Mitarbeiter und sie würden sie, sähen sie realistisch aus, schnellstmöglich umsetzen und dem Netz aussetzen.

Wäre dieses Feature ein Erfolg, bliebe es im Netzwerk verfügbar, wenn nicht, dann baute man es später wieder aus. Würde dieses Feature so sehr nachgefragt, dass mehr und mehr Services dieses Feature benötigten, dann entschiede das Management ob es in die funktionale Social Network Plattform integriert würde. So führte die Firma die Community in die Richtung, die zur eigenen Vision und zur Community passt.

Leider ist die Realität eine andere. Die sozialen Netzwerke in Deutschland verlieren meiner Meinung nach ihre Innovationskraft. Sie werden zu sehr durch traditionelle Businessmodelle gebremst. Manager verlangen klare Roadmaps, Features sollen sich rechnen und dem Kunden soll das gebaut werden, was er verlangt. Team-Leader werden eingezogen, die ersten Hierarchien entstehen und Verantwortliche werden gesucht. Druck, nicht aus der Gruppe, sondern von oben wird erzeugt, denn nun müssen plötzlich Deadlines gehalten werden. Das Management beginnt Absprachen mit Managern zu treffen, ohne vorher mit denen zu reden, die es besser wissen. Entscheidungen werden zentral getroffen. Die sozialen Netzwerke werden intern zu etwas, was sie extern anprangern: eine langweilige, selbstgefällige, tayloristische Organisation.

Das kann man ändern und diese Bewegung aufhalten. Wir haben in den letzten drei Jahren gesehen, dass Firmen des frühen Internetzeitalters mit Scrum wieder die Fahrt aufnehmen können, die sie hatten, als sie begannen. Hier spreche ich von den großen Netzwerken und Portalen in Deutschland (alle namhaften deutschen Internet-Companies, setzen inzwischen auf Scrum – ob Facebook Scrum ausprobiert hat? Keine Ahnung!).

Scrum bietet den idealen Startschuss für jede Firma hin zu mehr netzwerk-orientiertem Arbeiten. Scrum bot diesen Firmen aber auch einen eleganten Ausweg, sie konnten diese Form des Arbeitens auf die Entwicklungsabteilungen beschränken. Warum eigentlich? Warum haben Grafiker, Produkt-Designer und wie sie alle heißen, eigentlich ein Problem damit, ihre Abteilungen auch dem Netzwerk-Gedanken zu unterwerfen und die Basis ihrer Existenz, das Netzwerk, im eigenen Unternehmen zu leben?

Ich habe darauf keine klare Antwort, aber eine Vermutung: Es geht wieder um Macht. Das Netzwerk löst jede Form von traditionellem Machtverständnis auf. In den meisten Firmen wird die IT als Dienstleister gesehen. Unterwerfe ich diesen Dienstleister einem System, das mehr Kontrolle bei gleichzeitigem Machtentzug verlangt, ist das eine gewaltiger Machtzuwachs. Selbst aber die eigene Stellung in einem Netzwerk zu hinterfragen, ist nicht nur unbequem, sondern erzeugt einen originären Machtverlust. Hier liegt die absolute Schwäche eines jeden netzwerkbasierten Ansatzes, also auch der von Scrum. Scrum ist out-of-the-box nicht in der Lage, dem mittleren Management einen Gewinn anzubieten, der den Machtverlust ausgleichen würde.

Firmen, die mit Scrum beginnen, müssen daher über Scrum “hinausdenken” und sich  mit ihren Strukturen ganzheitlich auseinandersetzen.

Morgen lesen wir, was uns Jodok Batlogg zum Thema Scrum und Social Networks erzählt. Freuen wir uns drauf.

[1] Google, liest man die Google Story richtig, ist diesem Dilemma entkommen, weil die Gründer von Anfang an zwar das Geld genommen haben, sich aber nie reinreden liesen.

[2] Niels Pfläging nennt die modernen Firmen in “Führen mit flexiblen Zielen” so.

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 Case Study über P/Mod in München hat eine tolle Diskussion über Störungen, während des Sprints ergeben. Es freut uns, dass ihr die Summer School so rege verfolgt. Diese Woche beginnen wir das Thema Teamführung zu beleuchten. Dieter schreibt im Leitartikel über Führung in Scrum Teams. Boris wird im Branchenbericht über Führung im Sozialen Netzwerken schreiben, unser Case Study wird den StudiVZ beleuchten und wie immer bringen wir weitere interessante Aspekte zum Thema am Donnerstag. Ich freu mich schon jetzt auf das Cartoon von unserem Cartoonisten Joachim am Freitag. Das letzte Cartoon in Anlehnung an die drei Affen war ein echtes Highlight.

“Teamführung in Projekten – vorgesetzt oder selbst gewählt?” von Dieter Rösner

Verfolgt man die politischen Prozesse seit der letzten Bundestagswahl 2009 in Deutschland, kann man ein faszinierendes Phänomen zum Thema Führung wahrnehmen: Von den Medien und anderen

“Experten” wird ein massives Führungsvakuum beklagt und die Führungsfunktion Nummer 1 – die Bundeskanzlerin – aufgefordert, “endlich Führung zu übernehmen”. Dies scheint aber irgendwie nicht zu gelingen.

Hier wird ein spezifisches Dilemma demokratischer Systeme deutlich: die starke Abhängigkeit der Führung von den Geführten, sprich den Wählern. Jede demokratisch gewählte Führung kann wieder abgewählt werden (und entnimmt den wöchentlichen Trendmeldungen ihre Einflussstärke). Daher ist sie mittelfristig bemüht, ihre Wähler “gnädig” zu stimmen (siehe Wahl in NRW) und verliert damit leicht die notwendige Führung aus den Augen. Wird aber nicht “gut” geführt, nimmt dies der Wähler auch wieder übel, und es kommt zu Vertrauensverlust und dem Abrutschen auf der Beliebtheitsskala, ganz zu schweigen vom Autoritätsverlust im Führungsteam (Regierung, siehe “Gurkentruppe, Chaosverein, Wildsau” etc.) – also ein echtes Dilemma politischer Führung in demokratischen Systemen. Ausgeglichen wird dieser “Schwachpunkt” durch das Agieren von Opposition, Medien usw., die hier als Regulativ wirken und größere “Katastrophen verhindern”.

Wo ist nun der Zusammengang dieser politischen Führungsthematik zu Teamführung bzw. lateraler Führung durch einen ScrumMaster?

Immer wieder wird die Frage aufgeworfen (z.B. auch in Scrum-Trainings), ob es nicht im Sinne von Selbstorganisation sinnvoller wäre, wenn sich Teams ihre Führung (oder den ScrumMaster) selbst wählen würden. Diese Frage ist m.E. mit einem klaren Nein zu beantworten.

Führung soll hier definiert werden als gezielte und legitimierte Einflussnahme auf Andere (Mitarbeiter) im Interesse eines übergeordneten Systems zu Bewältigung definierter Aufgaben und Leistungen. Eine gewählte Teamführung in diesem Sinne  kommt zwangsläufig in ein ähnliches Dilemma wie eine politisch-demokratische Führung, nämlich in starke Abhängigkeit von den Teammitgliedern. Die notwendige Führungsdistanz ist nicht oder nur bedingt zu gewährleisten und damit die Einflussnahme eingeschränkt. Es gibt keine legitimierten Regulative (siehe oben), die im Falle einer Führungskrise (z.B. Autoritäts- oder Vertrauensverlustes, Machtkonflikten usw.) die Situationen im Sinne des übergeordneten Systems gezielt und kompetent klären können. Beobachtbare Phänomene sind dann Chaotisierung, Verwahrlosung, Leistungsabfall, Auflösung.

Ein vom Management vorgesetzter Teamleiter (ScrumMaster) hat eine legitimierte Positionsmacht, ist nicht direkt abhängig vom Team (obwohl Teil desselben) und kann damit distanzierter Führung übernehmen und den situativ notwendigen Einfluss ausüben. Bei kritischen Teamsituationen sind die hierarchischen Interventionen der “Einsetzer” der Teamleitung das Regulativ, das im Interesse das Systems problemlösend handelt (oder handeln sollte). Zum Beispiel durch Stärkung der Leitung, Moderation oder durch Ändern der personellen Situation.

Vor- bzw. eingesetzten Teamleitern ist zu empfehlen, ihre Funktion und ihren Status  selbstbewusst zu vertreten und kein “schlechtes Gewissen” zu haben, auch in diesem Falle sind sie ein genuiner Teile der Selbstorganisation des Teams. Den Einsetzern ist zu empfehlen, sich ihrer Rolle als Regulativ bewusst zu sein und bei Bedarf gezielt und kompetent zu intervenieren.

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.

Auch die Scrumlies wissen, wie man gut im Team kooperiert: indem man Kommunikation groß schreibt … Und es dabei belässt :-)
Und jeder macht was er will, keiner macht, was er soll, aber alle machen mit.

Das war also nun die Summer School Woche 3 zum Thema “Kommunikation und Moderation”.

In der nächsten Woche beschäftigen wir uns mit Teamführung und Teamentwicklung. Der Leitartikel am Montag stellt die Frage, ob ein Teamleader von seinem Team gewählt oder ihm vorgesetzt werden sollte. Wir sind schon auf eure Meinungen dazu gespannt…

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.