Kommunikation im Projekt

Nichts ist wichtiger in der Projektabwicklung, als zeitgerecht, respektvoll und verständlich zu kommunizieren. Als Projektleiterin, Projektmitarbeitende oder Projektauftraggeber, für alle gilt:

  • Respekt: einfach etwas nachdenken, bevor man spricht. Reflektieren, welche Konsequenzen  die eigene Kommunikation für andere haben könnte
  • Nutze Fakten, Beispiele und Bilder um die anderen rational und emotional zu erreichen. Lass Unwichtiges weg
  • Offene Fragen stellen – wie, was, wieso – erhöht das Verständnis für andere Sichtweisen und es resultieren mehr Möglichkeiten für das weitere Vorgehen
  • Wer schweigt stimmt nicht immer zu, sondern hat einfache keine Lust mit Idioten zu diskutieren

Gute Fragen:

  1. Was stört mich in der Kommunikation im laufenden Projekt. Warum?
  2. Was ändere ich an meinem Verhalten, um vorbildlich zeitgerecht, respektvoll und verständlich zu kommunizieren?
  3. Wie oft ist meine Zuhörzeit länger als meine Sprechzeit? Wann will ich bewusst auf weniger Sprechzeit und vermehrt Zuhören fokussieren?

Scrum Guide 2020 und was sich geändert hat

Im November 2020 wurde ein aktualisierter Scrum Guide veröffentlicht. Die deutsche Version kann hier heruntergeladen werden. Die wichtigsten Änderungen sind:

Dazu wurden im Scrum Guide 2020 Passagen entfernt oder weiter abgemildert, nämlich

  • die drei Fragen im Daily Scrum;
  • dass sich die Mitglieder des Development Teams häufig noch nach dem Daily Scrum treffen;
  • verpflichtenden Attribute eines Product-Backlog-Eintrags;
  • die 8 Elemente des Sprint Reviews;
  • die detaillierten Gründe, wozu die Sprint Retrospektive durchgeführt wird;
  • Empfehlung, wie viel Kapazität des Development Teams das Refinement üblicherweise beansprucht;
  • wie die Erreichung der Ziele im Product Backlog überwacht werden kann

Die Rolle Development Team wurde zu Developer geändert: Was dadurch das Scrum Team zu einem Team macht, welches aus einem Scrum Master, einem Product Owner und Developern besteht

Das Product Goal wurde eingeführt. Es beschreibt einen zukünftigen Zustand des Produkts. Das Product Goal hält fest, wozu das Scrum Team die Arbeit am Produkt erledigt. Das Product Goal unterstützt ein Scrum Team auf zweierlei Weisen:

  • Es kann als Ziel für das Scrum Team dienen, um dessen zukünftige Arbeit zu planen. Jeder Sprint sollte das Produkt näher zum Product Goal bringen.
  • Es hilft dem Scrum Team, den Fortschritt seiner Arbeit am Product Backlog sichtbar und messbar zu machen

 

Jedes Artefakt enthält ein Commitment und liefert somit Klarheit über den Zweck, Kontext und Wert des Artefakts.

  • Für den Product Backlog ist es das Product Goal.
  • Für den Sprint Backlog ist es das Sprint Goal.
  • Für das Inkrement ist es die Definition of Done.

 

Das Sprint Planning besteht jetzt aus drei Aspekten. Das Scrum Team beantwortet im Sprint Planning

  • welche Product-Backlog-Einträge im Sprint fertig gestellt werden können und
  • wie die ausgewählte Arbeit erledigt werden kann,
  • warum dieser Sprint wertvoll für die Stakeholder ist

Mit den Antworten auf die ersten beiden Punkte wird der Plan für den Sprint erstellt. Die Antwort auf den letzten Punkt wird im Sprint Goal festgehalten. Alles zusammen stellt den Sprint Backlog am Ende des Sprint Plannings dar.

Scrum Teams als Ganzes managen sich selbst. Das Scrum Team entscheidet, wer und wie die Arbeit erledigt werden soll und an was gearbeitet werden soll. Wobei weiterhin erwartet wird, dass die Developer ihre eigene Arbeit managen. Das Scrum Team ist für alle produktbezogenen Aktivitäten verantwortlich, die von der Zusammenarbeit der Stakeholder, über die Überprüfung, Wartung, den Betrieb, das Experimentieren, die Forschung und Entwicklung, bis hin zu allen weiteren erforderlichen Aktivitäten reichen. Diese Veränderung unterstreicht, wie die Ersetzung von Development Team durch Developer, dass ein Scrum Team ein Team ist. Ein Team, welches dafür verantwortlich ist, eigenständig ein wertvolles und nützliches Inkrement zu erstellen.

 

Projekterfolgsfaktoren als Gegenmittel zum Projektmisserfolg

Nicht wirklich neu doch immer wieder wichtig sind diese Projekterfolgsfaktoren, welche besondere Aufmerksamkeit benötigen, um den Projektmisserfolg zu mindern

  • Verbindlichkeiten in Entscheidungen
  • Verlässlichkeit
  • Zusammenarbeit über Hierarchie- und Organisationsgrenzen
  • Transparenz- und Fehlerkultur
  • Rechtzeitige Eskalation

 

Gute Fragen:

  1. Was ist mein Beitrag, dass Entscheidungen verbindlich umgesetzt werden?
  2. Wie interveniere ich, wenn die Verlässlichkeit im Projektteam vernachlässigt wird?
  3. Wie thematisiere ich Fehler und was ist meine Erwartung für deren Behebung und der resultierendem Lerneffekt?