Schlagwort-Archive: Blogpost

Basketball, Erinnerungen

Benjamin Scharf Gedächtnisturnier

Schreibe einen Kommentar

Wir als Eltern von Benni möchten gern unsere Eindrücke vom Gedächtnisturnier am 10.07.21 in München wiedergeben.
Zuallererst vielen Dank an Igors und sein Team für die sehr gute Organisation.
Nachdem wir gemeinsam mit Igors im Februar darüber nachgedacht haben, ein solches Turnier zu veranstalten, hat es uns sehr gefreut, dass dies so schnell zu Stande kam. Auch wir haben uns Gedanken gemacht welchen Beitrag wir zum Turnier beisteuern können. Aber dazu später mehr.

Eine der beiden gastgebenden Mannschaften des TSV Trudering mit Igors vorne in der Mitte

Da wir nicht wussten was uns in der Sporthalle erwartet, waren wir sehr aufgeregt. Doch die Aufregung war schnell verflogen, da wir von allen sehr herzlich begrüßt wurden und uns sofort wohl gefühlt haben im Kreise von Bennis Sportfreunden und deren Angehörigen. Es wirkte wie eine große Familie und wir waren mittendrinn. Wir haben gemerkt, dass Benni auch für seine Freunde beim Basketball unvergessen ist. Er hat so viel Freude am Basketball gehabt und dadurch viele neue Freundschaften geschlossen, das wurde uns beim Besuch in der Halle bewusst. Dieses schöne Turnier war ganz in seinem Sinne und er ist gewiss sehr stolz auf all die Spieler, Schiedsrichter und Gäste, die für ihn dabei waren.

Das Team vom TSV Jahn Freising – Bens früherem Verein

Die Eröffnungsreden zu Beginn des Turniers waren für uns sehr emotional, aber sehr schön, da Benni mit seiner großen Liebe zum Basketball mit all seinen Facetten als Spieler, Trainer, Schiedsrichter und Freund aufgezeigt wurde. Dafür habt vielen Dank. Es macht uns sehr stolz, dass Benni auch beim Basketball in München und Jena so viele tiefe Spuren hinterlassen hat. Wir haben uns sehr aufgenommen gefühlt im Kreise seiner Sportfreunde und deren Angehörigen.

Überreichen des eigenes für das Turnier angefertigten Stein-Pokals

Zum Abschluss des Turnieres durften wir gemeinsam mit Lena und Igors die Siegerehrung durchführen. Für die Siegermannschaft wurde von unserem Steinmetz ein Pokal nach unseren Vorstellungen gefertigt. Für alle Spieler, Trainer, Schiedsrichter haben wir ein T-Shirt entworfen und mit Hilfe vieler guter Basketballfreunde diese herstellen lassen. Zur Siegerehrung konnten wir allen ein T-Shirt überreichen.

Der Siegerpokal – extra vom Steinmetz angefertigt
Auch eine Mannschaft vom USV Jena war extra angereist – hier bereits in den eigens entworfenen und gedruckten T-Shirts

Wir glauben diese Idee ist bei allen gut angekommen und die Überraschung ist gelungen, zumal wir zwei Tage vorher noch nicht wussten, ob die Shirts zum Termin fertig werden. Dafür danken wir nochmal allen Beteiligten für die große Unterstützung, besonders Bennis sehr gutem Freund Stefan Heist (Heisti), der unseren Entwurf druckgerecht für die Herstellerfirma umgesetzt hat.
Den Abend haben wir gemeinsam mit den Mannschaften und Schiedsrichtern im Biergarten verbracht. Es waren viele schöne und für uns sehr angenehme Unterhaltungen.

Das Benni nicht mehr bei uns ist, ist für uns als Eltern sehr schwer zu ertragen, doch dieser Tag bei Euch in München hat uns Kraft gegeben. Wir haben gemeinsam mit Euch an Benni gedacht und viel über ihn gesprochen. Dafür danken wir allen die dabei waren von ganzem Herzen. Benni hätte ein solches Zusammensein sehr gefallen.
Es war eine rundum gelungene Veranstaltung und vielleicht ist es möglich, das Turnier zu wiederholen.

