Direkt zum Hauptbereich

Von den Erwartungen eines Teamcoaches

Einige Menschen in der Welt der Scrum Master / Teamcoaches / Wegbegleiter:innen / Berater:innen (etc. pp.) empfehlen, zur besseren Strukturierung der eigenen Arbeit ein berufliches Tagebuch zu führen, um einen Überblick darüber herzustellen, welche Ansätze mit welchem Ergebnis verfolgt wurden, und um seine Arbeit auf gewisse Ziele auszurichten. Ich mache das hier einmal mit einer - natürlich subversiven und subjektiven - Auswahl von Themen, die mir in meinem Berufsleben als Scrum Master / Teamcoach begegneten und die sich anders entwickelten, als ich dachte.


Ein planloses Planning

In einem Konzern war ich einem Querschnittsteam zugeordnet worden: bestehend aus mehreren Teil-Teams, die nur wenig Berührungspunkte miteinander haben, ergo nicht crossfunktional aufgestellt sind. In jedem Bereich gibt es stattdessen mindestens einen Silberrücken (m/w/d), der ganz allein das umfassende Wissen und die jahrzehntelange Erfahrung besitzt - aber eben nur für seinen Teilbereich. In der Planung der Arbeit können immer nur wenige ihre Spezialthemen einschätzen, die anderen gucken und hören vorwiegend zu. Es mangelt an einem greifbaren gemeinsamen Ziel, und bis auf wenige Ausnahmen, nämlich interne Tools, wird auch kein "Produkt" hergestellt, das einem ein Kunde begeistert aus der Hand reißen möchte. Natürlich gibt es, wie auch in anderen Teams und sogar (vielen?) anderen Unternehmen, immer zu wenig qualifizierte Leute, weswegen Nasen von außen eingekauft werden, die dann aber immer nur auf Zeit bleiben (und im schlimmsten Fall, wenn man als Konzern gepennt hat, das ganze angehäufte Wissen wieder mitnehmen).

Planning ohne jegliche Auswirkungen

Der gravierendste Stein des Anstoßes war für mich kurz nach meiner Ankunft das "Planning" des Teams. Aufgaben wurden in einem ungeeigneten Tool dargestellt, in dem sie nicht ordentlich gepflegt und auf dem aktuellen Stand gehalten werden konnten, zudem fehlte es an Dokumentation, was für die jeweiligen Aufgaben bereits getan wurde und was noch ausstand - von einem Arbeitsüberblick, der dem PO sehr geholfen hätte, ganz zu schweigen. Es handelte sich also eigentlich um gar keine "Planung" der Aufgaben. Wurden diese nicht fertiggestellt, schob man sie zudem ohne weitere Analyse einfach in den nächsten Entwicklungszeitraum weiter, und offenbar niemand störte sich daran. Viele Aufgaben waren angefangen, konnten aber nicht fertiggestellt werden, weil ein Signal von außen fehlte oder weil der Bereich (bzw. dessen CPOs - ja, Chief Product Owner, die dann das letzte Wort haben sollen, wenn sich die POs im Bereich nicht einigen können) zwischenzeitlich andere Themen höher priorisiert hatte. 

Ein Teufelskreis durch intransparente Priorisierung

In einer Retrospektive hatten sich zudem einzelne Teammitlieder darüber geäußert, dass sie die Priorisierung der vielen Themen, die leider nicht selten von außen hereinspülten, intransparent fänden. Dieser Effekt verstärkte ihren eigenen Beitrag zu der Herausforderung auch noch: Aufgrund einer zumindest in ihrer Vorstellung fehlenden oder mangelhaften Priorisierung suchten sie sich nämlich auch häufig inoffiziell, d. h. nicht offiziell im Team abgesprochen und eingeplant, diejenigen Themen aus, die ihnen Spaß machten, was wiederum zu einer noch schlechteren und intransparenteren Priorisierung führte. 

Was tun im Dickicht? Vom Aushändigen einer Machete

