Archiv der Kategorie: Teamwork

Vom Umgang mit schwierigen Menschen im Projekt

Als ToolBlog-LeserIn gehören Sie sicher nicht zu diesem Personenkreis, aber Sie haben sicher mit diesen Zeitgenossen zu tun. Die Rede ist von schwierigen Mitmenschen, die uns hier und dort das Leben schwerer machen als es ist. In diesm Blog habe ich schon mehrfach Autoren zitiert, die uns Hinweise geben, wie wir am besten mit ihnen umgehen können ohne unsere Nerven allzu sehr zu strapazieren (z. B. hier und hier).

Schwierige Mitmenschen sind überall anzutreffen, also auch in Software-Projekten. Sie kommen in unterschiedlichen Erscheinungen daher. Neil Green widmet ihnen eine komplette Website mit dem Titel How to Deal with Difficult People on Software Projects. Neil hat sich die Rollen

  • Product Manager
  • Designer
  • Project Manager
  • Development Manager
  • Entwickler
  • Qualitäter

genauer angeschaut und ordnet diesen Rollen unterschiedliche Typen von Nervensägen zu. Diese versieht er auch mit griffigen Bezeichnungen. So finden wir zum Beispiel bei den Entwicklern Divas, Idealisten, Elefanten im Porzellanladen oder Rockstars. Zu jeder dieser Typen liefert Neil die Erkennungsmerkmale, eine Problembeschreibung und einige Hinweise zum erfolgreichen Umgang mit ihnen.

Zum leichteren Auffinden der Typen hat Neil eine schöne Grafik erstellt. Ein Klick auf das jeweilige Symbol bringt Sie schnell zur entsprechenden Beschreibung.

Auch wenn die Seite schön und aufwändig gemacht ist, bitte bedenken Sie, dass so eine Typisierung ihre Grenzen hat. Aber Schmunzeln ist sicherlich erlaubt.

 

Schreibe eine Antwort

Der Unterschied zwischen Kanban und Scrum

Ich beschäftige mich nun schon geraume Zeit mit Scrum und sehe mich einem Phänomen gegenüber, dass ich auch von anderen Lernbereichen schon kenne. Wenn ich eine Tür öffne, erscheinen dahinter gleich mehrere, die zunächst verschlossen sind. Oder andersherum: Immer wenn ich denke, ich hätte etwas verstanden, dann tauchen wieder neue Fragen auf.

Beispielsweise die, worin eigentlich der Unterschied zwischen Kanban und Scrum besteht. Kanban kenne ich noch aus dem Automotivebereich, aber nicht umsonst unterscheidet die Wikipedia zwischen Kanban als Methode der Prozesssteuerung und Kanban in der Softwareentwicklung. Meine Verwirrung war perfekt als ich dann auch noch von Scrumban lesen musste.

Klar, hier war Recherche angesagt und hier ist meine derzeitige Ausbeute:

  • Planview LeanKit: Kanban vs. Scrum: What are the differences? [Link]
  • Alexander Sergeev: What’s the Difference Between Scrum and Kanban? [Link]
  • Yatin Pawar: 7 key differences between Scrum and Kanban [Link]

Am hilfreichsten war der Artikel meines Freundes Jan Fischbach auf dem Teamworkblog: Lean, Scrum, Agile und Kanban im Vergleich (so, dass man es versteht). In seinem Beitrag erwähnt Jan auch das Minibuch von Henrik Kniberg und Matthias Skarin. Eine wirklich wertvolle Empfehlung. Vor allem aber hält Jan sein Versprechen „so, dass man es versteht“.

Nein, ich werde hier nicht zusammenfassen, was denn nun der Unterschied zwischen Kanban und Scrum ist. Erstens bin ich noch nicht am Ende meiner Fragen (s.o.) und zweitens tun sich für mich schon wieder neue Fragen auf.

Monfocus / Pixabay

 

Schreibe eine Antwort

Wie Sie in 7 Schritten eine Agenda erstellen