Liebe Grüße an alle von Bennis Eltern Andrea und Dieter

LifeLongLearning

Blogpost: Meetings, die vom Ziel abdriften

Schreibe einen Kommentar

Bens TNG-interner Blogpost
Meetings, die vom Ziel abdriften

9. Dezember 2019
(editiert von Mathias Arens)

Vor kurzem hatte ich ein Refinement-Meeting mit etwa 10 Personen (Entwickler zweier Teams, UX Team, QA, Agilist, Team Lead)

Ziel des Meetings war es,

  • 3 verschiedene Optionen zu refinen,
  • deren Aufwand zu schätzen (in Form von Punkten für Team 1 und T-shirt Size für Team 2, aber dieses Konstrukt ist ein Thema für sich)
  • und damit eine Entscheidungsgrundlage für das Gespräch mit den Stakeholdern zu liefern, 
    • das aufgrund knapper Zeitlage (Weihnachtsgeschäft) am nächsten Tag geplant wurde

Für das Meeting hatten wir 1 Stunde eingeplant.

Nach 50 Minuten befand ich mich in der Situation, dass zwar alle Optionen vorgestellt worden waren (eigentlich waren sie das schon vor dem Meeting) und im Detail diskutiert worden waren – wir aber noch weit weg davon waren, eine Einschätzung zum Aufwand zu finden.

Das Meeting driftete dagegen ab in eine generelle Diskussion zu den Themen:

  • Was ist die Rolle von UX
    • Darf ein PO […] mit Stakeholdern alleine entscheiden, welcher Vorschlag gebaut werden soll oder hat UX ein Veto-Recht?
    • Was ist, wenn UX ein Feature in schön möchte, PO und Stakeholder […] aber ein Release in diesem Jahr für „wertvoller“ hält?
  • Welche von den 3 Varianten favorisiert XY
  • Was ist bei dem Feature bereits alles schief gelaufen in der Kommunikation […].

Frage an euch:

  • Wie hättet ihr in dieser Situation als PO reagiert?
  • Wie hättet ihr in dieser Situation als Agilist (Scrummaster) reagiert?

Später gibt es dann die „Auflösung“

  • was habe ich als PO getan?
  • wie ging es weiter?
  • was würde ich nach einigen Tagen Nachdenken (anders) formulieren?

Auflösung:

Was habe ich als PO getan?

  • zwei Mal die Frage gestellt „What prevents us from doing an estimation?“ – was wiederum 2x in eine Rollendiskussion abdriftete
  • Nach 50 Minuten hatte ich dann wirklich „Die Schnauze voll“ ? Dann kam der Ausspruch (auf den ich nicht stolz bin): „Either, we are now going to estimate the 3 options or I am ending the meeting“ 

Wie ging es weiter?

  • Daraufhin gab es Stille im Raum und jemand fragte in etwa „What’s blocking you guys from providing an estimation?“ 
  • Innerhalb von 10 Minuten wurden dann alle 3 Optionen geschätzt
  • am Ende wurde sich auf die mittlere Option geeinigt, nachdem klar wurde, dass keine der 3 Optionen noch dieses Jahr released werden kann, und die favorisierte Version von UX mehrere Risiken beinhaltet
    • Stakeholder […] waren nicht happy, haben es aber hingenommen
  • danach folgten längere persönliche Gespräche mit verschiedenen Teilnehmern des Meetings. 
    • ein Action-Item ist, dass wir per Feature (insbesondere mit mehreren Releases) Feature-Retros durchführen.
  • Mit einem anderen Teilnehmer hab ich bis heute keinen Austausch zum Meeting gehabt. Dafür hat der Techlead mit ihm geredet. Ich hoffe mal, dass er bald Zeit für mich findet.
  • Das Thema Rollenverständnis UX ? PO wird inzwischen Team-übergreifend diskutiert.