Da ich selbst noch keinen Plan von den zahlreichen Epics hatte, die allein für dieses Team kursierten (und die, wie mir schien, nach unterschiedlichen Kriterien erstellt wurden), holte ich mir Rat von einer erfahrenen Person, die mir sagen könnte, welche Schritte ich am besten als nächstes angehen sollte (danke, Jan, noch mal ;-)). Ich hatte die Aufgaben "Priorisierungsregeln bzw. Priorisierungsmix finden" (anteilig Aufräumen, Bugfixing, Entwicklung etc.), "mehr als 50% Verbesserung für die internen Tätigkeiten" (was auch immer das sei bzw. welche Kennzahl man dafür verwenden will), sowie "Lieferung der Ergebnisse schneller und hochwertiger" auf meinem neuen Zettel.

Priorisierungsmix finden

Nach meiner Einschätzung gab es im Team wenig Rework, es war ja auch kein Entwicklungs-, sondern ein Querschnittsteam, das infrastrukturelle Dinge für eine Reihe von technisch aneinandergeketteten Teams zur Verfügung stellte. Aufgrund von Ressourcenengpässen kam es aber auch bei uns z. B. zu längeren Wegen für Fertigstellungen, weil Reviews ausstanden, die die überlasteten Kolleg:innen aber gerade nicht durchführen konnten. Der kleine Anteil an Programmierung fand in enger Abstimmung und in pair programming statt, hier wurden Reviews meist implizit im 4-Augen-Prinzip schon durchgeführt. Idee war nun, den Priorisierungsmix mit dem PO abzustimmen und auch abzustimmen, wie das Thema ins Team zu tragen sei (Erwartungshaltung, Umgang mit Deltas etc.).

Guckt da nachher überhaupt noch einer rein?

Das Team hatte mir auf eine meiner ersten Fragen, wer denn außerhalb des "Plannings" auf die Ergebnisse des Termins sehe, ganz offen geantwortet, dass die "Aufgabenzettel", die von Zeitraum zu Zeitraum weitergeschoben wurden, "keine Bedeutung" hätten. Immerhin schien die psychologische Sicherheit im Team gut zu sein, und ich freute mich, dass man so offen zu mir war. Mit solchen Angaben kann man schließlich direkt weiterarbeiten. Interessanterweise hatte das Team sogar bereits vor meiner Einstellung schon vereinbart, wieder auf ein bekanntes Tool umzusteigen, mit dem wohl früher schon einmal gearbeitet wurde, aber offenbar konnte/wollte sich dann zwischenzeitlich niemand aus dem Team mehr daran erinnern.

Standardtätigkeiten statt Priorisierungsmix

Einen Priorisierungsmix gab es sehr lange nicht, dafür hatte das Team schon recht bald seine Standardtätigkeiten für die Berücksichtigung in den Plannings geschätzt, ein Impuls aus dem Team. Es zeigte sich häufig, dass nach Berechnung der Kapazität in den einzelnen Teil-Teams für den kommenden Entwicklungszeitraum nur äußerst wenige Tage oder auch mal gar keine für ein Teil-Team übrigblieben. Also null Puffer oder sogar Negativzeit. Das war eine klare Aussage, die uns auf andere Art genauso wichtig war wie ein Priorisierungsmix.

Das höhere Ziel bewusst machen

Im gleichen Team erhielt die Umgestaltung des Plannings eine gewisse Eigendynamik, an die ich im Traum nicht gedacht hätte. Es war wie ein Erdrutsch: Durch die Bewegung der ersten Schichten kamen weitere Schichten in Bewegung. Seitens PO kam die Idee, die Themen aus dem "Programm-Inkrement" des Bereiches, ein Zeitraum von drei Monaten, ins Planning hineinzunehmen, um die Fokussierung des Teams auf die anstehenden Ziele für das Quartal zu verbessern. Zudem konnten wir dadurch noch deutlicher sehen, an wieviele Themen auch auf höherer Ebene gleichzeitig gearbeitet wurde - und teilweise aus externen Gegebenheiten heraus gearbeitet werden musste. Abgesehen davon, dass das Team immer wieder durch hineingrätschende 3rd-Level-Support-Themen (ja, das auch noch!) von seinen Zielen abgelenkt wurde, konnten wir durch die Maßnahmen bereits besser sehen, wer an welchen Aufgaben saß, welchen Status diese hatten, und ob sie auf unserem Kanban-Board schon länger offen waren. Durch die höhere Transparenz der Aufgaben jedes Teammitglieds konnte auch gegenseitige Unterstützung gezielter angeboten werden ("ich mache Dir ein Review, ich empfehle Dir das, ich konnte dank Deines Tests dies umsetzen").

