Archiv der Kategorie: Teamwork

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

Wie Sie Entscheidungen visualisieren

Irgendein schlauer Mensch hat einmal gesagt

Entscheidbares muss man nicht entscheiden.

Zugegeben, im ersten Moment verwirrt dieser Satz etwas. Aber wenn Sie eine Weile darüber nachdenken, wird Ihnen die Logik dahinter einleuchten. Wenn eine Sache klar und sicher voraussagbar ist, dann ist eine Entscheidung unnötig, denn dann wissen Sie ja, was zu tun ist. Entscheiden heißt, sich unter Unsicherheit eine aus zwei oder mehreren Optionen auszuwählen.

Leider gibt es keine Garantie dafür, dass sie schlussendlich die „richtige“ Entscheidung treffen. Daran ändern auch die vielen Entscheidungsmethoden nichts, die in Workshops immer wieder angwewandt werden. „You simply don’t know“, sagen die Amerikaner.

Allerdings können diese Techniken dazu verhelfen, die Entscheidungsfindung zu strukturieren und das Für und Wider der Optionen gegeneinander abzuwägen. Wenn die Entscheidungsfindung dann noch in geeigneter Form visualisiert wird, dann lässt sich über die Dokumentation auch später noch sagen, wie und warum man zu der entsprechenden Entscheidung gelangt ist. Dies ist eine gute Grundlage, um für zukünftige Entscheidung Lehren ziehen zu können.

Nun eignet sich nicht jede Technik für jede Entscheidungsfindung. Da gibt es Paarvergleiche, Entscheidungstabellen oder die Bildung von Rangfolgen.

Jan-Torsten Kohrs hat in zwei informative Artikel zu Entscheidungsmethoden veröffentlicht: Das kleine Trainer- und Moderatoren-1×1: Entscheidungen in Gruppen herbeiführen (Teil 1 und Teil 2). Alle Methoden werden kurz und knapp erklärt und durch Flipchartfotos illustriert.

Mir hat besonders die Visualisierung des Paarvergleichs in Form des „Entscheidungsstifts“ gefallen. Der Paarvergleich ist eigentlich einfach, die Durchführung führt jedoch manchmal zur Verwirrung. Der Entscheidungsstift hilft das Vorgehen zu vereinfachen.

GregMontani / Pixabay

BTW: Wenn jemand den Urheber des Zitats zu Anfang kennt, dann bitte ich darum, mich aufzuschlauen. Ich würde zu gerne wissen, wer das war.

 

2 Antworten

Scrum: Von null bis etwas Ahnung

Seit einigen Jahren bewege ich mich nun auf diversen PM-Camps und habe nie einen Hehl daraus gemacht, dass ich von einigen diskutierten Ansätzen wenig bis keine Ahnung habe. Insbesondere was Scrum angeht, habe ich zwar hier und da das eine oder andere aufgeschnappt, von soliden Kenntnissen konnte aber keine Rede sein.

Höchste Eisenbahn also, den Zustand der Unkenntnis zu beseitigen. Letzte Woche durfte ich nun in Berlin auf Einladung meines lieben Kollegen und Freundes Jan Fischbach an einem seiner Scrum-Master-Trainings teilnehmen. Und ich muss sagen, nun fühle ich mich für weitere einschlägige Erkundungen gut gerüstet. Ich weiß nun, was die Werte, die Rollen, Artefakte und Ereignisse sind. Vor allem aber ist mir klar geworden, das Scrum weniger eine Projektmanagementmethode, sondern vielmehr ein Rahmen für Teams ist, um Ziele mit hoher Produktivität zu erreichen (und natürlich noch ein paar andere Dinge mehr).

Nun ist es ja nicht etwa so, dass ich in den vergangenen Monaten nicht versucht hätte, mir Kenntnisse bez. Scrum anzueignen. Startpunkt für derlei Unternehmungen ist bei mir zumeist ein Buch aus der berühmten Dummie-Reihe. So auch hier:

Allerdings muss ich gestehen, dass ich beim ersten Lesen nur Bahnhof verstanden habe. Das wird sich nach dem Seminarbesuch sicher ändern. Also ein neuer Versuch.

