Scrum - Sprint / Team Retrospektive

Die Sprint Retrospektive findet am Ende des Sprints statt. Hierbei überprüft das gesamte Scrum Team seine Arbeits- und Verhaltensweise während des Sprints, um im nächsten Sprint noch effektiver und effizienter arbeiten zu können.

Ablauf

• Es sollte eine angenehme Atmosphäre für das Team geschaffen werden,
• z.B. durch den Raum, der Umgebung und dem Zeitpunkt,
• jedes Teammitglied sollte Zeit für die Vorbereitung auf den Termin haben.
• Die Daten werden vom Scrum Master gesammelt (Erkenntnisse und Einsichten) und z.B. auf einem „Board“ festgehalten.
• Abschließend werden Aktionen und Verbesserungsmöglichkeiten daraus abgeleitet.

Beispiel

• Eine Pinnwand mit den Symbole: "Gewitter", "Regen", "Sonne".

Quelle: https://cdn.pixabay.com/photo/2013/07/12/12/53/weather-forecast-146472_1280.png

• Jeder im Team bekommt 3 Karten, für jede Kategorie eine und gibt Feedback zu den folgenden Fragen:
  
• Gewitter - Was hat mich im letzten Sprint wütend gemacht hat?
• Regen - Was hat mich im letzten Sprint traurig gemacht hat?
• Sonne - Was hat mich im letzten Sprint froh gemacht hat?
  

Eine nächste (Team) Retrospektive steht an und man hat keine Ideen für einen Ablauf? Dann kann ich die Seite https://retromat.org/de/ empfehlen. Hier kann man sich zufällig Ideen für eine Retro generieren lassen.

Zeitmanagement - MoSCoW Priorisierung / Prinzip

In einem meiner ersten Blog Einträge (Nutzen Sie das Parkinsonsche Gesetz) bin ich kurz auf das Pareto-Prinzip (Reduzieren Sie Ihre Aufgaben auf das Wesentliche mit Hilfe der 80-zu-20-Regel) eingegangen. Eine gute Hilfe um seine Aufgaben zu priorisieren, bietet das MoSCoW-Prinzip.

MoSCoW ist ein Akronym und steht für

MUST HAVE

• Nicht verhandelbare Aufgaben, die zwingend erledigt werden müssen und deren Erledigung erfolgskritisch ist.

SHOULD HAVE

• Wichtige Aufgaben, die keine hohe Priorität haben, aber durchaus signifikanten Mehrwert für das Tätigkeitsfeld stiften

COULD HAVE

• Nice-to-have Aufgaben, die nur wenige Mehrwert generieren und daher auch weggelassen werden können ohne Schaden anzurichten.

WON’T HAVE

• Aufgaben, die eindeutig de-priorisiert werden können, da sie keinen Mehrwert stiften und/oder überproportional viel Zeit in Anspruch nehmen
  

Mit Hilfe der richtigen Priorisierung sollte man die Umsetzung der jeweiligen Anforderungen nach ihrer Wichtigkeit und ihrem Potenzial steuern.

Kommunikation - Feedback, 5 Finger Feedback

In agilen Projekten sind "offene Information- und Feedback-Prozesse" sehr wichtig. Auch sollte man in seinen Projektteam immer ehrliche und aufrichtige Anerkennung geben. In diesem Beitrag möchte ich kurz auf Feedback Möglichkeiten eingehen.

Wie kann man Feedback geben und somit auch die "Scrum Werte" berücksichtigen?

1. Feedback Möglichkeit anbieten.
2. Positive Rückmeldung sollte zuerst gegeben werden.
3. Die Rückmeldung muss konkret sein und sollte eine Beschreibung bzw. Beispiel beinhalten.
• Wichtig, jeder ist für sich selbst verantwortlich und spricht nur für sich.
• Nicht: Wir alle sind total verärgert. => Sondern: Ich habe mich geärgert über xyz.
4. Formulierung einer konkreten Bitte bzw. eines Vorschlags, aber KEINER Forderung.
5. Der Dialog dabei ist sehr wichtig (den anderen sehen/erkennen, nicht Recht haben wollen).

 

Eine weitere gute Methode, ist die „Fünf-Finger-Methode“.

Quelle: Landesmedienzentrum Baden-Württemberg, https://www.lmz-bw.de/medien-und-bildung/medienwissen/medienbildung/definitionen-von-medienkompetenz-und-methoden/methoden/feedback-hand/

Kommunikation - Aktives Zuhören und GFK (Gewaltfreie Kommunikation)

