Wer bin ich – und wenn ja, wieviele? Requirements Engineers in der Sinnkrise…

Erstellt am 9 September 2014
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Casting für Product Owner

Und es trifft nicht nur die Requirements Engineers (REs), es trifft auch die Business Analysten (BAs), wie ich im Gespräch mit einer Teilnehmerin am Scrum Day erfuhr: „Unsere Entwicklung arbeitet jetzt mit Scrum – und ich weiß gar nicht mehr, was meine Aufgabe ist…“. Dabei ist das Arbeiten als RE/BA in einem Scrum Team herrlich. So vielfältige Aufgaben und Möglichkeiten, sich und sein Wissen einzubringen, habe ich bisher nur beim Arbeiten in einem agilen Team gehabt. Der Transfer der agilen Werte und Prinzipien auf das Requirements Engineering und die Rolle Requirements Engineer in einem agilen Umfeld ist eine Herausforderung für viele Menschen und Organisationen. Die heutigen Zertifizierungen am Markt zu Scrum/Agile und Requirements Engineering haben eines gemeinsam: Sie konzentrieren sich entweder auf das Thema Agilität/Scrum oder auf das Thema Requirements Engineering. Auch “Agile Extensions”, wie sie der BABoK oder das PMI veröffentlicht haben, ergänzen nur die agile Sichtweise, sie bieten keine übergreifende integrierte Sicht. Meine Erfahrung in der Arbeit mit agilen Teams und Organisationen auf dem Weg zu mehr Agilität zeigt jedoch, dass gerade die Verbindung beider Themen in der Praxis Schwierigkeiten macht. Die Transferleistung gelingt nicht oder nur schwer.

Die Qual der Wahl – das Konferenzprogramm der Manage Agile 2014 steht fest

Erstellt am 29 Juli 2014
von Schreibe einen Kommentar

manageagile_2014_quadrat_500pxWir Frauen sind es ja eigentlich gewöhnt aus einem überreichen Angebot auswählen zu müssen. Das geht morgens schon los mit der Frage „Was soll ich anziehen“, setzt sich in der Mittagspause fort mit der Entscheidung ob „Salat, Gemüse, oder doch das Schnitzel“ und (ja, ich bediene jetzt wirklich jedes Klischee) endet mit Verlustgefühlen oder Gewissensbissen nach dem Besuch im Schuhladen (je nach Anzahl der erworbenen Paar Schuhe). Und nein, Sie sind nicht aus Versehen auf dem Blog einer Frauenzeitschrift gelandet – gleich geht’s weiter mit agil.

Xtreme Simplicity – mach’s doch mit der Hand!

Erstellt am 6 Mai 2014
von Schreibe einen Kommentar

Kürzlich nahm ich an einer Story Time eines Scrum Teams teil. Das Ziel war, Klarheit in einige User Stories zu bringen, um diese dann schätzen zu können. Als die Zeit für die Schätzung gekommen war, sehe ich mich um: Keine Planning Poker Karten, keine Handys (mit Poker-App) am Tisch, nichts… Wie will das Team schätzen? Ich stelle mich also auf eine langwierige Schätzsession mit vielen Diskussionen ein. Ich plane im Geiste schon meine anschließende Intervention, um das Thema relative Schätzung zu motivieren. Plötzlich geht alles ganz schnell. Auf ein Zeichen des Scrum Masters heben alle Teammitglieder eine Hand, die Schätzzahl wird notiert und es geht weiter. Was war passiert? Und wieder einmal habe ich etwas gelernt: es geht immer noch einfacher!

Die ALM Days 2014 – zwei Tage mit dem „Who is Who“ im ALM

Erstellt am 4 März 2014
von Schreibe einen Kommentar

Ein erstes Highlight dieses Jahr waren zwei Tage „ALM Days“ in Düsseldorf. Hochkarätiger Sprecher, interessante Vorträge und ein höchst professionelles Ambiente, ließen keine Wünsche offen.

Besonders gefallen hat mir die Keynote „Engineering for a cloud cadence“ von Brian Harry, General Manager Team Foundation Server von Microsoft.

Experimente

Erstellt am 4 Februar 2014
von Schreibe einen Kommentar
This entry is part 3 of 5 in the series Ein Weg zur agilen Organisation

Die Bereitschaft zu experimentieren