Ein Grundbedingung für erfolgreiche Besprechungen ist das Vorhandensein einer Tagesordnung aka Agenda. Die Macher der App [Less Meeting] haben einen Artikel geschrieben, in dem Sie erfahren, wie Sie systematisch eine Agenda erstellen können: 7 Steps to The Perfect Meeting Agenda. Hier sind die 7 Schritte zur perfekten (!) Agenda:

1. Erstellen und versenden Sie Ihre Agenda 3 Tage vor der Besprechung

Die Teilnehmer haben genügend Zeit, sich auf die Besprechung vorzubereiten (ob sie die Zeit nutzen, ist eine andere Frage). In dieser Zeitspanne können Sie auf Angregungen der Teilnehmer reagieren und stressfreiarm Änderungen vornehmen.

2. Fangen Sie mit den Rahmenbedingungen an

Nennen Sie Zeitrahmen (Beginn und Ende), sowie den Ort der Veranstaltung. Überlegen Sie sich, wer an der Besprechung teilnehmen soll: Wer kann etwas zu den Themen beitragen, bzw, wer soll dazu informiert werden? Benötigen Sie Teilnehmer, die zu Entscheidungen berechtigt sind? Gibt es technische Hinweise, die für die Teilnehmer wichtig sind, wie Anfahrtsbeschreibungen oder technische Details? Letzteres betrifft vor allem online-Meetings.

3. Formulieren Sie das Ziel des Meetings

Was soll bei der Besprechung heauskommen? Denken Sie über den Unterschied (das Delta) zwischen dem Beginn und dem Ende des Meetings nach. Hier hilft oft die Technik des Zweiten Futurs: Was soll in der Besprechung passiert sein, wenn Sie erfolgreich verlaufen ist?

4. Strukturieren Sie die Besprechung

Strukturieren Sie den Inhalt des Meetings, indem Sie den einzelnen Tagesordnungspunkten Zeitspannen zuweisen. Planen Sie dabei nicht zu knapp und denken Sie an die vielen kleinen Zeitdiebe. Achten Sie darauf, Zeit für einen guten Einstieg und einen angemessenen Abschluss einzuplanen. Menschen müssen ankommen und benötigen einen ordentlichen Abschluss, z. B. eine Reflexion über das Meeting selbst (Was haben wir erreicht?).

5. Planen Sie höchstens 5 Punkte auf der Tagesordnung ein

Nichts fürchten unsere Mitmenschen mehr als endlose Besprechungen. Beschränken Sie sich auf die wesentlichen Punkte, sonst steigt die Anzahl der Absagen.

6. Ergänzen Sie notwendige Informationen

Teilen Sie in der Agenda mit, wer welche Rollen (z.B. Protokollant) einnimmt und was u.U. von den Teilnehmern im Vorfeld erwartet wird („Lesen Sie bitte das angefügte Dokument).

7. Was tun bei Einladungen ohne Agenda

Wenn Sie zu Besprechungen eingeladen werden ohne eine Agenda zu bekommen, dann thematisieren Sie dies in Ihrer Organisation. Wenn Sie sich trauen: Lehnen Sie die Einladung mit der Begründung ab, die Agenda nicht zu kennen. Ich bin sicher, Sie werden darauf eine Antwort bekommen.

In dem Artikel finden Sie ein Beispiel für eine Agenda, die nach der o.a. Vorgehensweise erstellt wurde. Ob eine derartige Agenda perfekt ist, wie in der Überschrift steht, sei dahingestellt.

Unsere amerikanischen Freunde neigen mitunter dazu, den Mund etwas voll zu nehmen. Aber das wissen wir ja. 😉

delphinmedia / Pixabay

 

Schreibe eine Antwort

Wie gehen Sie mit Totschlagargumenten um?

In vielen Diskussionen, insbesondere bei TV-Krawallsendungen á la „Hart, aber fair“, kann man beobachten, dass gar nicht auf Argumente sachlich, fachlich, logisch, kurz angemessen, reagiert wird. Vielmehr versuchen die Gesprächsgegnerpartner das Argument mit Scheinargumenten totzuschlagen.