Was würde ich nach einigen Tagen Nachdenken (anders) formulieren?

Ich glaube schon, dass es in der Situation wichtig und richtig war, die Karten auf den Tisch zu legen. Eine Vermeidung des Konfliktes oder ein „Ich nehme die komplette Frustration auf mich“ wäre nicht sinnvoll gewesen.

Gleichzeitig ärgere ich mich über die viel zu kurze und unsaubere Formulierung. Viel besser wäre etwa folgende Kette gewesen:

„We have 10 minutes left and I know that we cannot prolong the meeting today. Let me ask you straight: Is there something that really blocks us to give an estimation for the talks with the Stakeholders? If not, let’s estimate now. If there are, then let’s end the meeting here and discuss in a smaller round“

Als Notiz am Rande:

Es ist nicht so leicht greifbar, wie viel ein Remote Setup kostet. Schätzungen anderer Consulting-Unternehmen sprechen von 30% Produktivitäts-Verlust, wenn eine Person nicht am gleichen Ort ist.

Hier in dem Beispiel bin ich zu 100% sicher, dass die lausige Verbindungs-Qualität dazu beigetragen hat, die Emotionen hochzuschaukeln und verkürzende Sätze provoziert.

LifeLongLearning

Blogpost: The Clean Coder – and why I don‘t like it

Schreibe einen Kommentar

Bens TNG-interner Blogpost
The Clean Coder – and why I don‘t like it

26. August 2018
(editiert von Martina Schäfer)

Robert C. Martin as an author is probably most known for “Clean Code“  […].

His book “The Clean Coder: A Code of Conduct for Professional Programmers” from 2011 looks at another perspective of today’s coding and tries to teach “what it means to behave as a true software craftsman”. In my own words: the social aspects of the daily work of a programmer.

What I like about the book

The real life stories of Martin reaching back into the 70s give a view into what it was like to be a programmer in those times – and how much more manual work it involved. Furthermore, he is open about how he failed and why.

I like the general idea of the chapters “Saying No” and “Saying Yes”. This is something important to learn. However, the examples are very artificial and hard to generalize…

Why I don’t like the book

Basically, I have 3 main complaint points about this book. Please be aware that they are my subjective opinion and bound to my everyday situations and experience as a Product Owner.

  1. I think the author sees Agile as a process to improve development and developers, not a way to change companies into a more human-centric and successful place. In particular, the book does not even go into the direction of Scrum mechanisms to cope with typical situations between stakeholders and development teams. This surprises as the book is from 2011 and Agile practices are widely accepted in the world of software.
  2. the examples for talks between “management” and “coders” are so extreme that I would rather change the project than recommending any technique to deal with these kind of unrealistic expectations.
  3. the book does not teach any techniques of reflection, how to give feedback, how to deal with conflicts, how to communicate, not even a slight bit of psychology. For me, this is a main aspect that every developer should look into. Personally, I benefited the most from learning about these.

Summary

To be honest, I think the whole learning point of this book could be brought down to 2 blog posts of maybe 10 pages with lots of links to people who explained the details much better than Martin. And 2 statements to keep in mind.

 […]

Blog Post 1

These are the 10 things you should think and read about as a professional software developer

Blog Post 2

Why I failed in my professional software developers life and what I learned from it

Statement 1

Say NO when you would like to say maybe

Statement 2

Usually, a YES comes with a set of conditions. Make them transparent.

LifeLongLearning

Blogpost: Der Dilbert Autor über „Gutes Schreiben“ – The Day You Became A Better Writer

Schreibe einen Kommentar

Bens TNG-interner Blogpost
Der Dilbert Autor über „Gutes Schreiben“ – The Day You Became A Better Writer

16. Mai 2017
(editiert von Martina Schäfer)

Dieser Artikel von Scott Adams ist fast genau 10 Jahre alt, megakurz und kein bisschen veraltet:

http://dilbertblog.typepad.com/the_dilbert_blog/2007/06/the_day_you_bec.html