Das Seminar hat großen Spaß gemacht, nicht zuletzt deshalb, weil wir Teilnehmer uns den Stoff in Kleingruppenarbeit und durch Simulationen selbst erarbeiten durften. Eduscrum heißt die Methode: Scrum lernen durch Scrum tun. Die notwendigen Inputs von Jan waren kurz, knapp, knackig und vor allem auch humorvoll. Und ganz neidlos muss ich anerkennen, dass Jan sein Handwerkszeug versteht. Nicht nur als Scrum-Spezialist, sondern gerade auch als Trainer.

Vielen Dank.

Jan und Stephan

Achtung! In Berlin habe ich Blut geleckt. Es kann also durchaus sein. dass in der Zukunft hier der eine oder andere Artikel über Scrum & Co. erscheint. Ich hoffe, das stört nicht.

1 Antwort

10 einfache E-Mail-Regeln für Teams

Immer mehr Teams ersetzen in ihrer Zusammenarbeit die gute alte Tante E-Mail durch eigens dafür konzipierte Software (Groupware). Bekannte Beispiele für solche Anwendungen sind etwa Asana, Trello, Jira & Co. (hier eine kleine Übersicht).
Dennoch weiß ich von meinen Kunden, dass auch heute noch besonders innerhalb gemeinsamer Projekte unterschiedlicher Firmen immer noch auf das Medium E-Mail zurückgegriffen wird.

Für solche Fälle hat Boris Veldhuijzen van Zanten seinen Artikel 10 simple rules to make email (within teams) more efficient geschrieben. Er empfiehlt.

  1. Antworten Sie nicht auf jede Nachricht
    Auch wenn Sie ein höflicher Mensch sind, sollten Sie sich fragen, ob tatsächlich jeder Mail ein „Dankeschön“ folgen muss. Das bläht den Eingangskorb Ihrer Partner auf und lenkt sie ab. Sparen Sie sich überflüssige Reaktionen.
  2. Schreiben Sie nicht wegen jeder Kleinigkeit
    Nicht jeder Gedankenblitz muss sofort in eine E-Mail umgesetzt werden. Machen Sie sich stattdessen Notizen und gehen Sie diese später noch einmal durch. Dann können Sie immer noch entscheiden, ob Sie eine Nachricht absetzen möchten.
  3. Fragen Sie die E-Mail-Vorlieben Ihrer Partner ab
    Klären Sie im Team ab, wie die E-Nachrichten gestaltet werden sollen. Kann man Sie irgendwie standardisieren. Sie merken schon, wenn Sie das konsequent zu Ende denken, landen Sie zwangsläufig bei der Groupware.
  4. Je kürzer die Mail, desto besser
    Das muss nicht weiter erklärt werden. Die E-Mail ist digital das, was die Postkarte analog ist. Kennen Sie die zwei-, drei-, vier-, fünf-Sätze-Verpflichtung?
  5. Ist die E-Mail tatsächlich das beste Medium für die Nachricht?
    Manchmal ist es besser von schriftlich auf mündlich zu wechseln. Insbesondere, wenn es um heikle oder konfliktbeladene Dinge geht. Es gibt ja auch noch andere Medien, wie z.B. Skype oder das gute alte Telefon. Für extrem kurze Fragen, die einer extrem kurzen Antwort bedürfen, ist der firmeninterne Messenger die richtige Lösung.
  6. Halten Sie Ihre Gefühle außen vor
    Ich habe in meiner Laufbahn schon die schlimmsten Dinge infolge missverstandener E-Mails erlebt. Da helfen auch keine Emojis. Schreiben Sie keine E-Mails, wenn Sie ärgerlich sind. Greifen Sie stattdessen zum Telefonhörer oder noch besser: Gehen Sie hin und suchen das persönliche Gespräch.
  7. Verschicken Sie keine ellenlange Anhänge
    Nicht alle Unternehmen stellen ihren Mitarbeitern unbegrenzten Speicherplatz zur Verfügung. Richten Sie für die Zusammenarbeit ein gemeinsames Laufwerk für Dokumente ein. Wie Sie so etwas professionell bewerkstelligen, zeigen Ihnen Jan Fischbach und Wolf Steinbrecher im Praxisbuch Informationsmanagement.
  8. Verwenden Sie CC sparsam
    Benutzen Sie CC bitte nicht nur deshalb, weil Sie es können. Je mehr Leute Sie im Verteiler stehen haben, desto weniger von diesen Leuten werden Ihre Nachricht lesen. Oft ist ein aufgedunsener CC-Verteiler doch nur ein Merkmal einer ausgeprägten Absicherungsmentalität
  9. Benutzen Sie BCC, wenn es angebracht ist
    Wenn Sie doch einmal eine Nachricht an viele Absender schicken müssen, verwenden Sie die BCC-Funktion. Nicht jeder will jedem seine E-Mail-Adresse zukommen lassen.
  10. Verschicken Sie überhaupt keine E-Mail
    Das Versenden von E-Mails ist zwar einfach, aber nicht immer angebracht. Gehen Sie bitte verantwortungsvoll mit E-Mails um. Ihre Partner werden es Ihnen danken.

