Konfliktlösungsfähigkeit – Eine Eigenschaft eines Requirements Engineers?

Erstellt am 17 Januar 2017
von Schreibe einen Kommentar

Welche sind die notwendigen Eigenschaften eine Requirements Engineers? Wer IREB CPRE zertifiziert ist, das Buch [1] gelesen oder an einem HOOD Training zur Vorbereitung auf die CPRE Zertifizierung teilgenommen hat, kann diese Frage mit Leichtigkeit beantworten.
Heute möchte ich mit diesem Beitrag anhand der Eigenschaft „Konfliktlösungsfähigkeit“ demonstrieren, wie praxisrelevant diese geforderten Eigenschaften an einen Requirements Engineer sind.

Faszination überwindet Ängste

Erstellt am 11 Januar 2017
von Schreibe einen Kommentar
Glory of Icarus by ReyeD33

Warum sollen wir uns auf eine Änderung einlassen, wenn sowohl Weg als auch Ziel unklar sind und das Risiko entweder nicht abgeschätzt werden kann, oder sogar außergewöhnlich hoch ist?

Die glaubwürdige Beantwortung genau dieser Frage entscheidet über den Erfolg oder Misserfolg eines

Agil und Traditionell sind keine Gegensätze

Erstellt am 20 Dezember 2016
von Schreibe einen Kommentar

Das Cynefin-Modell von Dave Snowden zeigt sehr schön, dass es nicht ausreicht, als einziges Werkzeug einen Hammer zu haben und damit jedes Problem zu einem Nagel zu machen. Er nennt neben einfachen und komplizierten auch komplexe und chaotische Probleme. Und je nach Kontext brauchen wir unterschiedliche Methoden, Technologien und Praktiken, um ein Problem zu lösen.

Zeig doch mal die Metrik!

Erstellt am 13 Dezember 2016
von Schreibe einen Kommentar

Kennen Sie auch folgendes Szenario: Sie sitzen in einem Projektmeeting und der erste Punkt der Agenda steht an: Die aktuellen Metriken. Noch bevor inhaltliche Themen der Entwicklung besprochen werden, wird der aktuelle Status der Metriken als wichtigstes Mittel zur Messung des Projektfortschrittes herangezogen.

„Deep Work“ als agile Praktik

Erstellt am 6 Dezember 2016
von Schreibe einen Kommentar

„Früher haben wir jeden Tag zwei bis drei Stunden in Meetings verquatscht, das war verschwendete Zeit“, sagte ein Entwickler kurz nach dem Beginn meines Engagements in seinem Scrum-Team zu mir. Aber dann: „Und jetzt quatschen wir den ganzen Tag im Team-Raum. Mit dem PO, mit UX- und Security-Experten oder weiteren Stakeholdern, um ‚schnell und direkt‘ Nachfragen zu Stories zu klären. Mit den anderen Entwicklern aus unserem Team, um Architekturen und Lösungskonzepte zu diskutieren. Mit den Kollegen aus anderen Teams, um Schnittstellen abzustimmen. Und jetzt mit dir, unserem Scrum-Master, weil ich davon genervt bin, dass ich nicht zum Coden komme. Vielleicht sollten wir das in der nächsten Retrospektive thematisieren; also schon wieder reden, reden, reden, anstatt zu arbeiten. Und oben drauf kommt noch die Zeit für die Selbstorganisation der Abteilung und die Beteiligung der Mitarbeiter an der Weiterentwicklung der Firmenziele.“

Die abgespeckte Sprint-Retrospektive

Erstellt am 24 November 2016
von Schreibe einen Kommentar

Wenn Sie als Scrum Master arbeiten, dann erleben retro Sie wahrscheinlich auch, dass die Retrospektive nicht zu den heiß geliebten Scrum-Events gehört.  Ich habe aber die Erfahrung gemacht, dass Retrospektiven wirklich etwas bringen, nämlich Reflektion und Kommunikation darüber, was verbessert werden kann.

Ich bin daher ständig auf der Suche nach neuen Formaten, die von den Teams als nützlich empfunden werden. Das strikte Festhalten an 5 aufeinander folgenden Phasen ist meiner Erfahrung nach nicht notwendig, und manchmal sogar kontraproduktiv.

Projekterfolg erleben

Erstellt am 15 November 2016
von Schreibe einen Kommentar

projekterfolg_erfahren

Es gibt nichts motivierenderes als den Erfolg eines Projektes selbst zu erleben. „Die Lorbeeren gemeinsam mit Kollegen zu ernten!“ Mein Kollege Marco Prillwitz und ich konnten dies in einem Kundenprojekt nun miterleben. Hier die Geschichte:

Systems Engineering und Requirements Engineering – Gedanken aus dem Tag des Systems Engineering 2016

Erstellt am 8 November 2016
von Schreibe einen Kommentar

Auch dieses Jahr war ich auf dem Tag des Systems Engineering TdSE 2016. Diesmal in Herzogenaurach, abbildung05wo es wieder viele spannende Themen gab [2]. Als Mitglied der Gesellschaft für Systems Engineering (GfSE) und als Experte für Requirements Engineering bei HOOD verfolge ich mit hohem Interesse die Entwicklung des Systems Engineering (SE) im Bezug zum Requirements Engineering (RE). Mich freut es, dass diese „zwei Gebiete“ immer mehr zusammenwachsen und gemeinsam betrachtet werden.

TdSE 2016 – Trends im Systems Engineering

Erstellt am 2 November 2016
von Schreibe einen Kommentar

Dieses Jahr fand der Tag des Systems Engineerings (TdSE) vom 25. bis zum 27.10.2016  in Herzogenaurach statt. Die gut besuchte Veranstaltung bot den Teilnehmern in Tutorials und Vorträgen viel Abwechslung und neue Informationen rund um das Systems Engineering (SE). Unter vielen Themen kristallisierte sich das Model-Based Systems Engineering (MBSE) als eines der Hauptthemen heraus. In der Zukunft wird der Einsatz von Modellen bei der Entwicklung von komplexen Systemen mit interdisziplinären Teams die durchgängige Basis sein.

Schwarmintelligenz – gemeinsam weiterhelfen

Erstellt am 18 Oktober 2016
von Schreibe einen Kommentar
Habe ich mich angemessen verhalten? Waren meine Handlungen in Ordnung? Haben wir eine passende Entscheidung getroffen? Was nun – wie geht es weiter? Fragen über Fragen. In unserem Beruf, sei es als Scrum Master oder agiler Coach, arbeiten wir in einem komplexen Umfeld. Da tut es gut, einmal sein eigenes Handeln zu reflektieren und ein konkretes Anliegen zu betrachten. Dazu möchte ich in diesem Blog-Beitrag ein Format für eine Gruppen-Supervision vorstellen.

Was genau ist eine Supervision?

In einer Supervision (lateinisch für Über-Blick) werden schwierige oder herausfordernde Situationen eines Supervisanden (Ratsuchende) gemeinsam mit einem Supervisor (eine Person oder Gruppe) reflektiert. Die konkrete Situation wird aus unterschiedlichen Perspektiven betrachtet und es werden mögliche Handlungsvorschläge für das Anliegen erarbeitet.

Was benötige ich?

* einen Supervisand
* eine Gruppe von 3-7 Personen, welche als Supervisoren agieren
* einen Moderator
* mehrere Flipcharts, Stifte
* eine Metaplanwand oder ähnliches – näheres dazu später

Wie gehts?