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 Version 2010 der Scrum Checklist ist auf InfoQ erhältlich!

Ein nicht druckbares PDF steht hier zum kostenlosen Download bereit.

Die gedruckte Version hat die ISBN 978-3000282010 und ist über den Buchhandel erhältlich oder direkt von uns. Preis €9,95 + Versandkosten. Bestellung bitte per Email an bernadette.christ(at)borisgloger.com.

Die Edition 2010 ist bald ausverkauft, also bitte jetzt ordern!

Related posts:

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 Thema Skalieren, auch über Ländergrenzen hinweg, ist heute mit Hilfe von Scrum für Organisationen gelöst, ausprobiert und in der Praxis erfolgreich umgesetzt.” Oh ja, auch Santa weiß, wie man das angeht.

Das war also die Summer School Woche No. sechs, Thema “Scrum und Skalierung“.

Nächste Woche geht es weiter mit der Problematik rund um “Festpreis und Scrum”. Es bleibt spannend!

Das bor!sgloger Team wünscht euch allen ein schönes Wochenende!

Related posts:

• Summer School Weekly Cartoon: Teamführung
• Summer School Weekly Cartoon: Scrum und die Preisgestaltung
• Summer School Weekly Cartoon: Kommunikation

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.

Diese Woche beschäftigt sich unserer Summer School mit dem Thema Scrum und Skalierung anhand der Immobilienbranche. Heute gibt es wie jeden Donnerstag dazu weiterführende Hinweise.

1. salesforce.com – eines der Musterbeispiele für Skalierung. Eine äußerst interessante Präsentation dazu (wir haben auf sie schon in unserer ersten Summer School Woche hingewiesen) ist auf slideshare.net einsehbar und sehr empfehlenswert.
2. Ebenfalls bereits in unserer Summer School präsentiert haben wir die Case Study “Scrum bei Infonova – 80 Teammitglieder auf einem Nenner?”
3. Firmen wie 3M und Gore sind wunderbare Beispiele, wie man wächst in dem man klein bleibt: diese Firmen teilen sich dann, wenn sie mehr als 100 Mitarbeiter beschäftigen.
4. Es gibt eine Firma, die die ABCD – Methodology für Risk Management lehrt und trainiert. Absolut genial und ich kann es jedem nur empfehlen. Wir werden es ab 2011 auch in unserem Programm führen.
5. Das Wiener Unternehmen ERESNET GmbH setzt bei der Entwicklung von IMMOBILIEN.NET, Österreichs größter Immobilienplattform im Internet, und WEBREAL, Österreichs führender Maklersoftware, auf Scrum.
   “Wir haben uns schrittweise weiterentwickelt: Zuerst führten wir einzelne Elemente ein, wussten aber schon kurze Zeit später, dass wir Scrum mit seinen Bestandteilen für alle Developer Teams einsetzen wollen. Die Resultate: Seither entwickeln wir schneller, mit deutlich höherer Termintreue und in vielfach besserer Qualität als früher – unsere nächste Herausforderung ist nun die Abstimmung aller Teams miteinander.“ meint Johannes Mayer, Produktmanager Portale und Online Werbung

Related posts:

• Summer School Weekly Cartoon: Warum Scrum?
• Summer School Weekly Cartoon: Rechtssicherheit
• Ab 5. Juli auf unserem Portal: Die bor!sgloger Summer School 2010

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 Kathedralen, die wir sie heute in Wien, Paris oder London sehen, sind nicht in ein paar Jahren gebaut worden, sie sind auch nicht in zwei oder drei Jahrzehnten gebaut worden, sondern oft über ein bis zwei Jahrhunderte hinweg. Oft hat ein Baumeister die Vollendung seiner Kathedrale nie erlebt und an den Bauwerken, moderner Luftverschmutzung ausgesetzt, werden noch heute ständig Restaurationsarbeiten durchgeführt. (Die Dombauhütte zu St. Stephan, Wien, beschäftigt heute 20 Mitarbeiter.)

Mal eine ganz andere Betrachtung zum Thema Software:

Das Wesen der Software-Entwicklung aus der Sicht der Organisationsentwicklung ist durch viele Aspekte gekennzeichnet. Software-Entwicklung ist ein Prozess, Software-Entwicklung ist eine kreative Tätigkeit des Einzelnen wie des Teams, Software-Entwicklung ist aus der Sicht des Soziologen aber vor allem ein sozialer Prozess in dem es um Machtverhältnisse geht.

Es gibt aber noch einen ganz anderen Aspekt: Software-Entwicklung selbst ist Arbeit an der Organisation.

Als wir 2008 bei einem großen Portal Scrum eingeführt haben, machte Robert Schmidt [1], Soziologe am Sonderforschungsbereich “Kultur des Performativen” der Freien Universität Berlin, den wir und unser Kunde einluden, eine Scrum-Implementierung durch das bor!sgloger Team zu begleiten, eine faszinierende Feststellung: Er verglich das Arbeiten an der Software des Unternehmens – also an dem, was das Portal ausmachte – mit dem Arbeiten an der Geschichte des Unternehmens.

Erst war nicht deutlich, was er meinte, dann wurde es aber glasklar. Die Software Entwickler wühlten sich durch den “alten” Code der Organisation. Das Arbeiten an der Software erforderte das Lesen “alter” Texte, denn diese waren wiederum oft von Menschen geschrieben, die bereits seit langem das Unternehmen verlassen hatten. Norman Kerth [2] hatte mich schon 2004 in Wien beim Retrospective Gathering darauf hingewiesen, dass Software Entwicklung in einigen Teilen daraus bestünde, archäologisch herauszuarbeiten, welche Aspekte von Wissen in dem “alten”, teilweise vergessenen Code steckten.

Laut Robert Schmidt machten diese “alten” Texte die Geschichte des Unternehmens und damit das Wesen des Unternehmens aus. Viele Software-Entwicklungsteams befassen sich zum Großteil in ihrer Arbeit nicht mit den Neuentwickeln von Applikationen, sondern sie verändern bereits bestehende Software-Applikationen. Oft fügen sie hinzu, sie verändern oder sie bauen ganze Software-Applikationen um, ohne jedoch die Funktionalitäten zu verändern.

Diese Arbeit kann und muss als eine Arbeit “an-sich-selbst” gesehen werden. Denn die Menschen in dieser Organisation arbeiten mit der Einführung von Scrum nicht nur an ihrer neuen Art Software zu schreiben, sondern vor allem daran, das Wesen ihrer eigenen Organisation umzugestalten. Conways Law [3] besagt, dass “…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

Wird also die Architektur der Software durch veränderte Kommunikationsstrukturen verändert, so hat das auch eine Konsequenz für die Menschen in der Organisation selbst. Die Menschen in diesen Organisationen verändern dann ihr Verhalten, ihre Art miteinander zu arbeiten und zu kommunizieren. Ihre Sicht auf die Welt hat sich verändert.

[1] Robert Schmidt, “Praktiken des Programmierens — Zur Morphologie von Wissensarbeit in der Software-Entwicklung, Zeitschrift für Soziologie, Jg. 37, Heft 4, August 2008, S. 282-300

[2] Norman Kerth, Project Retrospectives

[3] http://en.wikipedia.org/wiki/Conway’s_Law

Related posts:

• Warum Scrum in der Software Entwicklung? Branchenbericht
• Modellgetriebene Entwicklung — Irrungen und Wirrungen
• 5 min on Scrum | Business Value

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.

Mal ehrlich. Die Vorstellungskraft darüber, wann und wo Scrum gut einsetzbar ist, endet oft bei einem einzelnen Team, das mehr oder minder für sich selbst entwickelt. Dass mit Scrum auch in anderen Dimensionen erfolgreich entwickelt wird, zeigt in dieser Case Study Oliver Zeiler, CTO von ImmobilienScout 24, dem größten Immobilien Onlineportal Deutschlands. Und er kann es belegen. Die Produktivitäts- und Qualitätssteigerungen sind nicht nur empfunden sondern gewogen und gemessen! Und sie lassen sich sehen. Anzahl der Bugs halbiert, Produktivität vervierfacht. Ein Beispiel, das sowohl hinsichtlich Ergebnis als auch Umsetzung von Scrum in skalierten Umfeldern anspornen mag.

Case Study hier lesen: 100805_casestudy immobilienscout24

Vielen Dank an Oliver Zeiler für diesen Beitrag! Allen Lesern darf das Erfolgsrezept von Immobilienscout 24: Konsequenz, Kommunikation und Managementinvolvement fest ans Herz gelegt sein.

Jürgen Margetich,
Head of Sales

Related posts:

• Case Study, we are sorry
• Case Study: Scrum im Umfeld eines traditionellen Versicherungsunternehmens
• Case Study: Scrum bei Infonova – 80 Teammitglieder auf einem Nenner?

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.

Große Teams, große Projekte, unterschiedliche Standorte — mit diesen Fragen beschäftigt sich die Scrum Summer School diese Woche. Es geht los mit einer Geschichte der Skalierung. Morgen werden wir erzählen, wie die Immobilienbranche beginnt, Scrum zu entdecken. Am Mittwoch, unserem Case Study Tag, berichtet uns Oliver Zeiler vom ImmobilienScout 24 über seine Erfahrungen mit Scrum. In den Ergänzungen zu dieser Woche am Donnerstag gibt es wie immer weiterführende Literatur und am Freitag zeigen uns wieder die Scrumlies ihre ganz eigene Meinung zu großen Projekten.

Oliver Zeiler, heute der CTO des ImmobilienScout 24, fragte mich vor 5 Jahren, als er für die Einführung von Scrum bei der BenQ-Mobile verantwortlich war, ziemlich provokativ: “Dass Scrum auf Team-Ebene funktioniert interessiert mich nicht, ich will wissen, wie funktioniert Scrum bei Multi-Side, Multi-Projekt und Multi-Teams?” Herzrasend und aufgeregt, weil ich den Auftrag unbedingt haben wollte, entwickelte ich auf seinem Whiteboard in 40 min ein Skizze dazu, wie es gehen müsste. Ein Bluff. Er und ich wussten damals, dass ich keine Ahnung davon hatte, wie man das machte.  Es gab einfach keine Erfahrungen darüber, wie man 180 Software Entwickler, die Projekte aus drei Standorten bekommen, die gleichzeitig operativ Bug-Fixing betreiben und noch neue Produkte entwerfen sollten, mit Scrum steuert. Dass die Product Owner in München und nicht in Wroclaw saßen, war dann nur noch ein Detail.

Die von Oliver Zeiler gestellte Frage war, damals wie heute, die Kernfrage, die uns bei der Einführung von Scrum in Organisationen und Abteilungen gestellt wird. 2005 ließ ich mich noch ins Boxhorn jagen. Die Behauptung der Projektmanager damals wie heute war und ist, dass die klassischen Methoden das von Zeiler geschilderte Problem lösen könnten. Das traditionelle Management in den Firmen behauptete ferner, dass sie mit Hilfe von Portfolio-, Programm- und Multiprojektmanagement große und sehr komplexe Projekte beherrschten und dass Scrum erst einmal beweisen müsse, es könnte all das auch.

Electronic Data Systems, EDS, brachte mir, dem Junior Projektmanager, 1999 eine Riskmanagement-Methode, die ABCD-Methodology, bei, mit der EDS seit 1996 internationale Projekte sehr erfolgreich im General Motors Umfeld durchgeführt hatte. Mit dieser Idee war es möglich, durch den monatlichen Abgleich der Annahmen zu den Projektgegebenheiten ein Projekt über die Ländergrenzen zu steuern. Für mich war das immer eine Frühform von Scrum gewesen, aber dort traf man sich nur einmal im Monat.

Als ich mit Oliver Zeilers Problem konfrontiert worden war, die Bedingungen am Standort Wroclaw gesehen hatte und unbedingt eine Lösung für das Managen von 8 Product Ownern brauchte, saß ich abends grübelnd im Restaurant. “Was wäre, wenn die POs sich auch als Team sähen? Dann hätten wir ein PO-Team. Wenn ich jetzt die gleichen Prinzipien anwende, wie die bei einem Scrum-Team und mir klar mache, es geht wieder nur um die Annahmen der einzelnen Projektbeteiligten, und es muss darum gehen, diese Annahmen  durch die Realität zu bestätigen oder zu widerlegen, dann … KLICK”

Das Meta-Prinzip der Skalierung war entstanden. Kurz darauf, entwickelte ich das PO-Daily Scrum mit dem Product Owner Scrum Board und 2006 kam dann noch das Multi-Team Sprint-Planning dazu.

In Wroclaw gab es noch einen Aspekt, den ich nicht auflösen konnte. Peter Beck und Andreas Schliep, damals meine Mitarbeiter in Wroclaw, die dieses Prinzip umsetzten, wurden damit konfrontiert, dass ein Team aus mehreren Projekten Anforderungen abarbeiten musste. Wir kreierten als Lösung auf diese Anforderung die Idee der Team-Backlogs, die vom Product Owner des Teams priorisiert werden. Ständig hatten die POs mit auf Business-Seite wechselnden Anforderungen zu kämpfen. Diese Idee war ok, aber nicht wirklich ausreichend, aber wir hatten keine andere. Ohne bessere Vorgehensweise entwickelte mein damaliges Software Entwicklungsteam bei Sprint IT ein Tool. Ein sinnloses Unterfangen.  Wir waren noch selbst in der alten Projektmanagement-Denke verhaftet.

Etwa gleichzeitig mit dieser Entwicklung konfrontierte mich ein paar Monate später ein Kunde mit einem anderen Problem: Seine Teams wurden vom Management gezwungen, sich ständig zu verändern, weil die Verkäufer im Sales ständig Projekte für eine Technologie verkauften, obwohl sie gar nicht die richtigen Skills in den Teams hatten. Damals beschäftigte mich die Tatsache, dass wir noch glaubten: Man könne Teams nach jedem Sprint umstellen: Leute dazugeben, sie wieder entfernen und so die Teams den Projekten anpassen. Das war aus der alten Ressourcen-Zuteilungssicht des Programm- und Multiprojekt-Sicht verständlich, und wurde so von Ken und anderen auch gelehrt. Aber dieses Vorgehen hatte einen entscheidenden Nachteil: Wir würden ständig die Teams dazu zwingen, in die Forming-Phase zurückzufallen. Absurd, wenn man High-Performance Teams kreieren will.

Was würde passieren, wenn ich bei meinem Kunden das Kern-Paradigma von Scrum – kleine Teams – nicht anrühre und die Teams also stabil hielte. Damit würde ich die Grundlage des klassischen Multi-Projektmanagements, das Ressourcen per Managementdiktat zuteilt, zerstören. Ich hätte zwar kein Teammitglied mehr, das an mehr als einem Projekt arbeitet, aber dann könnte ich die Projekte des Sales auch nicht abarbeiten. Ich drehte mich im Kreis.

Ein paar Tage später stand ich vor der  Passkontrolle in Denver, USA. Hier wurde die Cueing -Theorie konsequent angewendet. Die Durchschnittsdurchlaufzeit des Einzelnen in der Schlange wird geringer, wenn man die Reisenden erst ganz am Ende der Schlange auf die Abarbeitungsstationen, den Zöllnern,  verteilt. Also eine lange Schlange anstatt vieler kleiner Schlangen. Aber das reichte nicht, um mein Problem zu lösen, Goldraths Buch war mir seit 1999 bekannt und ich hatte diese Idee schon einmal verworfen. Aber an diesem Morgen in Denver, beobachtet ich die Zöllner, die seelenruhig in ihrer extrem langsamen und pedantischen Art  die Reisenden abfertigten. Kein Stress war zu sehen und dennoch wurde die Schlange in einem stetigen Rhythmus kleiner. Der Zöllner winkte einen Reisenden ran, wenn er fertig war.

“Moment”, dachte ich, “er winkt uns ran … er winkt den Reisenden ran.” Dieser Gedanke kreiste in mir und kreiste und … Peng! Da war die Lösung für mein Problem: Die Teams bleiben stabil und sie entscheiden, was sie sich als nächstes in ihren Sprint hineinziehen. Auf Unternehmensebene wäre der Reisende mit einem Projekt oder einem großen Funktionalitätsblock gleichzusetzen. Die Schlange vor den Zöllnern  ist das Backlog und wir müssen nur noch bestimmen, wie hoch der Durchsatz der Projekte insgesamt ist. Als Resultat bekämen wir die Kapazität der Gesamt-Organisation. Ist diese nicht hoch genug, machen wir nicht dem einzelnen Team Druck, sondern nutzen die Ideen von Goldrath, nachdem sich der Durchsatz des Gesamt-Systems erhöht, wenn das Bottleneck des Gesamt-Systems wegarbeitet ist.

2008 bekam ich von meinen Stammkunden Oliver Zeiler einen Anruf: Ob ich ihm bei der Einführung von Scrum im ImmobilienScout 24 helfen könne? Wieder stellte er die gleiche Frage und dies Mal kannte ich die richtige Antwort auf seine Frage und konnte sie für ihn auch praktisch umsetzen.

Mein Team von bor!sgloger consulting nutzt heute meine Methode, Scrum zu skalieren, um ganze Organisationseinheiten umzustellen. Unser Rekord liegt bei einer Woche um  10 Teams auf Scrum umzustellen, und unser Rekord für die Skalierung von einer Organisation nach Scrum ist derzeit bei 160 Personen.  Wir wissen, wie man mit 160 Menschen gleichzeitig ein Sprint Planning durchführt.

Das Thema Skalieren, auch über Ländergrenzen hinweg, ist heute mit Hilfe von Scrum für Organisationen gelöst, ausprobiert und in der Praxis erfolgreich umgesetzt. Scrum hat damit das erreicht, was das traditionelle Projektmanagement versprach, an dem es aber konsequent gescheitert war.  Olivers Frage: “Wie macht man Scrum in einem Multi-Team, Multi-Projekt und Multi-Site Umfeld!”, seit 6 Jahren in unzähligen Varianten an mich herangetragen, lässt heute ein Lächeln auf meinem Gesicht erscheinen.

Related posts:

• Scrum – eine Revolution (4)
• Scrum – Eine Revolution (3)
• Scrum — eine Revolution (5)

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.

“Rechtssicherheit ist für jedes Geschäftsmodell essentiell. Gerade für Scrum ist sie bedeutsam. Denn die Idee ‘Scrum’ kann nur in einem gesunden Unternehmen funktionieren.” schrieb Rechtsanwalt Marcus Antonius Hofmann am Montag in unserer Summer School.  Tja, davon kann auch Santa ein Weihnachtslied singen!

Nächste Woche beschäftigen wir uns mit dem Thema “Skalierung”. Wird wieder eine große Sache! ;-) Viel Spass weiterhin mit unserer Summer School!

PS: Kurze Review zum gestrigen Online-Chat mit Rechtsanwalt Hofmann: Erörtert wurde zunächst die rechtliche Stellung eines externen Dienstleisters, der als Berater des Auftraggebers (Kunden) ein Scrum-Projekt mit betreut, das aber von einem externen Entwickler im Auftrag des Kunden umgesetzt wird. Es ging hier vor allem um verschiedene Konstellationen und die jeweils damit einhergehenden Haftungsrisiken des Beraters. Danach drehte sich der Chat um agile Vergütungsmodelle: Diskutiert wurden Cost per Sprint und Cost per Storypoint Modelle, außerdem CPIF und verschiedene andere Lösungsansätze. Soweit man hier ein Fazit ziehen kann, so ist es wohl, dass das ideale Vergütungsmodell stark vom konkreten Projekt und der jeweiligen Konstellation abhängt.

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 und Kanban widersprechen sich nicht, noch ist die eine Idee besser als die andere. Es sind einfach zwei verschiedene Dinge. Scrum basiert auf Wissensmanagement, Kanban kommt aus der schlanken Produktion. Wir behaupten, dass Scrum sich für Produktentwicklung eignet und Kanban für Instandhaltungsarbeiten. Kurt Nielsen, unser dänischer Partner, schrieb diesen äußerst aufschlussreichen Artikel. (Boris)

Scrum und Kanban in der Realität | Kurt Nielsen

Kanban wird von einigen als die Novität gehandelt, die Scrum als bevorzugte Agile Arbeitsweise ersetzen wird. Also fragen die Leute: “Sollen wir auf Kanban setzen, statt auf Scrum?”

Nun, wollen wir einen Hamburger essen, oder Mozart anhören? Meiner Meinung nach sind Kanban und Scrum zwei verschiedene Ideen, die nicht in ohne weiteres in denselben Arbeitsbereichen Anwendung finden. Ich sehe das so:

1. Bei Kanban geht es darum, einen stetigen Produktionsstrom wie etwa Arbeitsschritte zu optimieren, also ein an sich operativer Ansatz. Sehr nützlich für ungeplante Aufgaben oder für eine fortlaufende Arbeitsabfolge mit niedriger Komplexität.
2. Bei Scrum geht es darum, das Feld für eine neue Produktentwicklung mit hoher Komplexität abzustecken. Das heißt für Dinge, bei denen wir noch gar nicht wissen, wie wir die einzelnen Aufgaben bearbeiten werden. Scrum definiert die nötigen Planungsaspekte der Produktentwicklung und führt sie durch, schafft also einen Rahmen, der das Team anleitet, die Arbeit letztlich durchzuführen.

Für mich ist Scrum das große Ganze, durch das wir in Organisationen Wert aus Aufwand generieren. Kanban könnte man dann innerhalb der Scrum Sprints verwenden, um die Arbeit auszuführen.

Wo Kanban allein verwendet wird – und es mag viele Arbeitssituationen geben, bei denen das angebracht ist – sehe ich Kanban als eine Art Scrum, bei dem ein Sprint einen Tag reduziert ist, oder wo ganz auf Sprints verzichtet wird.

Jene, die zu Kanban statt Scrum raten, begrüssen oft die Tatsache, dass es nicht dieselben Einschränkungen und Regeln gibt, man muß keine Sprints machen, man muss keine Estimation machen, man muß keine Retrospektiven machen. Ich frage mich, sehen wir hier wieder einmal den alten Widerwillen der Developerorgansitationen gegenüber Struktur und Einschränkungen wach werden? Wir wollen tun, was wir für das Beste halten, wenn wir es brauchen.

Das Fehlen von Grenzen ist nicht an sich schon etwas Positives, schließlich sind wir nicht mehr in den 68ern, oder in Height Ashbury 1967. Grenzen sind absolut notwendig, wenn wir Selbstorganisation etablieren wollen. Damit es eine gemeinsame, klare Auffassung von dem Produkt gibt, brauchen wir eine gemeinsame Sprache, eine klare Vision, Anhaltspunkte für die Richtung, in die wir unterwegs sind und so weiter und so fort. Man kann die Scrum-Regeln mit Verkehrsregeln vergleichen. Diese Grenzen schaffen einen Rahmen innerhalb dessen ich von A nach B komme und es auch überlebe. Ich will versuchen, dies noch etwas weiter auszuführen.

Was ist Scrum also wirklich?

Scrum ist eine Philosophie, eine Art und Weise Projekte und Aktionen einer wesentlichen Größe und Komplexität zu betrachten und anzugehen, so dass eine möglichst optimale  Lösung zustande kommt.

Der Kern der Scrumphilosophie ist der “Gedanke der ständigen Verbesserung”:

1. Auf der strategischen Ebene geht es darum, den Wert und die Kosten der Deliverables  (Product Backlog Items – PBIs) herauszufinden, und sinnvolle Deliverables so zu priorisieren, daß sie als nächstes bearbeitet werden.
2. Auf der taktischen Ebene geht es darum, eine Folge von Deliverables zu erstellen, die danach bearbeitet und in Aufgaben zerlegt werden können.
3. Auf der Ebene der Tasks (operative Ebene) geht es um die Anwendung von Fähigkeiten um eine Einzelaufgabe vollumfänglich zu erledigen und abzusichern, um dann das Deliverable insgesamt fertig zu stellen.

Über all dem steht der grundlegende Gedanke, dass Hindernisse und Barrieren sichtbar gemacht und in Echtzeit bearbeitet werden, damit Commitment, Schwung und Engagement erhalten bleiben.

In Scrum wird eine Reihe von Begrenzungen verwendet, um die oben erwähnten Ziele durchführbar zu machen:

1. Wir haben einen klar definierten “modus operandi”: die Arbeit ist in kurze Sprints aufgeteilt, mit regelmäßiger Lieferung von fertigen Deliverables.
2. Es gibt klar definierte Rollen mit bestimmten Verantwortungen: Product Owner, Scrum Master und Team.
3. Wir haben klar definierte Treffen: Sprint Planning (1, 2 und auch Estimation), Daily Scrum, Sprint Review und Retrospektive.
4. Wir haben bestimmte Artefakte: Product Backlog mit Deliverables, Sprint Backlog (Taskboard) mit den in Arbeitsschritte zerlegten Deliverables und die Liste der Hindernisse (Impediment Backlog).

Und was ist dann Kanban?

Kanban ist im grunde genommen ein fortgeschrittenes Taskboard, typischerweise mit den verschiedenen Stufen (Zuständen), die die in Ausführung befindlichen Arbeiten (Work in Progress) durchlaufen müssen, bis sie fertig sind. Die Arbeitenden (das Team) holen ihre Aufgaben aus dem priorisierten Upstream. In jeder Stufe gibt es ein Limit, wie viele Deliverables in dieser Stufe erlaubt sind, um die Menge des WIP (Work in Progress) zu minimieren und einen harmonischen Durchfluss zu schaffen, der auf längere Sicht Durchlaufzeiten reduziert.

Das ist alles! Was die sonstige Tagesstruktur angeht, gibt es keine Vorgaben.

Zusammenfassung

Kanban allein eignet sich für Aufgaben, die in einem steten Strom anfallenden, wie zB. in Produktionsabteilungen, iT Operations oder Serviceabteilungen. Bei dieser Art von Arbeiten ist ein Sprint oft nicht denkbar, weil die Leute großteils nicht im Vorhinein wissen, was als nächstes auf sie zukommen wird. Es gibt auch oft keine Diskussion über den wirtschaftlichen Wert oder gar eine Schätzung einer bestimmten Aufgabe, weil diese sowieso schnellstmöglich erledigt werden muss: Wenn der Hauptserver zusammenbricht, bringt ihn wieder zum Laufen! Jetzt.

Bei Scrum hingegen geht es um eine strategische Entscheidung was mit den zur Verfügung stehenden Ressourcen gemacht werden soll. Es ist eine Art der Organisation mit dem permanenten Anspruch sich zu verändern.

Ich behaupte, in Kanban und Scrum geht es um zwei verschiedene Dinge. Kanban ist die Feuerbekämpfung, bei Scrum geht es darum die Feuer zu entfachen (natürlich die richtigen).

Kanban ist ein defensiver “modus operandi”, Scrum ein offensiver.

[Anmerkung der Redaktion: Die Diskussion, ob Scrum oder Kanban, ist aus unserer Sicht obsolet - weil es eben um zwei verschiedene Dinge geht. Für eine Situation eignet sich das eine, für eine andere Umgebung das andere. Eine Vermischung ist genauso denkbar. ZB. die Organisation der Tasks im Sprint mit Kanban. Oder Kanban erweitert um Scrumelemente, wie zB. die Retrospektive, um Kaizen (das auch zu Kanban gehört) zu praktizieren.]

Es folgt die Betrachtung von Kurt zum Thema Scrum und Kanban

Kanban gegenüber Scrum

Sehen wir uns nun die verschiedenen Praktiken beider Zugänge an um die Vorzüge beider Ideen aus der Perspektive von Kanban zu sehen.

1. Work in Progress beschränken

Oft wird der Hauptnutzen von Kanban darin gesehen, dass es es explizit Work in Progress (WIP) beschränkt. Das ist wie auch immer bei Scrum inhärent, wo wir uns darauf konzentrieren, Deliverables so schnell wie möglich fertig zu bekommen. Das Delierable(Story) wird in Einzelaufgaben(Tasks) zerlegt, die circa einen Tag dauern. So sind sie leichter zu überblicken und zu bearbeitet. Alle Tasks einer Story fertig ist gleich Deliverable ist “done”. Es stimmt, dass es kein explizites Limit von WIP in Scrum gibt. Ziel einer “guten” Implementierung von Scrum ist ein minimiertes WIP. Im Allgemeinen ist das ausreichend, weil angenommen wird, dass das Team genug Überblick über die Arbeit im Sprint hat, um die lokale Komplexität zu bewältigen. Durch die Aufteilung der Arbeit in Sprint  reduziert sich die Komplexität des Projekts, also ist Waste normalerweise kein Thema.

Tatsächlich ist es so, dass das explizite Limitieren von WIP in Kanban, einen zusätzlichen Druck auf die Leute aufbaut. Anstatt den Menschen eine Richtlinie zu geben, wie sie ihre Arbeit machen sollen, zwingt sie der Kanban-Prozess gewissermaßen zu einer bestimmte Art der Arbeit.

2. Die verschiedenen Stufen von Work in Progress reflektieren

In Kanban ist es typisch, die WIP aufzuteilen, z.B. in Stufen wie “Design”, “Implementierung”, “Test” und anderes.

Einerseits kann das hilfreich sein, so sagt Scrum eigentlich nichts darüber wie das Taskboard oder das Sprint Backlog aussehen sollen. Alles, was  Scrum sagt ist, dass das beides existieren muss um den Fortschritt aufzuzeigen und Interventionen zu ermöglichen, wenn etwas schief läuft.

Andererseits hat es einen Einfluss auf die Selbstorganisationsfähigkeiten eines cross-funktionalen Teams. Diese Stufen zu definieren ermutigt die Leute nicht, Aufgaben zu übernehmen, an die sie nicht gewöhnt sind und verstärkt alte Gewohnheiten von spezialisierten Rollen. Es ermutigt Leute, bei dem zu bleiben, was sie kennen.

3. Die Abwesenheit von Regeln

Es heißt, Kanban definiert nur sehr wenig explizit, also ist jeder frei, die Strukturen zu entwicklen, die er braucht. Jeder soll die Werkzeuge benutzen, die er nützlich findet.

Klingt gut! Aber es stimmt nicht. Kreativität braucht Grenzen. Teams brauchen Grenzen. Scrum ist ein empirisch belegter Startpunkt und einer, den jeder verstehen kann. Totale Freiheit ist keine Wohltat, sondern ein Fluch. Indem man mit einem gut definierten Rahmen (der Scrum ist) beginnt, kann jeder erstmal loslegen und der Rest der Organisation kann verstehen, dass diese “Projektsprache” nicht jedes Mal neu erfunden wird.

Da Teams und Organisationen reifen, werden sie sicherlich lokale Anpassungen von Scrum by the Book machen, aber das ist nicht das selbe wie alle Grenzen fallen zu lassen.

Nur Kanban?

Meine Meinung ist, dass wenn man nur Kanban macht, man seinen Führungsbereich und -einfluss auf ein rein taktisches und aufgabenorientiertes Niveau beschränkt. Alle strategischen und Teambelange werden nicht bearbeitet – oder man muss ein paar zusätzliche Dinge zu Kanban einführen um diese abzudecken.

Kanban ist Produktion, gut passend zu einem konstanten Strom von Arbeit, wo jeder Arbeitsschritt relativ gut definiert ist. Ein paar Beispiele helfen möglicherweise:

1. Kanban hat keine Rollen. Scrums hauptsächlicher Erfolgsgarant ist, dass alle Spieler gut definierte Verantwortlichkeiten und die dazupassende Autorität haben. Es ist meine Überzeugung, dass Verbesserung mit Scrum hauptsächlich daraus resultieren, dass jede der drei Kernrollen extrem auf ihre Arbeit fokussiert ist und sicher ist, was von ihr erwartet wird. Das verliert sich mit reinem Kanban.
2. Kanban hat keine Sprints, es ist ein dauernder Fluss an Arbeiten. In Scrum geht es um ein lokalisiertes überschaubares Projekt – Sprint um Sprint – das ganze Projekt mag unübersichtlich und komplex sein, aber für die nächsten zwei bis vier Wochen wissen wir genau, was von uns erwartet wird und was wir tun sollen – es geht sozusagen um ein Miniprojekt. Das gibt dem Team gedankliche Ruhe und die Freiheit innerhalb der Grenzen kreativ zu sein, und es gibt dem Rest der Organisation eine verbindliche Erwartung darüber, was im Sprint geliefert werden wird. Dieser Überblick fehlt mit reinem Kanban.
3. Kanban hat keine Schätzung. Schätzung als erste Stufe in einem kontinuierlichen Bemühen um ein gemeinsames Verständnis  ist die Basis für das Team um sich auf Deliverables in einem Sprint verpflichten zu können. Schätzung ist auch die Basis auf der der Product Owner seine Releaseplanung macht und das Projekt mit dem Rest der Organisation abgleicht, Deadlines einhält, etc. Schätzungen sind für den Product Owner auch wertvoll, weil so auffällt, dass bestimmte Deliverables nur sehr kostspielig zu erhalten sind, und er mag zwei Mal überlegen, bevor er solche in Auftrag gibt. Mit reinem Kanban – wie kommt man zu einem Budget für ein bestimmtes Set an Deliverables?
4. Kanban hat keine Daily Scrum Meetings. Man braucht auch um keine, da die Leute “in Silos” arbeiten. Tester testen, Entwickler entwickeln. Ok, Kanban hat keine Sprints, also das Einzige, was es bei einem täglichen Meeting zu tun gäbe, wäre Stolpersteine zu aufzudecken.
5. Kanban hat keine Retrospektiven. Wenn das nicht anders abgedeckt wird, ruiniert das den ständigen Verbesserungszyklus; die Retrospektiven sind der Ort, wo Fakten deutlich gemacht und reflektiert werden, größere Impediments aufgedeckt und Verbesserungsbereiche identifiziert werden. Das ist geht nicht mit reinem Kanban.
6. Kanban hat keine Impediment Backlogs. Es wird oft gesagt, dass eines der Dinge in Scrum, das wirklich den Einsatz der Leute und das Wohlfühlen am Arbeitsplatz  verbessert, das Faktum ist, dass Stolpersteine und Hindernisse in Echtzeit behandelt werden (durch den ScrumMaster in Scrum). Die Menschen erleben, dass ihre Arbeit für jemand anderen (den ScrumMaster) wichtig genug ist, um asap auszuräumen, was immer ihre Arbeit behindert, das verhindert sehr effektiv Frustration. Das funktioniert nicht mit reinem Kanban.