Seine Regeln:
  • „Write short sentences.“
  • „Avoid putting multiple thoughts in one sentence.“ (keine Nebensätze)
  • „The main technique is keeping things simple. Simple means getting rid of extra words.“
  • „Your first sentence needs to grab the reader.“
Zum Vergleich:
Die „goldenen Regeln“ meines TUM Mathe-Professors:
  • „Write correct sentences“
  • „Every sentence add one information“
  • „Every sentence is directly connected to the next“
Habt ihr ähnliche/andere Regeln, die euch beim Schreiben (insbesondere im Beruf helfen)?
LifeLongLearning

Blogpost: VHS-Kurs: „Präsenz zeigen – ihr starker Auftritt“

Schreibe einen Kommentar

Bens TNG-interner Blogpost
VHS-Kurs: „Präsenz zeigen – ihr starker Auftritt“ […]

29. Juli 2016
(editiert von Martina Schäfer)

Zugegeben, als ich die Idee präsentiert bekam, an einem Volkshochschulkurs zur Weiterentwicklung meiner Persönlichkeit teilzunehmen, kamen in mir erstmal die üblichen Klischees auf:

  • was für Hausfrauen über 50
  • unterbezahlte Trainer, die sonst keine Arbeit finden
  • Kurse wie Qi Cong oder die Feldenkrais-Methode (wink)

Aber erstens kommt es anders, und zweitens als man denkt.

So stand ich an einem Freitag Abend 19:30 Uhr in einer Gruppe voller Kommunikationstrainer, Marketingverantwortlicher, Unternehmensberater, Jobcoaches, Projektleiter (12 Personen) und einem Trainer namens Carsten Schleuß [1], der Schauspieler, Fotograf, Einzelshandelskaufmann und irgendwie auch ein bisschen Überlebenskünstler war und ist.

Ein bisschen Background zum Thema

Albert Mehrabian führte 1971 mit ca. 50 Versuchsteilnehmern Kommunikationsexperimente durch, bei dem er die gleichen Wörter immer wieder mit verschiedenen Stimmen und Optik sagen ließ. Grob vereinfacht, kam er zu dem Schluss, dass die Wirkung der Person durch

  • Optik: 55 %
  • Stimme 38 %
  • Inhalt 7 %

( Am Telefon : Stimme: 87 % / Inhalt: 13 % )

bestimmt wurde. Dass diese Ergebnisse auch oft falsch oder zu extrem interpretiert werden, kann man unter [2] nachlesen.

Ingesamt kennt bestimmt jeder Mensch die typische Situationen:

  • Wieso habe ich mir diesen (Handy)-Vertrag aufschwatzen lassen?
  • Wieso glaube/traue/wähle ich diesen Politiker, obwohl ich seine Kompetenzen doch überhaupt nicht einschätzen kann (ich nenne das etwas abfällig den Guttenberg-Effekt)?
  • Warum sind die erfolgreichsten Professoren nicht die, die die herausragendsten Ergebnisse finden, sondern die, die sie auch einem allgemeinen Publikum zugänglich machen können?

Das war und ist immer wieder Anlass für mich, sich mit den nicht-inhaltlichen Themen der Kommunikation und des Auftretens zu beschäftigen.

Ablauf des Seminars

Nach der üblichen kurzen Vorstellung des Trainers und der auch bei TNG-Workshops inzwischen üblichen „Was wünsche ich mir vom Workshop“-Runde stiegen wir direkt in eine erste Spielerunde ein. Mal im Kreis, mal zu zweit, mal in der ganzen Gruppe übten wir Einzelaspekte des persönlichen Auftritts

  • wie halte ich Blickkontakt?
  • wie stehe ich sicher?
  • wie gehe ich mit Situationen um, in denen ich nicht weiß, was ich sagen/antworten soll?
  • wie komme ich zur Ruhe und entspanne trotz Stress?
  • wie wirke ich präsent vor einer Gruppe?
  • wie werde ich in Diskussionen gehört?