In einem meiner ersten Beiträge Kommunikation mit Gesprächspartnern in diesem Blog aus 2013, bin ich auf das 4 Ohren Modell von Friedemann Schulz von Thun (4-Seiten-Modell) eingegangen.

Ich möchte diesen Beitrag kurz aufgreifen und beschreiben, wie aktives Zuhören funktioniert, denn Kommunikation beginnt mit "Zuhören".

Deswegen immer volle Konzentration auf den Gesprächspartner und die folgenden Punkte berücksichtigen:

• Volle Aufmerksamkeit auf den Gesprächspartner bzw. Sprecher.
• Keine Interpretation.
• Kein „Was antworte ich?“.
• Schweigendes Zuhören.
• Paraphrasieren bzw. (einen sprachlichen Ausdruck) mit anderen Wörtern oder Ausdrücken umschreiben.
• Fragen stellen.

Ähnlich funktioniert auch das Grundmodell der GFK (Gewaltfreie Kommunikation) von Marshall B. Rosenberg (Beobachtung, Gefühl, Bedürfnis, Bitte).

Linux - Dateinamen mit Sonderzeichen (Umlaute) umwandeln / umbennen mit Detox

Mit Hilfe von Detox kann man relativ schnell Dateinamen bereinigen bzw. umbennen. Es ersetzt z.B. Leerzeichen durch Standardäquivalente und Dateinamen mit UTF-8- oder Latin-1-Zeichen (ISO 8859-1) werden automatisiert bereinigt.

Installation

sudo apt install detox

oder

git clone https://github.com/dharple/detox.git
cd detox
autoreconf --install (sudo apt install autoconf)
./configure
make (sudo apt install make)

Ausführen

Die wichtigste Option ist -n (--dry-run). Auf diese Weise kann man Detox ausführen, ohne die Dateien zu ändern, also eine Art Vorschaufunktion.

detox -n

detox -v

Ohne die Option, erfolgt dann die Umbennung der Dateien.

Tools - Windows Sysinternals, Microsoft PowerToys

Sysinternals wurde 1996 von Mark Russinovich gegründet, um seine Systemdienstprogramme und technischen Informationen allen Windows Nutzern bereitzustellen. Microsoft stellt unter https://live.sysinternals.com alle System-Utilities von Sysinternals einzeln zum direkten Download bereit.

Die kostenlosen Tools sind nicht gepackt, lassen sich unter Windows durch einbinden als Netzlaufwerk starten:

net use s: http://live.sysinternals.com/tools

Eine genaue Beschreibung der einzelnen Tools findet sich unter https://docs.microsoft.com/de-de/sysinternals/ wie z.B. Autoruns oder Process Explorer.

Weitere nützliche Tools "Microsoft PowerToys", finden sich auch unter https://docs.microsoft.com/de-de/windows/powertoys/ wie z.B. Fancyzones.

Im Microsoft Strore findet sich Windows File Recovery.

Im Download Bereich von Microsoft findet sich Microsoft Garage Mouse without Borders.

Why, How, What - The golden circle von Simon Sinek

Die Anforderungen werden bei Scrum nicht in Use Cases (Anwendungsfälle), sondern in User Stories erfasst. User Stories (Anwendererzählung) beschreiben GUIs, Funktionalitäten und Testszenarien.

Als „Anwender“ will ich „Eigenschaft/Feature“ Damit „Nutzen“.

Einen ähnlichen Ansatz verfolgt auch der "golden circle" von Simon Sinek.

In dem Buch Frag immer erst: warum: Wie Top-Firmen und Führungskräfte zum Erfolg inspirieren  beschreibt Sinek, dass die Menschen von einem Sinn für Ihre Absichten (dem "Warum") inspiriert sind. Daher sollte das WHY (Warum und wofür ist es wichtig?) bei der Anforderungsbeschreibung an erster Stelle stehen, bevor man mit dem "Wie" und "Was" in die Detaillierung geht.

Sinek nennt diese "Triade" den goldenen Kreis, beschrieben in einem Kreis-Diagramm mit

• "Why / Warum" im innersten Kreis, der die Motive oder Zwecke darstellt. Umgeben von einem Ring mit der Bezeichnung
• "How / Wie" hier werden die die Prozesse und Methoden dargestellt (Wie willst du dein Ziel erreichen?). Eingeschlossen mit der Bezeichnung
• "What / Was" welcher die Ergebnisse darstellt (Was machst du um dein Ziel zu erreichen?).

Quelle: Wikipedia (The golden circle diagram, redrawn from Start with Why - Mosborne01)