2010-07-18. CST Kurt B. Nielsen

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.

Marcus Antonius Hofmann, Rechtsanwalt in München, der bereits am Montag im Rahmen unserer Summer School mit seinem Post auf bor!sgloger das sehr interessante Thema “Scrum und Verträge” beleuchtet hat, stellt kostenlos das Vertragsmuster “Erstellung von Individualsoftware mit SCRUM” zum Download zur Verfügung.

Dieses Vertragsmuster dient dazu, die Erstellung von Individualsoftware unter Verwendung von Scrum rechtlich abzusichern. Es berücksichtigt die Besonderheiten des agilen Prozesses und stellt Rechtssicherheit her, soweit dies möglich ist, ohne den Prozess zu modifizieren. Dieses Vertragsmuster ist unter einer modifizierten Creative Commons Attribution Share Alike 3.0 (by-sa) Lizenz freigegeben, auch zur kommerziellen Verwendung. Details sind dem Download beigefügt. Das Archiv enthält Adobe PDF (.pdf) und Microsoft Word (.docx) Dateien.

Darüber hinaus steht Herr Hofmann heute von 14:00 bis 16:00 für einen Live Chat zum Thema ‘agile Verträge’ via Skype (ID “marcus.a.hofmann”)  zur Verfügung. (Dabei geht es um allgemeine rechtliche Fragen zum Thema, es findet keine Beratung zu Einzelfällen statt).

Freuen wir uns auf eine spannende Diskussion!

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.

Der Sommer hat’s ja doch in sich! Laut Stern ist der diesjährige Juli einer der heissesten Monate, die Deutschland je gesehen hat! Wir vom bor!sgloger Team laufen darum seit Wochen auch nur mehr mit kühlen Getränken an unseren Waterbelts herum! :-)

Das kannst du jetzt auch!

Für jede Anmeldung für eines der folgenden Trainings bis drei Wochen vor Beginn gibt’s einen Waterbelt gratis dazu:

o) CSM mit Boris Gloger, 08+09.09.2010, Frankfurt a. M.
o) Moderationstraining mit Dieter Rösner, 13+14.09.2010, Wien
o) CSM & Scrum Cooking mit Boris Gloger und Peter Beck, 16+17.09.2010, Wien

Let it flow!

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.

Diese Woche steht im Zeichen der formalen Aspekte von Scrum im Einsatz. Klar geht es am Anfang einer Scrum-Implementierung erstmal darum, die prozessualen Probleme in den Griff zu bekommen, die Teams zu stabilisieren usw., wenn aber diese Dinge “in Form” sind, kann man sich den nächsten Verbesserungsschritten widmen, die auch Aspekte rings um das Scrum-Team betreffen, z.B. Karrierepfade für Mitarbeiter.

Die Case Study dieser Woche berichtet aus einem Unternehmen, das Scrum seit ca.3 Jahren für mittlerweile rund 80 Mitarbeiter einsetzt. Dass hier die Anfangshürden genommen sind, ist in diesem Falle klar. Mit Stefan Klein, dem Abteilungsleiter Software Engineering, erzählen wir die Geschichte von Scrum bei Infonova in Graz, über die Entwicklungsschritte und welche Fragen Klein und seine Kollegen jetzt beschäftigen.

Case Study zum Download: 100803_case study_infonova

Wiedereinmal – wir sind gespannt auf eure Kommentare, Vorschläge und Antworten!

Stefan, danke für dein Engagement, Stichwort Best Practise – wir hören uns wieder! Ziemlich bald ;)
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.

Marcus Antonius Hofmann hat gestern in seinem Artikel “Scrum und Verträge” wunderbar erklärt, wieso Anwälte mit agiler Software Entwicklung ihre Probleme haben. Dieser Artikel erklärt, wieso die meisten Software-Entwicklungsverträge in den meisten Fällen das Falsche regeln.

“Ein Vertrag koordiniert und regelt das soziale Verhalten durch eine gegenseitige Selbstverpflichtung. Er wird freiwillig zwischen zwei (oder auch mehr) Parteien geschlossen. Im Vertrag verspricht jede Partei der anderen, etwas Bestimmtes zu tun oder zu unterlassen (und damit eine von der anderen Partei gewünschte Leistung zu erbringen). Dadurch wird die Zukunft für die Parteien berechenbarer.” [1]

Also alles klar und einfach. Zwei Parteien einigen sich darauf, was sie voneinander in der Zukunft erwarten. Warum ist das in unserer Branche so problematisch?

Schauen wir doch mal, welche Vertragsmodelle es so gibt: Bei meiner kurzen Internetrecherche zum Thema agile Verträge bin ich, jetzt nach 8 Jahren Scrum, noch immer auf die beiden gleichen Ideen zum Thema “agile Verträge” gestoßen: Fix Price/Fix Date, Time and Material. Der “Target Cost Contract”, der erstemalig durch das Terminal 5 des Heathrow Airports bekannt wurde und das Venture Capitalist Modell, mit dem VC neue Firmen mit Geld ausstatten, sind zwar bekannte Modelle, werden in der Praxis aber nicht genutzt.  [2]

Doch sind diese Modell für unsere Zwecke geeignet? Ein Vertrag besagt, dass zwei Parteien eine klar definierte Beziehung eingehen. Woraus besteht die Beziehung in unsere Industrie? Welche Varianten gibt es, diese Beziehung zu charakterisieren?

Die Beziehung zwischen Kunde und Lieferant kann beschrieben werden als eine Leistung = Arbeit / Zeit gegen Geld oder als die Lieferung eines Dings, eines Gegenstandes, eines Produktes gegen Geld.

Im Geschäftsbeziehungen gehen beide Parteien davon aus, dass Leistung = Arbeit / Zeit und dass das Produkt einen “materiellen” Wert hat. Einen Wert, von dem man im Geschäftsleben glaubt, dass es möglich ist, diesen WERT in einer Einheit – Geld – auszudrücken.

Schauen wir uns doch mal an, wieso die gängigen Vertragskonzepte bei der Entwicklung von neuen Produkten – und wir reden in der Software Entwicklung immer von neuen Produkten – versagen.

1) Fix Price / Fix Date. In diesem Modell wird für Leistung eine vorher festgelegter Betrag bezahlt, oder? Einem klar definierten Leistungsumfang wird ein Wert (ausgedrückt in unserer Einheit) gleichgesetzt, der zu einem fest definierten Zeitpunkt für die Leistung ausgetauscht werden muss. Moment, das stimmt ja gar nicht! Am Ende wird von einem Produkt gesprochen, richtig? Schlussendlich sind die Kunden des Lieferanten nicht bereit, die Leistung zu bezahlen, also dass der Lieferant alles gegeben hat, sondern sie wollen ein Produkt in den Händen halten, von dem zu Anfang niemand wusste, wie es sein soll.

2) Time and Material. In diesem Modell wird die Arbeit und das eingesetzte Material bezahlt. Im Grunde total fair, oder? Wieso funktioniert das dann nicht? Wieder stimmt etwas nicht: Der Kunde will nicht Arbeit bezahlen, sondern ein Produkt. Er will nicht selbst mit den eingekauften Mitarbeitern etwas produzieren, sondern am Ende des Projektes ein Produkt haben.