Umstrukturierung nach Kaizen

Insgesamt war meine Erwartung gewesen, dass das Planning entweder nach den ersten Maßnahmen insgesamt viel schneller umgestellt werden kann oder aber überhaupt nicht, weil man an liebgewordenen Gewohnheiten festklammert und sich nicht reinreden lassen möchte. Letzteres war zum Glück nicht der Fall, aber die Veränderungen zogen sich über eine ganze Reihe von Monaten hin, da immer wieder Zeit für Absprachen zur Umsetzung von Maßnahmen fehlte oder nur ich als Teamcoach eine gewisse Dringlichkeit bei bestimmten Themen sah. (Immerin entspannt es, wenn man sein Angebot gemacht hat, die andere Seite das Ansinnen auch versteht, aber aktuell nicht darauf anspringt.) Die Verbindung zu einer später eingeführten EPIC-Ownership hatte ich zunächst gar nicht gesehen, diese dürfte jedoch die Lage stets verbessern, da sie eine bessere Verteilung der Aufgaben bewirkt und außerdem dem PO dezidierte Ansprechpartner zur Verfügung stellt, die ihre Teil-Themen vorantreiben müssen und auch für deren Darstellung nach außen sowie deren Aufbereitung für das Planning und etwaige Refinements verantwortlich sind.

Ins Rollen kommende Steine

Was ich auch nicht erwartet hätte, war, dass der PO des Teams in puncto Verbesserungsideen für das Planning nach und nach "aufblühte" und immer mehr neue Ansätze entwickelte. Vielleicht wurde das Planning auch dadurch zu einem "Fokusthema", dass ich selbst immer mal wieder Impulse zu dem Thema gesetzt, eigene Vorschläge eingebracht und dem PO den Rücken zu stärken versucht hatte. Auch hier zeigt sich: Nicht immer gleich besitzergreifend das Steuer an sich reißen, sondern hier und da ein bisschen ankurbeln und gucken, was aus dem Team-Wald herausschallt.


Moving Motivators

In einem Team, ebenfalls bestehend aus Teilteams, kam ich einmal auf die grandiose Idee, die Retrospektive nach dem Format "Moving Motivators" durchzuführen. Ich wollte das schon immer einmal gemacht haben, investierte auch Zeit in eine gute Vorbereitung und hoffte, dass sich die Teammitglieder untereinander besser kennenlernen könnten. Weit gefehlt: Während die Beschreibungen im Internet von tollen Diskussionen zwischen den Mitgliedern faselten, die sich im Team angeblich entspinnen sollten, war es bei meinem Team völlig anders: Alle machten mit, brachten brav ihre Motivatoren in eine Reihenfolge, guckten dann, was die anderen für eine Reihenfolge gelegt hatten, nickten zufrieden, lächelten teils ein wenig, wenn sie das Ergebnis ihrer drekten Teilteam-Kolleg:innen sahen, und sagten nur: "Ja - passt."

"Goldene Wasserhähne programmieren" als Teamcoach

