Archiv der Kategorie: Projektmanagement

Task Boards für Gmail, Evernote & Co

Wenn Sie sich mit GTD und ähnlichen Konzepten befasst haben, dann sind Ihnen zwei grundsätzliche Aufgabentypen bekannt. Es gibt Aufgaben, die lassen sich „in einem Rutsch“ erledigen und die großen Brocken, die Sie in Teilaufgaben zerlegen müssen um sie handhabbar zu machen. David Allen nennt letztere Projekte. Ich persönlich ziehe es vor, zwischen Ein- und Mehrschrittaufgaben zu unterscheiden.

Für die Organisation der Einschrittaufgaben verwende ich die Aufgabenleiste von Outlook, die ich nach den Vorschlägen von Michael Linenberger eingerichtet habe. Für die Mehrschrittaufgaben habe ich eine Zeitlang ebenfalls mit Outlook experimentiert. Allerdings wurde das Ganze sehr schnell unübersichtlich, so dass ich mittlerweile meine persönlichen Projekte nach den Prinzip Personal Kanban mit Trello plane. In der Aufgabenleiste von Outlook verweise ich dann nur noch auf das entsprechende Task Board unter Trello.

Obwohl sich Trello zu diesem Zweck sehr gut eignet und etabliert ist, gibt es auch noch andere Möglichkeiten, ein Task Board zu erstellen. Sie können z.B. mit der Mind-Mapping-Software XMind in einer Kombination aus Organigramm und Baumdarstellung eine Aufgabenboard erstellen.

Melanie Pinola stellt in ihrem Beitrag Kanban Everything: How to Add Trello-Like Boards to Gmail, Evernote, and More Gestaltungsmöglichkeiten für

  • GoogleMail (GMail)
  • Evernote
  • den Chrome-Browser
  • WordPress und auch
  • Outlook vor.

Meist handelt es sich um Erweiterungen nach dem Freemium-Modell, mit denen die Task-Board-Funktionalität hergestellt werden kann. Das heißt die Basisausstattung ist kostenlos, für die interessanten Zusatzfunktionen ist ein monatlicher Obolus fällig.

Ausgerechnet die Erweiterung für Outlook bildet hier die Ausnahme. Sie heißt Outlook Taskboard und ist kostenlos über GitHub zu beziehen. Allerdings müssen Sie für den Gebrauch eine besondere Ordnerstruktur anlegen. Das Ganze ist schon ein wenig tricky. Dies und die Tatsache, dass die Verwendung von Erweiterungen in Outlook aus Performance- und Verträglichkeitsgründen mit Vorsicht zu betrachten ist, hielt mich davon ab, das Add-on zu installieren.

Fazit: Ich stehe erst einmal weiter treu und fest zu Trello. Aber vielleicht sind diese Erweiterungen für Sie eine Überlegung wert, was meinen Sie?

Übrigens sollten Sie durchaus als Alternative zu diesem Elektronikkram das gute alte Whiteboard und Post-it-Notes in Erwägung ziehen. Ich kenne eine Mengen Menschen, gerade auch aus dem IT-Bereich, die diese „altmodischen“ Werkzeuge benutzen und sehr zufrieden damit sind. VitaminP.info erklärt wie es geht:

Kanban in 2 Minuten erklärt | VitaminP.info

 

Das Buch zu Personal Kanban (Werbung)

 

Schreibe eine Antwort

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

Wie Sie Ihre Dateien benennen und organisieren

Wenn Sie mich fragten, was ich in meinem Computerleben bereue und gerne ändern würde, dann würde ich Ihnen antworten, mich nie um die Benennung von Dateien gekümmert zu haben. Ich will es mit der Zerknirschung allerdings auch nicht übertreiben, es gibt Gründe dafür. Ich habe mich deshalb nie darum gekümmert, weil:

  • die Übersichtlichkeit der Dateien auch ohne besondere Benennung gewährleistet war. Schlicht und einfach, weil die Diskettenkapazität sehr begrenzt war. Man hat halt die Diskette beschriftet. Das hat sich dann auf anderen Speichermedien fortgesetzt
  • in grauen Windows-Vorzeiten eine systematische Benennung nur schwer möglich war. Die Dateinamen mussten eine bestimmte Länge haben, ohne Leerzeichen auskommen usw.