Eine meiner Lieblingsfiguren ist der Whataboutism. Wenn ich beispielsweise Fahrradfahrer auf regelwidriges Verhalten gegenüber Fußgänger hinweise, bekomme ich oft die Antwort: „Und was ist mit den Autofahrern? Wie verhalten die sich gegenüber uns? Ist das etwa besser?“. Auf das ursprüngliche Argument wird also gar nicht eingegangen, vielmehr wird es mit Whataboutism totgeschlagen.

Es gibt aber noch mehr solcher Konstruktionen. Ligitas Nefas hat 20 Logical Fallacies That Dumb People Use To Win Arguments zusammengetragen. Mit dabei sind fiese Methoden wie

  • Auf die Person statt auf das Argument zielen
  • Das ausschließliche Verwenden von „Beweisen“, die die eigene Meinung untermauern oder
  • zirkuläres Begründen.

Nun kann man sich fragen, wer jemals durch derartige Rabulistik jemand anders überzeugt hat. Den Anwendern geht es aber oft auch gar nicht um das Überzeugen. Vielmehr wollen sie sich selbst erhöhen, indem sie andere klein machen. Oder sie ziehen es vor, in ihrem vermeintlich sicheren Meinungskokon zu verbleiben. Andere wiederum wollen vor dem Publikum glänzen. Es geht also weniger um die Sache, sondern um die eigene Person.

Leider bietet Ligitas Nefas keine Lösungen für seine Beipiele an. Vielmehr sind die Leser gefordert, in den Kommentaren ihre Vorschlage für den Umgang mit Totschlagargumenten zu hinterlassen. Allerdings muss man die sprachlichen Figuren erst einmal kennen, bevor man in der Lage ist sich zu wehren.

Zu diesem Zweck empfehle ich den Klassiker von Arthur Schopenhauer: Die Kunst, Recht zu behalten. Für den Kindle gibt es das Buch sogar umsonst.

Tumisu / Pixabay

 

1 Antwort

15 Regeln für gutes Feedback

Der Spiegel ist ein vielbenutztes, doch völlig unterschätztes Werkzeug des täglichen Lebens. Wir benutzen ihn, weil er uns ermöglicht, eine Außerperspektive einzunehmen. Nur mit ihm bekommen wir einen Eindruck davon, wie unsere Mitmenschen uns betrachten könnten. Für das Aussehen (Kleidung, Rasur etc.) mag das leidlich funktionieren, aber wie sieht das mit unserem Verhalten aus?

Da der sprechende Spiegel aus dem Märchen „Schneewittchen“ verloren gegangen ist, bleibt uns wohl nur die Möglichkeit, unsere Mitmenschen direkt anzusprechen und sie um Rückmeldung („Feedback“) zu bitten. Wir warten dann gespannt auf die Meinung des Beobachters. Manchmal macht uns das verlegen, denn Feedback zu bekommen ist oft weniger schwierig als Feedback zu geben. Sind wir zu offen, kränken wir vielleicht den Empfänger, halten wir uns bedeckt, dann kann der Empfänger mit dem Feedback nichts anfangen und lügen sollen wir ja auch nicht. Eine verzwickte Situation. Noch viel schwieriger wird es, wenn Sie ungebeten Feedback geben müssen, etwa um Kollegen auf Fehler hinzuweisen.

Damit Ihnen das Feedback geben in Zukunft leichter fällt, nennt uns Ann Gomez The 15 golden rules of constructive feedback:

1. Konzentrieren Sie sich auf Lösungen

Vorwürfe bringen niemanden weiter, Lösungen schon. Helfen Sie Ihrem Partner, selbst Lösungen zu finden. Vielleicht haben Sie auch selbst Lösungen anzubieten. Auch gut, aber schulmeistern Sie nicht.

2. Fragen Sie anstatt zu behaupten

Bedenken Sie, dass Ihre Sichtweise nicht die richtige sein muss. Gute Fragen helfen dem Partner, sich zu sortieren und den Sachverhalt für sich zu klären. Vielleicht erfahren Sie Aspekte, an die Sie bisher noch gar nicht gedacht haben.

3. Machen Sie spezifische Aussagen

Versuchen Sie bei Beobachtungen zu bleiben und bleiben Sie bei Zahlen, Daten, Fakten. Das ist nicht einfach, denn wir neigen dazu, sofort zu interpretieren und zu werten. Versuchen Sie es trotzdem. Mit Generalisierungen kann Ihr gegenüber nichts anfangen.