Vielleicht hätte ich mir vorher überlegen sollen, dass sich die Leute innerhalb ihrer kleinen Teil-Teams so gut kennen, dass die Moving Motivators keine Überraschung darstellen. Außerhalb der kleinen Teil-Teams gab es dagegen offenbar so wenig Berührungspunkte, dass man die Reihungen der anderen einfach hinnahm, bestenfalls mit einem interessierten "Aha, so, so!" Daran änderten auch Fragen nichts, die ich in den Raum stellte, um noch einen Austausch in Gang zu bringen (wie sich das schon anhört, man sieht es förmlich vor sich: Der Teamcoach hat sich etwas in den Kopf gesetzt und versucht z. B., eine tonnenschwere Maschine unter Schweißausbrüchen anzuschieben, bewegt sie aber eigentlich keinen Millimeter vom Fleck). Vielleicht waren es die falschen Fragen... Immerhin, so bemerkte eine Gästin fidel, wären ja keine Motivationsdurchhänger sichtbar - was dem ratlosen Teamcoach dann auch noch die Grundlage für Verbesserungsmaßnahmen aus dieser Retrospektive entzog. Vor dem Team bekannte ich offen, dass die Aktion ganz anders geplant war, und dass das wohl nix gewesen sei. Macht auch mal nix.

Marie Kondo kehrt JIRA

In nicht nur einem Team hatte ich die undankbare Aufgabe, die ich auch noch selbst angeboten hatte, dass ich mich um ewig offene Tickets (Stories, Fehler, Anforderungen usf.) kümmern würde. Zuhause mag ich es auch nicht, wenn zu viel herumsteht und den Weg auf die wichtigen Dinge versperrt, wenn überall Zeug herumliegt. In Wohnungen oder Häusern mancher Leute sind alle Wände vollgehängt und steht auf jeder Fensterbank irgendein Geraffel, sodass man nicht einmal mehr problemlos und spontan das Fenster öffnen kann. Angst vor freien, aufgeräumten Flächen. So ähnlich ist es auch in manchen JIRAs dieser Welt, übertragen gesprochen. Ich dachte, wenn ich ein paarmal genervt habe und wir besprochen haben, was für die einzelnen Aufgaben zu tun ist, dann sind die Aufgaben auch wieder präsent, und die Menschen werden sie schon selbst aus dem Kreuz haben wollen. Hahaha. War aber nicht so.

Immer wieder dieselbe Fliese fegen

Nachdem ich mich für viele Wochen immer wieder mit den einzelnen Personen zusammengesetzt und gefühlt immer wieder an den gleichen Punkten aufgesetzt hatte ("noch nichts gemacht", "müssen immer noch warten auf xyz", "ach, ja, stimmt ja, das da.." etc.), wurde mir klar, dass das Aufräumen so nicht klappen würde. Marie Kondo ist übrigens eine zeitgenössische Aufräum-Queen aus Japan, die natürlich auch Bücher über ihre Arbeit geschrieben hat /1/. Aber das ist eine andere Geschichte. Mir kam natürlich zuerst der Gedanke, dass all die Aufgaben, wenn sie all die vielen Wochen lang nicht erledigt werden ja so wichtig nicht sein können (bis auf Ausnahmen, die die Regel bestätigen mögen).

Mit dem JIRA-Besen ins Rampenlicht

Der zweite Gedanke war dann, nicht nur einzelne Leute zum JIRA-Putzen zu bitten, sondern mit dem gesamten Team zu prüfen, welche Aufgaben einfach geschlossen werden können. Ich hoffte, dass sich in größerer Gruppe eine Dynamik entwickeln würde, die z. B. ewigen Sammlern zu Leibe rücken und sie davon überzeugen würde, dass eine alte offene Aufgabe nicht mehr weltverändernd sein würde. Diese Rechnung ging zumindest auf. Freund bildlicher Titel nannte ich die Veranstaltung "Sack zu", und das Team entschied gemeinsam, dass für einige Aufgaben nur noch ein winziger Schritt notwendig sei, um sie guten Gewissens schließen zu können, andere Tickets konnten erfolgreich sofort dichtgemacht werden. Auch hier gilt wieder der Rat "Take it to the team".

Verbesserung der internen Tätigkeiten - aber wie?