Heute ist das natürlich anders, der Speicherplatz ist nahezu unbegrenzt und bei der Benennung können Sie (beinahe) machen, was Sie wollen. Nun ist der große Speicherplatz Fluch und Segen zu gleicht. Auf der einen Seite können Sie so viel Dokumente abspeichern, wie Sie möchten, auf der anderen Seite entsteht so ein fürchterlicher Datenverhau, in dem man sich kaum mehr zurecht findet. Das ist auch der Grund dafür, dass ich immer mal wieder verzweifelt nach einem cleveren Programm Ausschau halte, das mir die Suche nach verschollenen Dateien abnimmt.

Zum Glück bin ich ein Einzelunternehmer und muss meinen Rechenknecht bzw. meine Dateiablage nicht mit anderen Mitmenschen teilen. Wenn in Teams die Dateien abgelegt werden wie bei Luis Trenker im Rucksack, dann kann die Sache dramatisch ausgehen. Spätestens dann nämlich, wenn ein Kollege auf die Dateien zugreifen muss und nicht weiß, wo er/sie mit der Suche überhaupt anfangen soll.

Das Leibniz-Institut für Bildungsforschung und Bildungsinformation hat auf der Website forschungsdaten bildung einen Ratgeber zum Dateimanagement veröffentlicht. Hier finden Sie allerhand Hinweise zur Dateibenennung, Ordnerstruktur und – ganz wichtig – zur Versionierung. Hier erfahren Sie auch, wie Sie den bestehenden Datenbestand analysieren und organisieren können. Allerdings ist mir das zu aufwändig, das bemühe ich doch lieber eine geeignete interne Suchmaschine.

Was für die Forschung recht ist, sollte für den Arbeitsalltag billig sein. Auch wenn das beschrieben Vorgehen sehr formal zu sein scheint, so finden Sie m.E. doch einige umsetzbare Hinweise für das Wald- und Wiesenbüro.

Was die Dateiorganisation in Projekten angeht, so möchte ich an dieser Stelle noch einmal auf das Grundlagenwerk von Fischbach und Steinbrecher hinweisen: Projektablage – Wie aus einer lästigen Pflicht eine mächtige Plattform für Zusammenarbeit wird.

Tama66 / Pixabay

 

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

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

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

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

Update: Der Emergent Task Planner und andere Tools

Der Titel ist paradox, ich gebe es zu. Schließlich ist der Clou am Unvorhergesehen, dass man es nicht vorhersehen kann. Und was man nicht vorhersehen kann, das kann man auch nicht planen. Ist doch logisch, oder? Diese einfache Wahrheit kann auch David Seah mit seinem “Emergent Task Planner (ETP)” nicht umstoßen. Allerdings hilft der ETP dabei, mit Unvorhergesehenem effizienter umzugehen. David schreibt:

The Emergent Task Planner (or ETP) is a daily planning sheet that provides a way for you to structure your day in the face of uncertainty. By helping you visualize the time you have, you can get a sense of just how much work you can get done done.

David bedient sich bei seinem ETP einer ausgefeilten Variante des Time-boxing, einer Methode, die auch bei der Pomodoro-Technik angewandt wird. David stellt auf seiner Website eine ausführliche, hübsch aufgemachte Anleitung zum Herunterladen zur Verfügung. Dort gibt es auch die Druckvorlagen für die Formulare seiner Methode, sogar in Deutsch. Ich selbst organisiere meine Bürotage ähnlich, wenn auch nicht so ausgeklügelt.

In seinem Artikel A Variety of Downloadable Productivity Tools hat David nun einige weitere Werkzeuge aufgelistet. Aus gegebenem Anlass, wie es so schön heißt, werde ich mir den Fast Book Outliner und den NaNoWriMo 2017 Word Counting Calendar (hoffentlich bald auch in einer 2018er-Version). Ersterer dient zum Anfertigen von Buchauszügen, letzterer zum Besiegen des inneren Schweinehunds beim Schreiben.

Wie gesagt, das sind die Tools, die ich gerade interessant finde, für Sie ist vielleicht etwas anderes gerade von Nutzen.

StockSnap / Pixabay

1 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