4. Wählen Sie den richtigen Zeitpunkt

Geben Sie Feedback nur dann, wenn der andere es auch hören kann. Damit ist nicht nur der akustische Aspekt gemeint. Der Empfänger muss auch aufnahmebereit sein.

5. Nichts überstürzen!

Geben Sie Feedback nicht zwischen Tür und Angel. Wenn Sie sich Zeit für Ihren Partner nehmen, dann zeigen Sie damit Ihre Wertschätzung.

6. Bedenken Sie die Selbstachtung

Achten Sie darauf, dass der Andere sein Gesicht behält. Erwarten Sie auch nicht, dass Ihre Meinung sofort (oder überhaupt!) akzeptiert wird. Sie müssen nicht Recht haben und gut Ding will Weile haben.

7. Bilden Sie Vertrauen

Sie können nur dann erwarten, dass Ihr Feedback auf fruchtbaren Boden fällt, wenn der Andere Ihnen traut. Vertrauen entsteht durch Verbindlichkeit, Zuverlässigkeit und Sprechen auf Augenhöhe.

8. Achten Sie auf ein gutes Gefühl hinterher

Es muss einen Unterschied geben zwischen Gesprächsbeginn und -ende. Was haben Sie beide gelernt, was möchten Sie ändern, was beibehalten?

9. Gibt es ein Muster?

Einmaliges Verhalten rechtfertigt oft kein Feedback. Es ist vielmehr dann angebracht, wenn eine bestimmte Verhaltensweise zurückgespiegelt werden soll. Achten Sie also auf Wiederholungen oder Muster.

10. Lohnt es sich, etwas anzusprechen?

Bedenken Sie auch beim Feedback das Kosten-Nutzen-Verhältnis. Lohnt es sich tatsächlich, „ein Fass aufzumachen“ oder kann man auch mit Toleranz über die Sache hinwegsehen?

11. Konzentrieren Sie sich auf das, was der Empfänger ändern kann

Nicht ist frustrierender als für etwas kritisiert zu werden, was außerhalb des eigenen Einflussbereichs steht. Fragen Sie sich also vorher, ob der Andere überhaupt etwas ändern kann.

12. Erwische den Anderen, wenn er es richtig macht

In der Pädagogik kennt man den Begriff der „positiven Verstärkung“. Kenneth Blanchard formulierte dies so: „Erwische den Anderen, wenn er’s gut macht.“ Lassen Sie das den Anderen wissen. Mit großer Wahrscheinlichkeit wird er/sie die Handlung wiederholen.

13. Prüfen Sie sich selbst

Geben Sie Feedback nie, wenn Sie negative Gefühle haben. Das kann Ihr berechtigtes Anliegen völlig verzerren. Warten Sie stattdessen, bis Sie wieder klarsehen.

14. Auch Feedback muss man üben

Gehen Sie dem Feedback nicht aus dem Weg, besonders wenn Sie darum gebeten werden. Nur so gewinnen Sie Sicherheit und Urteilsvermögen.

15. Seien Sie selbst offen für Feedback

Sind Sie selbst offen für Feedback und bereit, daraus Schlüsse für Ihr Verhalten zu ziehen? Wenn nicht, dann sollten Sie das auch nicht von Ihrem Gegenüber erwarten.

Ein wichtiger Hinweis zum Schluss:

Denken Sie daran, dass Feedback immer die Sichtweise eines Menschen darstellt. Es handelt sich um Wahr-nehmung, nicht um Wahrheit.
Auch der Spiegel in der Anprobe im Bekleidungsgeschäft zeigt Ihnen nicht die Wahrheit, sondern lässt eine Menge Spielraum für Interpretationen zu.

Sie kennen das.

a_m_o_u_t_o_n / Pixabay

 

Schreibe eine Antwort

Scrum: Stolperfallen und Lösungen