Mein Plan, interne Arbeitsprozesse in einem Team zu verbessern, sollte auf ganz oben genannte "mehr als 50% Verbesserung für die internen Tätigkeiten" einzahlen. Dass mir nicht klar war, wie ich die Messpunkte dafür setzen sollte, machte nichts, denn es dauerte unglaublich lange, bis ich - teils über Umwege - an diese internen Arbeitsprozesse überhaupt erst mal herankam. Der Workshop zum Ticket-Bearbeitungsprozess brachte viel weniger Erkenntnisse als erhofft, auch der darin gemeinsam visualisierte Prozess mit diversen Entscheidungspunkten nahm sich regelrecht popelig aus.

Manuelle Arbeit verringern

Einem anderen Team hetzte ich Fragen nach möglichen Maßnahmen zur Reduktion manueller Arbeit auf den Hals, letztere mache nach meinem Eindruck einen nicht unbeträchtlichen Teil ihres Tagesgeschäfts aus. Darauf versicherte man mir, dass es schwierig sei, manuelle Arbeit noch weiter zu verringern, und dass man das Thema vor einiger Zeit bereits aufgerollt und Prozesse optimiert habe. (Das sind dann immer die Momente, in denen man sich als geisteswissenschaftlich geprägter Scrum Master oder Teamcoach wünscht, der Mega-Techie zu sein, um solche Aussagen bewerten zu können. Oder man muss Geduld haben und darauf warten, dass jemandem der Kragen platzt, der dieses technische Wissen mitbringt...)

Wie wäre es mit... Testautomatisierung?

Als ich bei obigen Themen zunächst auf der Stelle trat, entschied ich, mit einem Fachmann das Thema "Testautomatisierung" zu besprechen. Fazit: Es gab keine (und dieser Konzern war nicht der einzige, dem dieses tragische Schicksal beschieden war - in einem anderen Unternehmen hatte man Jahre mit Diskutiererei zugebracht und konnte sich aus unerfindlichen Gründen nicht mal auf ein Test-Tool einigen). 

Irgendwer hat doch bestimmt schon was gemacht

Ich hatte gehofft, mich an dem Thema entlanghangeln zu können à la: Was wurde bisher gemacht, wer hat sich damit bereits beschäftigt, welche Tools wurden von der Test-Truppe bereits ausprobiert und mit welchen Ergebnissen, welchen Rhythmus gibt es für wenigstens Teil-Automatisierungen, welche automatisierten Testfälle werden bereits benutzt etc.? Dann hätte ich gehofft, mich von Kolleg:innen mit passendem technischen Hintergrund aufschlauen zu lassen. Gut sind ja auch immer Rechnungen in Euro und Cent à la "wenn du das 100 mal durchklickst, ist so viel Zeit weg, die kostet bei deinem Gehalt xyz, und dazu noch ist das Risiko manueller Fehler gegeben. Wenn du das automatisierst, hast du einen Initialaufwand von x und immer wieder leichten Wartungsaufwand von y, aber dafür bei allen Deployments eine enorme Zeitersparnis, ein geringes Fehlerrisiko und ein leichteres Aufsetzen von Regressionstests, was sich in Euronen folgendermaßen ausdrückt...".

Wieder ein dickes altes Brett zu bohren

Stattdessen bekam ich von einem Kollegen die Aussage, dass das Thema Testautomatisierung so alt wie das Unternehmen selbst sei. Und dieses hatte vermutlich schon viele Menschen kommen und gehen sehen, die durchaus mehr von dem Thema verstehen als ich. Ich will ganz offen sein: Der Prozess des Versuchs der Verbesserung interner Tätigkeiten läuft immer noch, vermutlich noch lang, wenn man mich lässt. Ich kann nur beten, wie Reinhold Niebuhr es der Welt gezeigt hat: "Gott, gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann, den Mut, Dinge zu ändern, die ich ändern kann, und die Weisheit, das eine vom anderen zu unterscheiden." /2/


Synchronisierung von Kalenderblockern