Postkasten Arona

Schreibe eine Antwort

Was Google über die Effektivität von Teams denkt

Ich bin ja ein bisschen skeptisch, wenn ich höre, dass Google als Modell für die neue Arbeitswelt hingestellt wird. Aber sei’s drum, interessant sind die Impulse aus diesem Unternehmen allemal.

In einem Vortrag erzählt Julia Rozovsky, was ein effektives Team von den anderen unterscheidet: How Google thinks about team effectiveness. Sie beruft sich dabei auf Studien, die intern bei Google angestellt wurden. Rozovsky beantwortet in ihrem Vortrag die Fragen:

  1. Können wir als Team Risiken eingehen ohne Angst vor Unsicherheit oder Verlegenheit zu haben?
  2. Können wir aufeinander zählen um rechtzeitig Ergebnisse hoher Qualität zu erreichen?
  3. Sind unsere Ziele, Rollen und Maßnahmenpläne klar?
  4. Arbeiten wir an etwas, das auch jedem von uns persönlich etwas bedeutet?
  5. Sind wir davon überzeugt, dass die Arbeit, die wir tun, von Bedeutung ist?

Wenn diese Fragen im Team mit „Ja“ beantwortet werden, dann ist die Wahrscheinlichkeit sehr groß, dass ein Team auch als effektiv anzusehen ist.

Aber sehen und hören Sie selbst;

Julia Rozovsky How to Build a Great Team

Schreibe eine Antwort

OpenSpace zur Strategieentwicklung

Wie die geneigten Leserinnen und Leser (gar nicht) gemerkt haben, habe ich in der ersten Woche nichts zu Papier in den Blog gebracht. Der Grund war sehr angenehm für mich: Ich durfte wieder einmal einen OpenSpace begleiten. Es ging bei der Veranstaltung um Stratiegieentwicklung bei AX Semantics. Kurz das Fazit von meiner Warte aus:

  • Lasst Menschen über die Dinge nachdenken, die ihnen am Herzen liegen. Fragt die Leute einfach und nehmt sie ernst, dann kommen die Lösungen von alleine. Es war faszinierend mit anzusehen, mit welchem Engagement und welcher Konzentration die Menschen zusammenarbeiten. Da braucht man kein Motivationsgedöns.
  • Die Menge an Themen, die im OpenSpace bearbeitet werden, ist beeindruckend. Am Dienstag bearbeiteten rd. 30 Teilnehmer 16 verschiedene Themen.
  • Es ist wichtig dafür zu sorgen, dass die Themen am Ende der Veranstaltung so aufbereitet werden, dass nahtlos mit/an ihnen weitergearbeitet werden kann. Das ist gelungen, wie ich finde.
  • Zwischen Barcamp und OpenSpace gibt es tatsächlich Unterschiede, die den Unterschied machen. Ohne den Diskurs der vergangenen Wochen noch einmal aufgreifen zu wollen, fühle ich mich in meiner Ansicht bestätigt.

Danke dem sympathischen Team von AX Semantics für die Gastfreundschaft und das erwiesene Vertrauen!

 

Bücher zum Thema (Werbung)

Schreibe eine Antwort