3) Target Cost. Das klingt gut. Time and Material mit einem definierter Marge, die ausgewiesen wird, verhandelbar ist, aber über die der Kunde informiert wird, Grundvoraussetzung: es gibt einen klare definierten Scope. Aber Moment, im Grunde wird ja wieder Arbeit verkauft, diesemal allerdings mit Transparenz und einem klaren Commitment auf beiden Seiten, die Kosten im Auge zu behalten. Schaut man sich die Case Study “Selling Agile: Target-Cost Contracts” [3] dazu an, dann wird schnell klar, dass sie in diesem Fall erfolgreich waren, weil sie höhere Transparenz erzeugt hatten, aber nicht weil das Bezahlmodell anders gewesen war. Auch diesem Modell zielt am Wesentlichen vorbei. Wieder wird Arbeit verkauft, am Ende will der Kunde aber ein Produkt.

4) Das Venture Capitalist Modell. Der VC investiert in die Idee und schaut, was dabei herauskommt. Er investiert weiter, wenn er noch an die Firma glaubt. Er bezahlt nicht die Arbeit, sondern investiert in eine Idee mit dem Vertrauen, am Ende ein Produkt in Händen zu halten. Er investiert also nicht in Arbeit, sondern in das Produkt. Der VC macht sich klar, was ihm die Chance auf das Produkt wert ist und investiert. Wieso wird dieses Modell, wie auch Alistair anmerkt, bei agilen Verträgen, obwohl es dem Wesen dessen, was wir tun, am nächsten kommt, nicht gewählt? Meine Antwort: Kunden wollen nicht investieren, sondern kaufen. Der Lieferant will nicht investieren, sondern dem Kunden etwas verkaufen. Venture Capitalists arbeiten mit Menschen, die sich gemeinsam darüber im klaren sind, dass der VC und der Unternehmer beide auf Entdeckungsreise sind und nur unterschiedliche Funktionen in diesem Abenteuer haben. In den meisten Software Entwicklungsprodukten stehen beide Seiten auf unterschiedlichen Standpunkten. Sie verstehen sich nicht als Einheit, die gemeinsam einen Wert schaffen wollen, an dem beide partizipieren, sondern der Lieferant will am Kunden verdienen. Ein tiefes Misstrauen entsteht.

Die Varianten 1 bis 3 sind gängige Verfahren, Software-Entwicklungsprojekte vertraglich abzusichern. Sie treffen aber nicht das Wesen der Geschäftsbeziehung, obwohl es so aussieht. Agile Software Entwicklungsverträge sollten das VC Modell emulieren, allerdings müssen wir uns dabei im klaren sein, dass dann immer ein unternehmerisches Risiko existiert. Wer dieses Risiko trägt, kann ein Vertrag regeln, aber eine Partei muss es in diesem Fall eingehen.

[1] http://de.wikipedia.org/wiki/Vertrag#Typologie_der_Vertr.C3.A4ge

[2] http://alistair.cockburn.us/Agile+contracts

[3] http://cyrusinnovation.com/downloads/agile2005_cyrusinnovation_targetcostcontracts_paper.pdf

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.

Diese Woche steht die Summer School unter dem Motto “Scrum & Verträge“. Marcus Antonius Hofmann, Rechtsanwalt in München, stellt in diesem Artikel wundervoll dar, vor welchem Dilemma jeder Anwalt steht, wenn man von ihm verlangt einen Vertrag für ein Scrum Projekt zu erstellen. In Folge wird Boris Gloger morgen verschiedene Arten von agilen Verträgen vorstellen und kritisch beleuchten, wie wenig zu diesem Thema in der Scrum Community geschehen ist. Am Mittwoch gibt es die nächste spannenede Case Study, und am Donnerstag, 5. August, wird Herr Hofmann für einen Live Chat zum Thema ‘agile Verträge’ via Skype (ID “marcus.a.hofmann”) von 14:00 bis 16:00 zu Verfügung stehen . (Dabei geht es um allgemeine rechtliche Fragen zum Thema, es findet keine Beratung zu Einzelfällen statt). Wie immer können wir uns auf den Freitag freuen, wenn die Scrumlies uns die Dinge aus einem anderen Blickwinkel zeigen.

Das Leben hält immer wieder Überraschungen bereit. Manch einer hat schon sein blaues Wunder erlebt, weil er sich um die rechtliche Absicherung seiner Projekte nicht ausreichend Gedanken gemacht hat. Gerade im Entwicklungsbereich, insbesondere bei der Softwareentwicklung, ist das auch besonders leicht. Wer schon einmal an einem großen, klassischen IT-Projekt beteiligt war, kennt das Drama, das sich „Leistungsbeschreibung“ nennt: das Lastenheft, das Pflichtenheft, die fachliche und technische Feinspezifikation. Und die Diskussionen darum, wer für was davon zuständig und kompetent ist. Das ist nicht nur anstrengend, sondern das ist auch teuer. Man muss Anwälte ins Boot holen, die an den Vertragsverhandlungen teilhaben und die nicht nur gerne das Ruder in die Hand nehmen, sondern die auch die unangenehme Eigenschaft haben, immer nur in Worst-Case-Szenarien zu denken. Personifizierte Spaßbremsen eben. Und dafür stellen sie dann auch noch Stunden- oder Tagessätze in Rechnung.

Außerdem weiß doch jedes Kind, dass man sich an einen anfangs aufgestellten Plan sowieso nicht konsequent hält, ja dass man komplexe Projekte überhaupt nicht vollständig vorab planen kann. Da ist es nur zu leicht, beim nächsten Projekt auf das ganze Vorgeplänkel zu verzichten und direkt in medias res zu gehen. Vielleicht sogar ganz ohne Vorplanung.

Wenn alles gut geht, hat man viel Zeit, Geld und Nerven gespart.

Wenn aber etwas schiefgeht, ist die Katastrophe perfekt. Nichts ist schriftlich fixiert, und jeder hat den anderen ganz anders verstanden. Die klassische Projektkrise verläuft immer in denselben Phasen: Am Anfang will man gemeinsam ein tolles Projekt machen. Alle sind euphorisch. Man „duzt“ sich. Irgendwie läuft es dann aber nicht so richtig rund. Vorsichtshalber beginnt man also, sich wieder zu „siezen“. Leider führt das nicht wirklich zu emotionaler Distanz, und wenn das Projekt dann immer schlechter läuft, wird sich gegenseitig heftig beleidigt. Nach diesem „Auftakt in drei Akten“ folgt das große Schweigen. Man spricht einfach nicht mehr miteinander. Das kann eine Weile dauern, hilft dem Projekt aber leider auch nicht weiter. Und deshalb geht schließlich der Eine oder der Andere irgendwann Hilfe holen, zum Anwalt. Der soll es dann richten. Und er richtet es. So, wie er es gelernt hat: Vor Gericht. Mit Beweisanträgen, Klagen und Gutachtern. Das ist das „große Finale“. Wer dort schon einmal war, der weiß, dass alles, was nun kommt, mit dem tollen Projekt nichts mehr zu tun hat. Nun ist es ein anderes „Projekt“, und jetzt ziehen andere Leute die Fäden. Und eigentlich haben inzwischen, unabhängig vom Ausgang, alle Beteiligten schon längst verloren. Bis auf die Anwälte.