Scrum und Agilität sind derzeit in aller Munde. Bis April gehörte ich zu den Ahnungslosen, die sich unter Scrum nicht allzu viel bis gar nichts vorstellen konnten. Nach der Teilnahme an einem Seminar mit Jan Fischbach hat sich das etwas geändert, mittlerweile kann ich den Gesprächen der Fachleute wenigstens einigermaßen kompetent zuhören.

Jan hat es in dem Training geschafft, mich wirklich für das Thema „anzuspitzen“, der Scrum Day in Filderstadt tat sein Übriges. Nach der Lektüre vieler Fachartikel und Bücher zum Thema Scrum ist mir eines klar geworden:

It’s simple but not easy.

Übrigens muss man den Urhebern von Scrum, Jeff Sutherland und Ken Schwaber zugute halten, dass sie daraus nie einen Hehl gemacht haben. Im Scrum Guide (pdf-Datei] schreiben sie:

Scrum ist leichtgewichtig, einfach zu verstehen, schwierig zu meistern.

Der Teufel steckt im Detail und in der Anwendung von Scurm gibt es einige Fallstricke. Mishkin Berteig hat 24 Common Scrum Pitfalls zusammengefasst. Die Fallstricke reichen von „Exzessiver Vorbereitung/Planung“ über „Zuweisung von Aufgaben“ bis hin zur „Anwesenheit der Scrum Master“. Zu jedem Fallstrick gibt es eine kurze Beschreibung und einen Link zu einem weiterführenden Beitrag.

Leider sehe ich mich (noch) nicht in der Lage, den Nutzwert des Artikels von Mishkin zu beurteilen. Allerdings gibt es dazu viele Kommentare, die einen näheren Blick sicher wert sind.

Viele Fragen, die die Umsetzung von Scrum aufwirft, kommen mir als Organisationsentwickler bekannt vor, Déjà-vu sozusagen. Es würde sich für die Agilisten und Scrummer m. E. durchaus lohnen, einmal über den Tellerrand in Richtung Gruppendynamik oder Problemlösungsmethodik zu schauen.

Da gäbe es für sie einiges zu entdecken.

 

Bücher zum Thema (Werbung)

Schreibe eine Antwort

Agile is dead!

Eigentlich ist dieser Überschrift ein Widerspruch an sich. Denn entweder ist etwas agil oder eben nicht. Wie auch immer. Dass „Agil tot ist“ behauptet in dem folgenden Video nicht irgendwer, sondern einer der Unterzeichner des Agilen Manifests, Dave Thomas. Den Vortrag „Agile is Dead“ hat Dave Thomas auf der GOTO Konferenz 2015 in Amsterdam gehalten. Mir haben einige Sequenzen durchaus eingeleuchtet, aber sehen Sie selbst:

GOTO 2015 • Agile is Dead • Pragmatic Dave Thomas

 

1 Antwort

Die E-Mail-Selbstverpflichtung: Fasse Dich kurz

Manchmal bin ich schon erstaunt darüber, welchen Umfang e-Mails im Geschäftsverkehr annehmen. Man kann es nicht oft genug sagen: E-Mails sind nicht das Medium für längere Romane. Der Geschäftsbericht oder die Doktorarbeit gehört in den Anhang. Beschränkt Euch auf das Wesentliche. “Fasse Dich kurz”, stand früher in den Telefonzellen. Mittlerweile gibt es sogar die Website zu Selbstverpflichtung zu kurzen Nachrichten:  two.sentenc.es. Dort heißt es:

Treat all email responses like SMS text messages, using a set number of letters per response. Since it’s too hard to count letters, we count sentences instead.
two.sentenc.es is a personal policy that all email responses regardless of recipient or subject will be two sentences or less. It’s that simple.

Falls Ihnen zwei Sätze doch zu wenig sind, dann probieren Sie halt three.sentenc.es, four.sentenc.es oder five.sentenc.es. Das war es dann aber auch.

Es schadet übrigens auch nicht, sich die wichtigsten Grundregeln für E-Mails in Erinnerung zu rufen, die im Email Charter gelistet sind:

  1. Respektieren Sie die Zeit des Empfängers
  2. Kurz und knapp heißt nicht unhöflich
  3. Üben Sie sich in Klarheit
  4. Vermeiden Sie offene Fragen
  5. Vermeiden Sie überflüssige CCs
  6. Halten Sie den Gesprächsfaden kurz
  7. Denken Sie über Ihre Anhänge nach
  8. Nutzen Sie geläufige Kürzel
  9. Vermeiden Sie nutzlose Antworten
  10. Gehen Sie offline