Im Folgenden gebe ich ein bisschen Einblick in die einzelnen Übungen

Die erste Übung – Assoziieren
Eigentlich ganz simpel:
  1. Die Gruppe steht im Kreis
  2. Person A sagt ein Wort und gibt es an Person B weiter (Blickkontakt, Gestik, …)
  3. Person B wiederholt das Wort und nennt nachfolgend ein weiteres Wort, das sie mit dem ersten Wort assoziiert. Sie gibt dieses Wort an Person C weiter (Blickkontakt, Gestik)
  4. usw.
Was wird geübt?
  • Den Blickkontakt und die Präsenz in der Gruppe auch dann zu halten, wenn einem nicht sofort ein neues Wort einfällt
    • man neigt doch schnell dazu, aus seiner Haltung zu fallen, wenn man nachdenkt (wink) Mit dem Abwenden des Blickes und des Körpers verliert man die Präsenz
  • Durch die Wiederholung des Wortes der vorherigen Person verschafft man sich Zeit zum Nachdenken
    • eines der Lieblingsmittel im Vertrieb: „Verstehe ich sie richtig, dass sie sich folgendes wünschen/fordern/sehen…?“
    • Kernidee: Die Pause des Nachdenkens mit Inhalt füllen.
  • Weiter atmen lernen
Für den Alltag

Versucht mal, beim Bäcker, an der Käsetheke, im Restaurant Blickkontakt mit der Bedienung zu halten – das gesamte Gespräch über.

Die härteste Übung für mich – Mein Auftritt
Wieder ganz simpel:
  1. Die Gruppe sitzt in einer Reihe
  2. Einer aus der Gruppe geht hinter eine Pinnwand und sammelt sich
  3. Er tritt hervor, sucht sich einen sicheren Standpunkt in dem für ihn passenden Abstand
  4. Ohne zu reden, steht man da, Blickkontakt zum Auditorium suchend
  5. Nach einer Weile (ca. 20 Sekunden, die viel länger wirken) gibt der Moderator ein Zeichen
  6. Daraufhin begrüßt man die Gruppe und stellt sich vor: „Guten Tag, meine Name ist …“
Was wird geübt?
  • Weiter Atmen (wink)
  • Richtige Wirkung
  • guter Blickkontakt, der allen Anwesenden das Gefühl gibt, beteiligt zu sein
  • eine Begrüßung und seinen Namen sauber und verständlich wiederzugeben, in einer Weise, die zum körperlichen Auftreten passt
  • Ruhe bewahren vor ungewohnten Situation (bei mir: ordentlicher Herzschlag (wink))
Für den Alltag

Versucht mal, darauf zu achten, wie ihr euren eigenen (vollen) Namen aussprecht und wie das beim anderen ankommt. Kann man da was verbessern?

Meine Lieblingsübung – Sich durchsetzen in einer Gruppe
Und wieder simpel:
  1. Alle sitzen in einem Stuhlkreis, als fiktive Mitarbeiter einer Firma
  2. Jeder wählt ein gewünschtes Ausflugsziel für den Firmenausflug – aber jeder ein anderes
  3. Man versucht, sein Ausflugsziel in der Gruppe durchzusetzen
  4. Alle rhetorischen Mittel sind erlaubt
Was wird geübt?
  • Die erste Runde war das absolute Chaos:
    • Fiese Tricks unter der Gürtellinie
    • lautes Überstimmen und Durcheinander rufen
    • einige Teilnehmer, die sich schnell aufgaben
    • kein Konsens
  • Danach gibt der Moderator einige Tipps und man probiert das Ganze nochmal. Einige Tricks:
    • Suche Konsens und Koalitionen mit einigen Personen
    • Äußere Wunsch/Bitte (das bekannte „Jetzt lassen sie mich doch mal ausreden“)
    • Blickkontakt erzwingen und damit Aufmerksamkeit einer Person bekommen
    • und vor allem auch: Seine Rede durchziehen und nicht stoppen (gegebenenfalls lauter)
