© Excellent backgrounds/Shutterstock.com
Java Magazin
Sage mir, was du entscheidest, und ich sage dir … Über unterschiedliche Arten von Entwicklungsteams

Kolumne: DevOps Stories

Lukas hat eine WhatsApp-Nachricht von seinem Cousin Robert bekommen. Robert arbeitet seit einiger Zeit bei einem IT-Dienstleister und hat sich vor ein paar Monaten mit Lukas auf einer Familienfeier über die Planung agiler Softwareentwicklungsvorhaben unterhalten [1]. In seiner Nachricht hat er Lukas um einen Skype Call gebeten.

Konstantin Diener


Lukas: „Hallo Robert, alles klar bei dir? Du hast geschrieben, dass du noch ein paar Fragen zur Entwicklung in agilen Teams hast und deswegen gerne mit mir sprechen möchtest.“Robert: „Ja, das stimmt. Wir hatten auf Silkes Hochzeit über viele Themen gesprochen, über die ich noch länger nachgedacht habe. Die Tipps, die du mir hinsichtlich der Entwicklungsplanung gegeben hast, waren sehr hilfreich. Einige andere Sachen aus unserem Gespräch bringe ich noch nicht mit der Arbeit in meinem Team zusammen und hätte auch da gerne ein paar Tipps von dir.“Lukas: „Ah, ok, wenn ich dir helfen kann, werde ich es gerne tun.“Robert: „Du hast erzählt, dass Erik, euer Product Owner, dafür zuständig ist, Hypothesen über das Produkt und die Kunden zu erstellen und daraus zum einen passende User Stories abzuleiten. Außerdem priorisiert er diese Stories auch, korrekt?“Lukas: „Ja, das stimmt im Wesentlichen.“Robert: „Bei uns kommt mir der Product Owner immer eher wie ein Projektleiter im neuen Gewand vor, der die Anforderungen oder User Stories von den Stakeholdern bekommt. Die Stakeholder entscheiden auch im Wesentlichen über die Priorisierung der Stories. So setzen wir immer wieder Dinge um, die wir alle – inklusive des Product Owner – für unsinnig halten. Was mich auch oft an die Projektleiterrolle von früher erinnert, ist, dass die Stakeholder die Stories und die Priorisierung vorgeben. Wenn die Software aber nicht den gewünschten Erfolg hat, ist unser Product Owner bzw. wir als ganzes Team dafür verantwortlich.“Lukas: „Wir werden auch dafür verantwortlich gemacht, wenn das Produkt nicht den gewünschten Erfolg bringt, – bzw. Erik, unser Product Owner. Aber bei euch gibt es offenbar viel mehr Einmischung von außen. Es ist zwar lange her, dass ich in einem Projekt mit einem Projektleiter gearbeitet habe, ich sehe aber auch die Parallelen. Vielleicht hat es damit zu tun, dass wir MusicStore auf eigene Rechnung entwickeln und ihr im Wesentlichen im Auftrag von Geschäftskunden arbeitet.“Robert: „Ja, das könnte sein. Daran habe ich auch schon gedacht ...“Abb. 1: Lukas beantwortet die Fragen seines Cousins per SkypeMarty Cagan unterscheidet in einem Blogpost [3] drei Arten von Entwicklungsteams. Eine verbreitete Form sind nach seiner Ansicht sogenannte Delivery Teams. Sie bestehen aus einem Product Owner und einer Reihe von Entwicklern. Das bedeutet, dass sie nicht wirklich cross-funktional und damit im Sinne des Scrum-Guides eigentlich noch nicht einmal richtige Entwicklungsteam...

Java Magazin
Sage mir, was du entscheidest, und ich sage dir … Über unterschiedliche Arten von Entwicklungsteams

Kolumne: DevOps Stories

Lukas hat eine WhatsApp-Nachricht von seinem Cousin Robert bekommen. Robert arbeitet seit einiger Zeit bei einem IT-Dienstleister und hat sich vor ein paar Monaten mit Lukas auf einer Familienfeier über die Planung agiler Softwareentwicklungsvorhaben unterhalten [1]. In seiner Nachricht hat er Lukas um einen Skype Call gebeten.

Konstantin Diener


Lukas: „Hallo Robert, alles klar bei dir? Du hast geschrieben, dass du noch ein paar Fragen zur Entwicklung in agilen Teams hast und deswegen gerne mit mir sprechen möchtest.“Robert: „Ja, das stimmt. Wir hatten auf Silkes Hochzeit über viele Themen gesprochen, über die ich noch länger nachgedacht habe. Die Tipps, die du mir hinsichtlich der Entwicklungsplanung gegeben hast, waren sehr hilfreich. Einige andere Sachen aus unserem Gespräch bringe ich noch nicht mit der Arbeit in meinem Team zusammen und hätte auch da gerne ein paar Tipps von dir.“Lukas: „Ah, ok, wenn ich dir helfen kann, werde ich es gerne tun.“Robert: „Du hast erzählt, dass Erik, euer Product Owner, dafür zuständig ist, Hypothesen über das Produkt und die Kunden zu erstellen und daraus zum einen passende User Stories abzuleiten. Außerdem priorisiert er diese Stories auch, korrekt?“Lukas: „Ja, das stimmt im Wesentlichen.“Robert: „Bei uns kommt mir der Product Owner immer eher wie ein Projektleiter im neuen Gewand vor, der die Anforderungen oder User Stories von den Stakeholdern bekommt. Die Stakeholder entscheiden auch im Wesentlichen über die Priorisierung der Stories. So setzen wir immer wieder Dinge um, die wir alle – inklusive des Product Owner – für unsinnig halten. Was mich auch oft an die Projektleiterrolle von früher erinnert, ist, dass die Stakeholder die Stories und die Priorisierung vorgeben. Wenn die Software aber nicht den gewünschten Erfolg hat, ist unser Product Owner bzw. wir als ganzes Team dafür verantwortlich.“Lukas: „Wir werden auch dafür verantwortlich gemacht, wenn das Produkt nicht den gewünschten Erfolg bringt, – bzw. Erik, unser Product Owner. Aber bei euch gibt es offenbar viel mehr Einmischung von außen. Es ist zwar lange her, dass ich in einem Projekt mit einem Projektleiter gearbeitet habe, ich sehe aber auch die Parallelen. Vielleicht hat es damit zu tun, dass wir MusicStore auf eigene Rechnung entwickeln und ihr im Wesentlichen im Auftrag von Geschäftskunden arbeitet.“Robert: „Ja, das könnte sein. Daran habe ich auch schon gedacht ...“Abb. 1: Lukas beantwortet die Fragen seines Cousins per SkypeMarty Cagan unterscheidet in einem Blogpost [3] drei Arten von Entwicklungsteams. Eine verbreitete Form sind nach seiner Ansicht sogenannte Delivery Teams. Sie bestehen aus einem Product Owner und einer Reihe von Entwicklern. Das bedeutet, dass sie nicht wirklich cross-funktional und damit im Sinne des Scrum-Guides eigentlich noch nicht einmal richtige Entwicklungsteam...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang