„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.“
Systems Engineering und Requirements Engineering – Gedanken aus dem Tag des Systems Engineering 2016
Auch dieses Jahr war ich auf dem Tag des Systems Engineering TdSE 2016. Diesmal in Herzogenaurach, 
wo 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
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
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?
Was bietet uns die Soziokratie als Organisationsstruktur?
Betrachten wir verschiedene neuzeitliche Organisationsstrukturen, dann wurde die Soziokratie in den letzten 50 Jahren von einigen Unternehmen und NGOs eingesetzt. Soziokratie ist von dem lateinischen Socius für ‚Gefährte‘ oder ‚Begleiter‘ und dem altgriechischen kratia für ‚regieren‘, Macht, Stärke abgeleitet[1].
Warum uns „Impediments“ aufhalten
Eines der Zwölf Prinzipien des Agilen Manifest lautet: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.”
Doch wie schaffen wir dies?
Wenn der Sturm sich nicht legt, dann bauen wir eben Windmühlen
Aufblende: Seit einem halben Jahr diskutieren Sie nun ein fachliches Thema mit mehreren Fachabteilungen. Aber der Sturm der Konflikte will einfach nicht aufhören. „Soll ich etwa eine Windmühle bauen?“ denken Sie, schon fast verzweifelt.
Agilität und die Qualität von Anforderungen
Wie gehen wir mit der Qualitätssicherung von Anforderungen im agilen Umfeld um?
In vielen Projekten benutzen wir User Stories und versuchen, die INVEST-Kriterien zu erfüllen. Aber was ist mit den Qualitätskriterien für Anforderungen, wie sie beispielsweise das IREB (International Requirements Engineering Board) vorschlägt? Brauchen wir die noch? Wenn ja, wann und wie kommen sie zum Einsatz?
Vier gewinnt – Die Teamgröße macht‘s
Vielfach wurde bereits über die Gründe geschrieben, dass kleinere Teams produktiver seien. Aber warum ist das so? Gefühlt würde ich sagen: „Na klar, je mehr Beteiligte, desto mehr Informationen und Meinungen sind zu verarbeiten.“ Und genau hierauf möchte ich in diesem Blogbeitrag eingehen: Die Entdeckungen der Gehirnforschung gepaart mit unseren eigenen Erfahrungen aus der Praxis und was wir aus der Korrelation lernen können.
Agile Softwareentwicklung benötigt mehr Werkzeuge
In den 90er Jahren und noch zu Beginn des Jahrtausends haben wir sogenannte CASE-Tools (Computer Aided Software Engineering) verwendet, um zuerst ein Design in Form eines großen, komplett durchdachten UML-Modells zu erstellen, bevor wir anfingen, die Details zu kodieren.