Für den Alltag

Talkshows, Talkshows, Talkshows. Immer wieder spannend zu sehen – welche Mittel nutzen insbesondere Politiker, um in einer Runde zu Wort zu kommen? Was kommt gut an, was schlecht? Was ist fair, was ist unfair?

[….]

Quellen:

[1] http://www.active-seminare.de/

[2] https://www.quora.com/Is-Albert-Mehrabians-7-38-55-rule-Verbal-Vocal-Visual-or-7-93-rule-Verbal-Nonverbal-still-valid-in-human-communication

LifeLongLearning

Blogpost: E-Mail parsen und verarbeiten mit Zapier

Schreibe einen Kommentar

Bens TNG-interner Blogpost
E-Mail parsen und verarbeiten mit Zapier

30. Dezember 2015
(editiert von Martina Schäfer)

Zwischen Weihnachten und Silvester habe ich mich mal mit einem Problem beschäftigt, dass mich immer wieder Zeit kostet. An einem Beispiel möchte ich euch erklären, wie man mit Zapier und seinem E-Mail Parser relativ komplexe automatische Handlungen aus wiederkehrenden, gleich strukturierten E-Mails vornehmen kann. Natürlich kann man das auch per Regex und sed oder ähnlichem lösen (wink)

Ausgangslage:

  • 1-2 Mail im Monat erhalte ich 3-10 E-Mails im gleichen Format mit Ansetzungen als Basketball-Schiedsrichter, die enthalten
    • Ort, Zeit, Kollege, Halle mit Adresse, …
    • leider kein ICS-Anhang, um sie direkt in den Kalender zu übertragen.

Ziel

  • generiere aus diesen E-Mails automatisch Kalender-Einträge
  • generiere mir eine Vorlage für eine E-Mail, die ich 2-3 Tage vorher an den Schiedsrichter-Kollegen schicke, wo ich nochmal die Grunddaten checke und ihm mitteile, wann ich in der Halle bin.

Umsetzung:

Schritt 1:

Mails parsen. Mit dem Mail-Parser von Zapier (1), der komplett kostenlos ist, lassen sich E-Mails, die einer gleichen Grundstruktur gehorchen, parsen. 

Am Ende dieses Schrittes hat man eine Mailbox mit all seinen E-Mails und dem geparsten Text in Listenform:

So sah die Mail vorher aus:

Und das ist der Output

Schritt 2:

Nun wollte ich natürlich die Information auch anhand von Regeln (im Sinne von „If this, then that“) verarbeiten. Dazu nutze ich das Tool Zapier (2). Leider ist Zapier nur kostenlos bis 100 ausgeführte Tasks pro Monat und bis zu 5 ausgeführten Zaps (angelegte Regeln). Danach wird es schnell teuer (20 Dollar pro Monat für Stufe 1). Als kostenlose Alternative bietet sich IFTTT (3) an. Leider gibt es zu IFTTT keinen eigenen Mail Parser, man müsste ihn sich vermutlich in irgendeiner Weise selbst schreiben, siehe (4), oder einen anderen Mail-Parser finden, der IFTTT in geeigneter Weise anspricht.

Mit Zapier verbinde ich nun den Zapier Mail-Parser mit meinem Google Kalender. Der automatische Flow ist dann wie folgt

  1. Leite eingegangene Mail (automatisch) an Mail-Parser Inbox weiter
  2. Mail-Parser erstellt den passenden Output
  3. Zapier triggert die Erstellung eines Google Kalender Eintrags

Für 3. muss man bei der Erstellung des Zaps nur die entsprechenden Tags, die der Mail-Parser auswirft, den passenden Feldern im Google Kalender Event zuordnen. Bei mir sieht das in etwa so aus:

Weiterhin verbinde ich mit einem zweiten Zap den Mail-Parser mit meinem Google Mail Konto und lasse mir einen Mail-Entwurf mit den wichtigsten Daten der Schiedsrichter-Ansetzung und immer gleich bleibendem Text (smile) schicken. Fertig!