Ich denke, diese Grundsätze sprechen für sich und bedürfen keiner weiteren Erklärung. Wenn doch, finden Sie ein paar Erläuterungen im Email Charter selbst.

cattu / Pixabay

 

Schreibe eine Antwort

Buch: Das New Workspace Playbook

Man muss sich schon kräftig die Ohren zu halten, um Wörtern wie Digitalisierung, New Work, Agil & Co aus dem Weg zu gehen. Eines ist jedoch klar: Es wird gar nicht mehr diskutiert, ob es Veränderungen in der Arbeitswelt gibt, sondern allenfalls, wie stark sie sind und in welche Richtungen sie tatsächlich gehen.

Mit Sicherheit wird die Qualität der Kommunikation der beteiligten Menschen ein noch größere Rolle für den Erfolg eines Unternehmens spielen als bisher. Neue Formen der Zusammenarbeit benötigen auch andere (neue?) Arbeitsumgebungen. Das der der Arbeitsplatz großen Einfluss auf Kreativität und Produktivität der Beschäftigten hat, zeigt nicht zuletzt die teils heftige Diskussion um Vor- und Nachteile von Großraumbüros.

Dark Horse Innovation ist eine Denkfabrik aus Berlin (woher sonst), die auf die Fahne geschrieben haben, ihre „Kunden dazu zu befähigen, die Chancen der digitalen Revolution zu erkennen und davon zu profitieren“. Und das bedeutet eben auch, sich mit neuen Raumkonzepten zu beschäftigen. Daraus entstand das New Workspace Playbook, ein „Praxisbuch für das Arbeiten in neuen Räumen“.

Das Buch gliedert sich in drei Teile:

  1. In „New Times“ wird dargestellt, warum wir schon mitten in der Digitalisierung stecken und welche Auswirkungen sie auf die Arbeit hat.
  2. In „New Work„, werden die Prinzipien diskutiert, die nach Meinung der Autoren die Grundlagen für das neue Arbeiten bilden. Jedes Prinzip wird in drei Teilen dargestellt: Einer Definition, Beispiele hierfür und eine steckbriefartige Zusammenfassung („Take-Aways“).
  3. In „New Space“ geht es in die Praxis. Hier wird gezeigt, wie die im zweiten Teil des Buches vorgestellten Prinzipien in Arbeitsumgebungen übersetzt und umgesetzt werden. Vorgestellt wird ein Umsetzungsmodell in sechs Phasen, eine Vorbereitungsphase, vier Arbeitsphasen und eine Nachbereitungsphase. Dieser Teil des Buches zeigt sehr schön, dass das Design von Räumen weit mehr ist als bloßes Stühlerücken. Vielmehr handelt es sich um eine Stück Organisationsentwicklung, das wir oft genug gar nicht auf dem Schirm haben.

Mir gefällt dieses Buch außerordentlich gut. Es ist nicht nur ein Arbeits-, sondern im besten Sinn auch ein Bilderbuch, ein Playbook eben. Das große Format, die reichhaltige Illustration und die angenehme Haptik laden dazu ein, das Buch öfters in die Hand zu nehmen und darin zu blättern. Es ist kein Buch zum Durchlesen. Man nimmt es immer wieder, liest einen Abschnitt, schließt die Augen und stellt sich vor, wie es wäre, wenn…

Allerdings hat einen dann schnell wieder die Realität eingeholt. Das Gefühl kennen Sie vielleicht von den Broschüren der Bausparkassen. Da werden schmucke großzügige Einfamilienhäuser in parkähnlichen Landschaften vorgestellt und am Ende ist man froh ein Reihenhaus zu ergattern. So ging es mir manchmal beim Betrachten der Beispiele von Lufthansa, SAP usw. auch.