Ich kam als externe Arbeitskraft in eine Unternehmung, wie so viele, die gefühlt fast ständig kommen und gehen, immer ein bisschen Spuren hinterlassen, aber stets auch einiges Wissen wieder mitnehmen. Verbindungen in Communities sind gekappt, müssen mit zunächst fremden Menschen neu aufgebaut werden. Manche guten Ansätze bleiben wahrscheinlich liegen, weil sich kein anderer mit ihnen identfizieren kann. Ich sah das Bild eines Konzerns, der die gleichen Probleme hat wie andere, wenn er versucht, Scrum oder die vermeintlichen Rosinen daraus zu skalieren. Inzwischen kenne ich mindestens ein toxisches Arbeitsumfeld in einem großen schein-agilen Programm, und ich kenne auch aus mehreren Beispielen von Initiativen die Flut an Terminen, weil sich niemand von Beginn an Gedanken darüber gemacht hat, wer mit wem in welchen Formaten reden muss. 

Exponentielle Kommunikationskanalanzahlkurve

Stattdessen reden gefühlt alle mit allen, vorsichtshalber, und das Ergebnis der Formel für die Anzahl an Kommunikationspfaden je Anzahl beteiligter Personen (N(n-1))/2 explodiert /3/. Ich erwartete, dass auch in diesem Umfeld daran nicht zu rütteln war und dieses Thema eine Nummer zu groß (bzw. zu "zäh") für mich oder irgendwelche anderen Einzelpersonen war.

Eines Tages sprach ich in der Teamcoach-Community über das Thema "Terminflut" in unserem gemeinsamen Bereich (eine Krankheit, die wohl jeder kennt, ich war allerdings jüngst zum ersten Mal in einer kleinen Arbeitsgruppe gelandet, die versuchte, sich des Themas anzunehmen und bereichsweite Termine "auszulichten" statt neue ins System hineinzupumpen). In den letzten Monaten waren nach und nach neue Teamcoaches hinzugekommen, andere waren zuvor gegangen, es kam also frischer Wind durch die Tür hinein. 

"Betriebsgeheimnis" lüften kann Brücken bauen

Mit einem Augenzwinkern und charmanter Offenheit bekannte einer beinahe beiläufig, dass sich sein Team Kalenderblocker einstelle, um zwischendurch endlich einmal konzentriert arbeiten zu können. Diese Blocker würden dann sehr wichtig betitelt, etwa "lateraler Strategie-Workshop" oder ähnliches. Nachdem der Damm gebrochen war, bestätigten auch andere Teamcoaches ähnliche Vorgehensweisen aus ihren Teams. Am Schluss wurde noch die Idee in den Raum geworfen, dass man doch eventuell bereichsweite Blocker vereinbaren könne - an bestimmten Tagen zu bestimmten Zeiten -, in denen dann ALLE konzentriert arbeiten können, ohne ein schlechtes Gewissen haben zu müssen.

Wir können alle an einem Strang (in der gleichen Richtung) ziehen!

Am Schluss der Veranstaltung machte ich allen bewusst, dass wir durch unsere Transparenz die einmalige Chance erhalten hätten, sinnvoll an diesem gemeinsamen Thema zu arbeiten, und bedankte mich bei dem betreffenden Teamcoach für sein Vertrauen und seine Offenheit. Der Prozess (ja, auch dieser) dauert natürlich zu lange, als dass man sein Ergebnis schon in den Händen hielte, aber Konsensfindung und erste gemeinsame Arbeit am Thema sind vielversprechend.

Tja, wie soll ich diesen Artikel beenden? Am besten mit einem passenden Zitat anderer: "Wenn wir unsere Erwartungen verringern, werden wir Zufriedenheit erfahren." /4/ (Das soll der Dalai Lama gesagt haben.)


Anmerkungen

/1/ https://de.wikipedia.org/wiki/Marie_Kond%C5%8D

/2/ https://de.wikipedia.org/wiki/Gelassenheitsgebet

/3/ https://www.projektmagazin.de/artikel/skalierung_grundprinzipien

/4/ https://www.aphorismen.de/suche?f_thema=Erwartung&seite=2

Kommentare

Beliebte Posts aus diesem Blog

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.