Nebenbemerkung: Vergleich Zapier und IFTTT

Das kostenlose IFTTT ist sicher vom Funktionsumfang und von der Anzahl der Apps und Tools, die man automatisieren kann, deutlich schwächer als Zapier. Aber trotzdem, man kann coole Sachen damit anstellen:

a) Ich lasse mir morgens und abends eine Mail mit dem Wetterbericht schicken, die auch als Benachrichtigung auf meiner Pebble Smartwatch erscheint. So werde ich nochmal gewarnt, falls Regen angesagt ist und ich mich als Fahrradfahrer entsprechend vorbereiten sollte

b) Hätte ich ein Android Smartphone, würde ich Folgendes nutzen: Starte google maps mit der Verbindung nach Hause/zur Arbeit, wenn man das Haus verlässt.

c) IFTTT arbeitet auch mit Android Wear und damit mit nahezu jeder Smartwatch zusammen. Benachrichtigungen aller Art sind möglich.

d) Heimautomatisierungs-Freunde finden diverse Möglichkeiten: So lässt sich die Lampe Philips Hue per Tageszeit, Wetterbericht, oder beim Siegder NBA-Lieblingsmannschaft einschalten. Oder das Licht und die Heizung geht an, wenn man das Haus betritt.

e) und für die Atlassian-Freunde: JIRA ist auch dabei.

f) eine meiner Lieblingsapps ist Pushbullet, das schnell zum Text- und Datenaustausch zwischen mobilen Geräten und Desktop-PCs genutzt werden kann. Die Pro-Version bietet sogar ein Universal Clipboard, also eine Zwischenablage, die zwischen den Geräten synchronisiert wird. IFTTT bietet auch eine Pushbullet-Integration…

Zusammenfassung

Der Haken der meisten Automatisierungen ist ja oft, dass die Umsetzung zu lange dauert, dass es sich für kleine, private wiederholende Tasks nicht lohnt. Mit Zapier und dem Mail-Parser habe ich gelernt, dass es a) Spaß macht und b) auch privat in kleinem Kreise Sinn machen kann, E-Mails automatisch abzuhandeln. Beide Tools, Zapier und IFTTT, bieten Unmengen an Möglichkeiten, die jeder für sich selbst entdecken kann.

(warning) Aber denkt an den Datenschutz… 

(1) Infos zum Mail Parser: https://parser.zapier.com/ (kostenlos)

(2) Infos zu Zapier: https://zapier.com/app/dashboard (sehr eingeschränkt kostenlos) 

(3) Infos zu IFTTT: https://ifttt.com/ (kostenlos) 

(4) Mail-Parser für IFTTT selbst basteln: http://webapps.stackexchange.com/questions/69028/is-there-a-way-to-automatically-extract-e-g-regex-information-e-g-prices-f

LifeLongLearning

Blogpost: Die Product Owner User Story Check List

Schreibe einen Kommentar

Bens TNG-interner Blogpost
Die Product Owner User Story Check List

24. February 2017
(editiert von Martina Schäfer)

Vermutlich alle bzw. viele von euch kennen die folgenden Check Lists:

Definition of DoneWann ist ein Task fertig? Wann ist eine Story fertig?Implementation, Code Review, Story Review, Sprint Review
User Story ChecklistHaben wir alles beachtet? Woran müssen wir noch denken?Planning 2
Definition of ReadySind alle Fragen geklärt, sodass wir mit der Entwicklung starten können?Grooming/Backlog Refinement und Planning 1

[….]

Product Owner User Story Check List

Da wir inzwischen beim Kunden mehrere POs sind, haben wir uns gefragt, ob es nicht auch Sinn macht, eine ähnliche Checkliste mit Projektbezug auch für die Arbeit der Product Owner zu erstellen. Man stellt sich im Prinzip die Frage:

Welche Dinge muss ich alle bedenken, um eine Story „Ready for Estimation“ zu machen und zu versuchen, mit den Akzeptanzkriterien möglichst viele Punkte bereits abzudecken?

