Komm mir nicht mit Fachlichkeit – Ina Einemann 

 17. April 2024

Sie sehen gerade einen Platzhalterinhalt von Podigee. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen

“Die Entwickler haben genug zu tun, ich möchte jetzt nicht, dass die jetzt auch noch Interviews den ganzen Tag führen. Aber dass sie mitlernen was der Kunde überhaupt möchte. Also dass sie Teil des (…) interdisziplinären Teams sind” – Ina Einemann

Fachlichkeit, dieser Begriff zieht zunächst einmal Grenzen. Hier ist Inas Meinung nach auch der Widerspruch bei Scrum: er spricht einerseits von der Zusammenarbeit aller Teams, legt andererseits den Fokus jedoch stark auf das auslieferungsreife Produkt – so werden dann beispielsweise Features entwickelt, die der Endanwender gar nicht nutzt. Wenn der Endanwender aber kontinuierlich mit einbezogen wird und gleichzeitig die Entwickler stärker in die Planung einbezogen werden, dann entsteht ein umfassendes Bild dessen, was der Endanwender braucht um sein Problem zu lösen. Und solcherlei Innovationen kommen oft aus dem technischen Bereich, nämlich den Entwicklern, die beim Problemverständnis dann direkt Ideen zu Features haben, die das Problem lösen.

Ina Einemann ist als Agile Coach bei der open knowledge GmbH in Oldenburg tätig. ‍Sie arbeitet als agiler Coach mit dem Schwerpunkt Anforderungsmanagement und Product Ownership. Seit zehn Jahren beschäftigt sie sich mit agilen Methoden und Vorgehensmodellen und berät Teams bei der Umsetzung agiler Praktiken mit dem Ziel Teams zu motivieren tolle Produkte umzusetzen. ‍Sie spricht regelmäßig auf agilen Veranstaltungen, ist Kuratorin diverser Konferenzen und einer der Hosts des agilen Podcasts „Mein Scrum ist kaputt”. 2022 veröffentlicht sie mit Frank Düsterbeck das Buch „Product Ownership meistern. Produkte erfolgreich entwickeln”.

Highlights in dieser Episode:

  • Ina Einemann spricht über gute Anforderungen und Methoden in der Softwareentwicklung
  • Ina erklärt, warum Scrum nicht das Allheilmittel ist und was es beim Erheben von Anforderungen zu beachten gibt
  • Es wird betont, wie wichtig es ist, den Endanwender zu verstehen und in den Entwicklungsprozess einzubeziehen
  • Ina teilt ihre Erfahrungen mit Workshops wie Eventstorming und Storymapping, um ein gemeinsames Verständnis zu schaffen
  • Es wird diskutiert, wie wichtig es ist, regelmäßig Feedback vom Endanwender zu erhalten und dieses in den Entwicklungsprozess zu integrieren
  • Ina betont die Bedeutung von gemischten Teams und wie sie helfen können, ein Produkt zu entwickeln, das tatsächlich genutzt wird
  • Ina wünscht sich, noch mehr Fokus auf den direkten Kontakt mit dem Endanwender zu legen, um neue Ideen und Energie ins Team zu bringen

 

Kontakt zu Ina:

Weitere Links:

 

Agile Prozesse neu definiert: Fachlichkeit, Event Storming & Story Mapping

TLDR: Heute sprach ich mit Ina Einemann über die Herausforderungen und Chancen im Umgang mit Fachlichkeit in agilen Prozessen, insbesondere im Kontext von Scrum. Wir erkundeten innovative Methoden wie Event Storming und Story Mapping, um tiefer in die Anforderungen der Kunden einzutauchen und den wahren Nutzen hinter den Anforderungen zu identifizieren.

Die Grenzen von Scrum

Ina beleuchtet ein kritisch betrachtetes Thema: Die Grenzen von Scrum, insbesondere wenn es darum geht, das richtige Produkt zu entwickeln. Scrum konzentriert sich stark auf Delivery, während der wichtige Discovery-Bereich oft vernachlässigt wird. Es entsteht die Frage: Wie kommen eigentlich die richtigen Anforderungen ins Backlog? Ina argumentiert, dass Scrum von einem fertigen Backlog ausgeht und den Weg dahin – also wie Anforderungen entstehen und priorisiert werden – weitgehend ignoriert.

Event Storming und Story Mapping als Schlüssel

Um diese Lücke zu schließen, sprachen wir über innovative Ansätze wie Event Storming und Story Mapping. Diese Methoden ermöglichen es Teams, auf interaktive Weise ein tiefgreifendes Verständnis für die Bedürfnisse ihrer Kunden zu entwickeln. Durch das gemeinsame Arbeiten an einer physischen Map können alle Beteiligten – von Usern über Product Ownern bis hin zu Entwicklern – ein gemeinsames Verständnis für das Projekt entwickeln. Diese Ansätze fördern nicht nur die Zusammenarbeit im Team, sondern helfen auch dabei, Prioritäten klarer zu setzen und sicherzustellen, dass das Endprodukt wirklich den Bedürfnissen des Kunden entspricht.

Feedback als wesentlicher Bestandteil

Es reicht nicht aus, einfach nur ein Produkt basierend auf den im Backlog definierten Anforderungen zu entwickeln; vielmehr ist es entscheidend, kontinuierlich Feedback von den Endnutzern einzuholen. Dies kann durch regelmäßige Reviews geschehen oder indem man direkt beim Endanwender vor Ort beobachtet, wie das Produkt tatsächlich genutzt wird. Solche Einblicke sind unerlässlich für die kontinuierliche Verbesserung des Produkts und stellen sicher, dass es tatsächlich einen Mehrwert für den Nutzer bietet.

Die Rolle der Technologie bei der Innovation

Technologische Innovation spielt eine entscheidende Rolle bei der Adressierung von Kundenbedürfnissen. In unserer Diskussion betonten wir die Wichtigkeit des technischen Inputs innerhalb des Teams. Entwickler und technische Experten tragen maßgeblich dazu bei, Lösungen für identifizierte Probleme oder Bedürfnisse zu finden. Durch ihre Expertise können sie Möglichkeiten aufzeigen, wie die Produktentwicklung optimiert werden kann. Das macht die Notwendigkeit eines interdisziplinären Teams deutlich, in dem jeder seine Stärken einbringt und gemeinsam an der bestmöglichen Lösung arbeitet.

Der Weg nach vorn

Agile-Methoden können durch die Integration innovativer Ansätze zur Anforderungserhebung verbessert werden. Einem tiefes Verständnis des Kundennutzens sollte immer im Zentrum dieser Bemühungen stehen. Indem Teams eng zusammenarbeiten und kontinuierlich Feedback einholen, können sie sicherstellen, dass sie Produkte entwickeln, die wirklich einen Unterschied machen.