Dennoch; Wenn Sie planen, neue Büroräume zu beziehen oder Ihre alten umzugestalten, dann stöbern Sie in diesem Buch. Ihr Innenarchitekt wird im Gespräch Ihre Sachkenntnis bewundern.

 

Das Buch wurde mir freundlicherweise vom Verlag Murmann Publishers als Rezensionsexemplar zur Verfügung gestellt. Vielen Dank dafür.

BTW: Ich freue mich, wenn ich ab und zu ein Buch zum Rezensieren geschickt bekomme. Die Bücher, die mir gut gefallen, bespreche ich, über die anderen schweige ich mich aus. Ich habe keinen Gefallen an Verrissen, schließlich bin ich nicht Reich-Ranicki.

 

Schreibe eine Antwort

Infos über Scrum und Märchen darüber

Dieses Jahr hatte ich zum ersten Mal das Vergnügen, beim Scrum Day in Filderstadt dabei zu sein. Für mich, der ich mit Scrum Neuland betrete, war die Veranstaltung äußerst lehrreich und hat wesentlich dazu beigetragen, dass meine Lernkurve seitdem stark angestiegen ist. Neben spannenden Vorträgen und Workshops kam auch das Netzwerken nicht zu kurz, ich habe viele nette und interessante Menschen kennengelernt. Ein Highlight war für mich das Open Space am Nachmittag des ersten Tages, dass ich zusammen mit Jan Fischbach und Edgar Rodehack begleiten durfte (s. Beweisfoto).

Jan hatte mir in auch die Session Barry Overeem empfohlen: The Scrum Master as a Change Facilitator. Kurz und klein, die Empfehlung von Jan war goldrichtig, das Hingehen hat sich gelohnt.

Von Barry stammt auch ein Artikel, in dem er einen überblick über 10 Mythen zu Scrum gibt: A Summary of the 10 Scrum Myths. Diese sind:

  1. Ein Scrum Master muss während des Daily Scrums anwesend sein
  2. Der Sprint-Backlog darf sich während eines Sprints nicht ändern
  3. Releases gibt es nur am Ende eines Sprints
  4. Das Product Backlog muss aus User Stories bestehen
  5. Das Product Backlog ist priorisiert
  6. Der Product Owner ist ein Bevollmächtigter der Stakeholder
  7. Der Scrum Master muss jedes Problem lösen
  8. Der Scrum Master ist ein Junior Agile Coach
  9. Im Scrum sind Story Points erforderlich
  10. Im Scrum gibt es keine Planung.

Ich gebe zu, Irrtum (2) bin auch ich aufgesessen. Aber man lernt ja dazu.

Wenn Sie jetzt so gar nichts mit diese Ausdrücken anfangen können, aber gerne wissen möchten, um was es bei Scrum eigentlich geht, dann empfehle ich Ihnen diese Quellen für eine erste Übersicht:

  • Für eilige Leser: Der Wikipedia-Artikel auf die Schnelle
  • Der Scrum Guide, auch in Deutsch erhältlich (Die Grundlage, ein Muss!)
  • Agiles Projektmanagement mit Scrum, eine Präsentation von Eric Dreyer (pdf)
  • SCRUM, eine agile Methode zur Software Entwicklung. Seminararbeit von Raffael Schweitzer (pdf)
  • Scrum auf einer Seite von William C. Wake (pdf)
  • Scrum kompakt von Angelika Drach, Christoph Mathis (pdf)
  • Scrum – Auf dem Bierdeckel erklärt, diverse Autoren (pdf)

Eine kritische Würdigung von Scrum unternimmt Mark Harwardt in seiner Magisterarbeit:
Wasserfallmodell versus Scrum – Ist der gute Ruf der agilen Methode gerechtfertigt? (pdf)

Eine Anmerkung zum Schluss:
Besonders der Bierdeckel-Titel verleitet zu der Auffassung, Scrum sei einfach. Das stimmt nur zum Teil. Scrum ist

Einfach zu verstehen, aber schwierig zu meistern.

So die Väter des Ansatzes Jeff Sutherland und Ken Schwaber im Scrum Guide.
Ich finde, auch der erste Teil dieses Satzes stimmt nur bedingt.

 

Schreibe eine Antwort