Herausgekommen ist dabei der unten stehende Entwurf, der natürlich ein Work in Progress ist.

Fragen an euch, speziell die Product Owner/Business Analysten:

  • Habt ihr ähnliche Listen für euch selbst oder gar im Team?
  • Haltet ihr sie für sinnvoll?
  • Welche Punkte findet ihr sinnvoll/wenig sinnvoll?

Die Liste: Questions to ask when preparing stories

Concerning Pre Development
  • Which departments/people have to deliver data/designs/information for the Development? 
  • Customer Care/Communication: Did we inform Person 1 and Person 2 and got their opinion on the story?
Concerning In Development
  • Which departments/people are involved in the Development? 
  • Whose expectations (departments/people) need to be managed?
Concerning Post Development
  • Are we expected to roll this out to a specific audience only?
    • Countries
    • Languages
    • Specific Customers
  • Which departments/people are affected by the Development?
    • What implications does the story might have on those?
    • Who is to be informed of the changes and when?
      • Is it enough to inform with the release mail or sprint review?
  • How do we measure the impact and success of the Story (after its release)?
    • Can/Should we use Tracking/Reporting for/by
      • Tool 1
      • Tool 2
      • Tool 3
  • Which parts of the Story should be configurable/changeable without a release?
LifeLongLearning

Ein Einstieg ins Zeitmanagement

Schreibe einen Kommentar

Hier Benjamins Vortrag, bzw. eigentlich eher Workshop am Winterretreat 2017 von TNG.

Getting Things Done und Todo.txt
Ein Einstieg in Zeitmanagement
Benjamin Scharf, Tirol, 2017-03-24

GTDWR17-Getting-Things-Done-und-Todo.txt

Bens TNG-interner Blogpost zu diesem Workshop

18. April 2017
(editiert von Martina Schäfer)

Ziel des Halbtages-Workshops war es, innerhalb von 2,5 h die Grundlagen von Getting Things Done zu behandeln und zu erlernen, wie man sich schnell und einfach ein eigenes Aufgaben-Management-System bauen kann. Am Beispiel von todo.txt haben wir gemeinsam ein Task-Management System aufgesetzt. Dabei kam natürlich auch der Erfahrungsaustausch, insbesondere zum Thema „Was hab ich schon alles probiert, was nicht funktioniert hat“, nicht zu kurz.

Inhaltlich begaben wir uns in die 5 Phasen „Capture, Clarify, Organize, Review, Engage“ und spielten sie anhand eigens gewählter Beispiele aus dem wahren Leben durch – von „welche Eingänge habe ich eigentlich und wo kommen meine Aufgaben her“ bis zu „ein perfekt präparierte Liste, wo jede Aufgabe actionable und ausführbar ist“.

Als Experte und erfahrener Anwender hatten wir spontan Christoph Stock [einen der Partner von TNG] zu Gast, der uns aus seinen Erfahrungen aus plain-text todo Listen mit 2000 und mehr Tasks erzählte, während Menschen wie ich sich schon mit 325 Tasks (Stand heute) fühlen, als ob so viel hinten runterfällt. Insbesondere das Thema Weekly Review – also dem wöchentlichen Überprüfen der Task-List, aber auch des eigenen Systems – nannte Christoph als Kernpunkt zum erfolgreichen Management der eigenen Aufgaben. Schade, dass wir das kaum vertiefen konnten, denn die Zeit verging wie im Flug.

Ich war froh, dass wir die einzelne 5 Schritte, Prioritäten, Kontext, Projekte und wie man sie abbildet noch irgendwie in der Zeit geschafft haben, was aber dazu führte, dass die Feedback-Runde ausfallen musste. Also dann doch lieber 3-4 h Zeit nehmen (smile) 

Ich bin gespannt, was unsere Teilnehmer mitgenommen haben und ob sie ihr eigenes Task-System entwickelt/weiterentwickelt haben.