Die grundlegende Voraussetzung, um in einer Organisation erfolgreich agil entwickeln zu können, sehe ich in der Bereitschaft der Stakeholder, zusammen zu experimentieren.
Mit experimentieren meine ich:

  • Hypothesen aufstellen,
  • in kontrolliertem Rahmen etwas ausprobieren,
  • Hypothesen überprüfen,
  • aus dem Ergebnis Schlüsse ziehen.

Übertragen auf die Produktentwicklung heißt dies unter anderem, folgende Hypothesen zu überprüfen und daraus während der laufenden Entwicklung Schlüsse zu ziehen:

Der Business Analyst – als Scout im agil skalierten Umfeld

Erstellt am 13 Januar 2014
von Schreibe einen Kommentar

„Was wird aus unseren Business Analysten?“ – Diese Frage ist häufig zu hören – vor allem in größeren Organisationen – wenn die agile Transition beginnt.

Auf diese Frage fallen mir vier Antworten ein:

HOOD konzentriert seine agilen Aktivitäten in der neuen Marke “Agile-by-HOOD”

Erstellt am 23 Oktober 2013
von Schreibe einen Kommentar

Agile-by-HOOD LogoMünchen, 22. Okt 2013: Die HOOD GmbH geht heute mit ihrem Angebot Agile-by-HOOD an den Markt.

Erster Auftritt von Agile-by-HOOD ist auf der vielbeachteten Konferenz „Manage Agile“ in Berlin.

Seit mehr als 25 Jahren berät und unterstützt HOOD erfolgreich seine Kunden bei der Entwicklung komplexer Software und Systeme durch Requirements Engineering-Prinzipien.

Mit der Marke Agile-by-HOOD bündelt HOOD das Angebot im agilen Umfeld und macht somit einen weiteren konsequenten Schritt zur zielgerichteten Unterstützung von Organisationen, die entweder bereits agil arbeiten oder sich vorgenommen haben, in Zukunft ihre Entwicklung auf Scrum, Kanban oder ähnliche Vorgehensweisen umzustellen.

HOOD kann dabei auf langjährige Erfahrungen im Agile Coaching und fundierte Expertise im Requirements Engineering zurückgreifen, um große Unternehmen beim Umstieg von klassischer auf agile Vorgehensweise zu begleiten. Das Thema agil-skaliert ist uns ein besonderes Anliegen – wir verstehen auch die Entwicklung komplexer Produkte und Systeme mit vielen Teams und großen Organisationen.

Weitere Infos unter: http://www.Agile-by-HOOD.com

Story Splitting Revisited

Erstellt am 23 Juli 2013
von Schreibe einen Kommentar

Vor kurzem habe ich an dieser Stelle das Story Splitting Flowchart von Richard Lawrence vorgestellt, eine gute, praktische Hilfe zum Schneiden von Use Stories.

Heute möchte ich die darin enthaltenen Pattern um zwei weitere ergänzen, die sich schon in mehreren Projekten als sehr hilfreich erwiesen haben.

Requirements Engineering (RE) findet in Scrum kontinuierlich statt – wir nennen es nur nicht so

Erstellt am 16 Juli 2013
von Schreibe einen Kommentar

„Wir arbeiten agil und benötigen kein RE mehr“. Diese Aussage hört man immer häufiger in unterschiedlichen Organisationen. Ist die Zeit des Requirements Engineerings (RE) durch die Verbreitung von der agilen Methoden (z.B. durch das Scrum-Framework) damit abgelaufen und werden nicht mehr benötigt?

Warum ist es so schwer, ein Scrum-Team zu bilden?

Erstellt am 25 Juni 2013
von 2 Kommentare

Eine typische Organisationsform für System- und Softwareentwicklung sind Komponenten-Teams. Entwickler werden um Komponenten herum gruppiert, es gibt ein Team für Komponente X und eines für Komponente Y; dann gibt es auch oft Spezialteams wie ein GUI-Team oder ein Test-Team.

Eine andere weitverbreitete Organisationsform ist die Einteilung in Silos, Pools oder Services entlang der Disziplinen, also ein Requirements-Service, ein Design-Service, ein Test-Service (das eignet sich für Outsourcing angeblich sehr gut) und die Mitarbeiter dieser Services werden dann Projekten gemäß ihrer „Spezialisierung“ zugeordnet. Jeder Mitarbeiter arbeitet gewöhnlich in mehreren Projekten gleichzeitig.