Aber dazu muss es ja nicht kommen. Alles eine Frage des Projektmanagements, mag man denken. Man ist ja kundennah, offen und kulant, man hält den Kunden bei Laune, alles kein Problem. Diese Überlegung ist so falsch auch gar nicht. Ist das Ergebnis gut, das Projekt im Zeitplan und der Kunde zufrieden, bleibt man von der großen Projektkrise verschont. Gerade Scrum ist – richtig implementiert – in besonderem Maße geeignet, Projekte erfolgreich und mit hoher Kundenzufriedenheit abzuschließen. Dadurch besteht gerade im Umfeld agiler Prozesse eine gesteigerte Bereitschaft, auf rechtliche Absicherung zu verzichten. Dass die Risiken durch Scrum aber nicht beseitigt werden, dürfte jedem einleuchten. Es fällt nur leichter, sie zu verdrängen. Die „Wird schon gutgehen“ Einstellung funktioniert mit Scrum eben besser. Und öfter. Bis es dann irgendwann trotzdem schiefgeht. Womit wir wieder bei den Überraschungen wären, die das Leben dann und wann bereit hält.

Rechtssicherheit ist für jedes Geschäftsmodell essentiell. Gerade für Scrum ist sie bedeutsam. Denn die Idee „Scrum“ kann nur in einem gesunden Unternehmen funktionieren. Einem Unternehmen, in dem der Chef dem Team vertraut. In dem die Ressourcen bestehen, neue Wege zu gehen, neue Dinge zu probieren. Dazu gehört auch finanzielles Rückgrat. Aber selbst bei besten Bilanzen ist ein Unternehmen nicht gesund, wenn in den laufenden und abgewickelten Projekten unüberschaubare oder sogar unerkannte Haftungsrisiken schlummern. Ein solides Unternehmen, in dem Scrum leben und wachsen kann, braucht Rechtssicherheit.

Auch für Anwälte hält das Leben Überraschungen bereit. Die können zum Beispiel so aussehen, dass Mandanten sich der Bedeutung von Rechtssicherheit für ihr Geschäftsmodell bewusst sind. Einfach so, von ganz alleine. Da kommt also plötzlich ein Mandant vorbei, den man schon lange nicht mehr gesehen hatte. Der erzählt einem, dass er da einen neuen Prozess einführt, der „Scrum“ heißt. Und dass das mit den alten Verträgen, die man ihm vor Jahr und Tag entworfen hat, nicht mehr so zu passen scheint. Klar, die waren ja auch für ein Wasserfallmodell gemacht.

Der Mandant erzählt also von Scrum, davon, dass das ein ganz einfacher, strukturell simpler Prozess sei, und dass man da doch sicher auch ganz einfache Verträge machen könne. Solche, die zu der Philosophie von Scrum passen. Das könne ja nicht so schwer sein. Und deshalb auch nicht so teuer. Und außerdem am besten gestern fertig. Meint der Mandant.

Als er gegangen ist, führt der erste Weg zu Google. “Scrum”. Das “Gedränge”. Aha, interessant. Literatur muss her. Schwaber, Sutherland, Cohn, Pichler – Amazon freut sich. Bis ich zu begreifen beginne, worauf ich mich eingelassen habe, vergeht eine Weile. Der große Vorteil von Scrum ist nämlich gleichzeitig auch das große Problem. Betrachtet man die Philosophie hinter Scrum, die sich nicht zuletzt in den agilen Werten wiederfindet, stellt man fest, dass abstrakt-generell gut greifbare Elemente – Prozesse, Dokumentation, Vertragsverhandlungen, Pläne – abgewertet werden. All diese Dinge sind vertraglich aber wunderbar zu regeln. Sie sind das Fundament eines soliden Vertrages. Stattdessen verschieben agile Prozesse den Fokus auf „weiche“ Faktoren: Individuen, Interaktion, Kommunikation, Zusammenarbeit, Flexibilität – ungreifbar, unfixierbar, ständig veränderlich. Ein rotes Tuch für den vertragsgestaltenden Juristen.

Wie soll man etwas vertraglich regeln und Rechtssicherheit schaffen, wenn man noch gar nicht weiß, was gemacht werden soll? Wenn das Produkt und auch die Planung dafür erst während des Projektes inkrementell-iterativ entstehen? Wie soll man einen Vertrag schreiben, wenn man keine verbindlichen Abläufe und Prozesse vorschreiben darf, um vom Gesetz vorgesehene Eckdaten zu fixieren, weil das Team sich eigenverantwortlich selbst organisiert – und bei seiner Organisation natürlich und völlig zu Recht keine Rücksicht auf irgendwelche übertrieben formalen Gesetze oder Vorschriften nimmt? Wenn man zu Recht unproduktive und aufgeblähte Verwaltungsaufgaben einfach unter den Tisch fallen lässt? Wenn an die Stelle verbindlicher, nachvollziehbarer, schriftlich detailliert fixierter Besprechungen und Entscheidungen die horizontale Kommunikation, das kurze, offene Gespräch tritt? Wenn hinter dem Produkt, den Leitideen des potenziell auslieferbaren Produktinkrements und der Vermeidung von Technischer Schuld andere Dinge völlig zurücktreten? Wenn ein Prozess in vielerlei Hinsicht von Vertrauen geprägt ist, statt von Kontrolle?

Der Vertrag steht auf Papier. Das ist geduldig, und unveränderlich. Verträgt sich das mit einem agilen Prozess? Kann man beim Einsatz von Scrum überhaupt wirksame und funktionierende Projektverträge abschließen? Und können diese Verträge wirklich einfacher sein, als wir das bisher kannten? Ist es möglich, die schlichte Eleganz von Scrum auch in dem Vertragswesen abzubilden? Gibt es vereinfachte Rechtssicherheit durch Scrum? Kann das gehen?

Ja, es kann. Wenn man sich als Anwalt auf die erforderliche Denkweise einlässt. Wenn man bereit ist, hergebrachtes über Bord zu werfen und neue Wege zu gehen, neue Dinge zu probieren. Indem man die Prozesse und Protokolle, die Scrum bietet und mit denen Scrum arbeitet, instrumentalisiert, um darauf rechtliche Absicherung aufzubauen. Wenn man sich davor hütet, Scrum zu verändern. Dann kann es gehen. Dann bekommt man fast ohne zusätzlichen Aufwand das, was ich die “eingebaute Rechtssicherheit” von Scrum nenne.

Voraussetzung ist, dass man Scrum “richtig” macht. Aber das ist ja ohnehin das erklärte Ziel.

Marcus Antonius Hofmann
Rechtsanwalt, München

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…