Kommentare zu: Es geht nicht um Software-Entwicklung! http://borisgloger.com/2013/02/06/es-geht-nicht-um-software-entwicklung/ Doing as a way of thinking Thu, 16 May 2013 05:59:00 +0200 hourly 1 http://wordpress.org/?v=3.4.2 Von: Sven Winkler http://borisgloger.com/2013/02/06/es-geht-nicht-um-software-entwicklung/comment-page-1/#comment-55854 Sven Winkler Wed, 20 Feb 2013 14:27:00 +0000 http://borisgloger.com/?p=18953#comment-55854 Jep, du bringst es auf den Punkt :-) Die Ausrichtung ist der Markt, denn dafür wird ja gearbeitet. Wichtig ist hier noch die internen von den externen Märkten zu trennen. Also wann machen wir etwas mit Geschäftswert und Strahlkraft und ab wann entwickeln wir für interne Bedürfnisse, die keinen Geschäftswert erzeugen. Jep, du bringst es auf den Punkt :-)
Die Ausrichtung ist der Markt, denn dafür wird ja gearbeitet. Wichtig ist hier noch die internen von den externen Märkten zu trennen. Also wann machen wir etwas mit Geschäftswert und Strahlkraft und ab wann entwickeln wir für interne Bedürfnisse, die keinen Geschäftswert erzeugen.

]]> Von: Sebastian Radics http://borisgloger.com/2013/02/06/es-geht-nicht-um-software-entwicklung/comment-page-1/#comment-55848 Sebastian Radics Fri, 15 Feb 2013 20:35:00 +0000 http://borisgloger.com/?p=18953#comment-55848 Hi Sven, danke für die super Erklärung! Das schärft für mich zusammen mit dem Video von Boris das Bild. Es ist nicht nur die technische Diversifizierung im Team sondern gerade das Zusammenwachsen von Produktwissen und Technik - mit dem Ziel ein Team zu schaffen, was möglichst weit durch eigene Kraft ein Produkt entwickeln kann (natürlich in enger Abstimmung mit den Markbedürfnissen)? Oder? Hi Sven,
danke für die super Erklärung! Das schärft für mich zusammen mit dem Video von Boris das Bild. Es ist nicht nur die technische Diversifizierung im Team sondern gerade das Zusammenwachsen von Produktwissen und Technik – mit dem Ziel ein Team zu schaffen, was möglichst weit durch eigene Kraft ein Produkt entwickeln kann (natürlich in enger Abstimmung mit den Markbedürfnissen)? Oder?

]]> Von: Sven Winkler http://borisgloger.com/2013/02/06/es-geht-nicht-um-software-entwicklung/comment-page-1/#comment-55847 Sven Winkler Fri, 15 Feb 2013 10:22:00 +0000 http://borisgloger.com/?p=18953#comment-55847 Hi Sebastian, es gibt verschiedene Möglichkeiten Know-How cross-funktional in dein Team hineinzubekommen. Eine Möglichkeit ist, dass aus Service und Betrieb dein Team so lange unterstützen, bis sie autonom ausliefern und installieren können, also befähigen. Das gleiche geht mit Fachexperten, die man anfangs zu Sprint Planning und Review einlädt und mit denen dann über die Zeit immer engere Kontakte entstehen und zu einer besseren Zusammenarbeit führen, was übrigens Ziel einer Organisation ist. Es geht allerdings auch anders. Ein Kunde von uns hatte, beim nachsinnen über die Vergangenheit, fallen lassen: "damals saßen die Leute aus den Fachbereichen noch direkt neben uns und haben uns die Funktion direkt in die Finger diktiert" - und das meinte er im positiven Sinne: Teamarbeit und direkter Austausch - von Angesicht zu Angesicht und ohne Dokumente, Verträge dazwischen. So wachsen auch gute Produktentwickler heran. Immer nah an der Domän. Zum Start Entwickler, die Produkt-Know-How haben, später dann (und das ist mein Ziel) Produktentwickler, die Entwicklungs-Know-How haben. Das letztere rockt mehr :-) und genau das kriegt man hin, wenn verschiedene Disziplinen zusammenarbeiten. Heutzutage nennt man das Teams, aufgestellt und getrennt durch disziplinarische Gerüste. Viele Grüße, Sven :-) Hi Sebastian,

es gibt verschiedene Möglichkeiten Know-How cross-funktional in dein Team hineinzubekommen. Eine Möglichkeit ist, dass aus Service und Betrieb dein Team so lange unterstützen, bis sie autonom ausliefern und installieren können, also befähigen.
Das gleiche geht mit Fachexperten, die man anfangs zu Sprint Planning und Review einlädt und mit denen dann über die Zeit immer engere Kontakte entstehen und zu einer besseren Zusammenarbeit führen, was übrigens Ziel einer Organisation ist.

Es geht allerdings auch anders. Ein Kunde von uns hatte, beim nachsinnen über die Vergangenheit, fallen lassen: “damals saßen die Leute aus den Fachbereichen noch direkt neben uns und haben uns die Funktion direkt in die Finger diktiert” – und das meinte er im positiven Sinne: Teamarbeit und direkter Austausch – von Angesicht zu Angesicht und ohne Dokumente, Verträge dazwischen. So wachsen auch gute Produktentwickler heran. Immer nah an der Domän. Zum Start Entwickler, die Produkt-Know-How haben, später dann (und das ist mein Ziel) Produktentwickler, die Entwicklungs-Know-How haben. Das letztere rockt mehr :-) und genau das kriegt man hin, wenn verschiedene Disziplinen zusammenarbeiten. Heutzutage nennt man das Teams, aufgestellt und getrennt durch disziplinarische Gerüste.

Viele Grüße, Sven :-)

]]> Von: Sebastian Radics http://borisgloger.com/2013/02/06/es-geht-nicht-um-software-entwicklung/comment-page-1/#comment-55836 Sebastian Radics Sat, 09 Feb 2013 08:48:00 +0000 http://borisgloger.com/?p=18953#comment-55836 Hi Boris, danke für das geniale Video - das hat es echt klasse gezeigt, was cross-funktionale Teams bedeutet und bewirkt. New Product Development Game - lese ich gerade. Sebastian Hi Boris,
danke für das geniale Video – das hat es echt klasse gezeigt, was cross-funktionale Teams bedeutet und bewirkt. New Product Development Game – lese ich gerade.

Sebastian

]]> Von: Boris Gloger http://borisgloger.com/2013/02/06/es-geht-nicht-um-software-entwicklung/comment-page-1/#comment-55834 Boris Gloger Sat, 09 Feb 2013 07:27:00 +0000 http://borisgloger.com/?p=18953#comment-55834 Hi Sebastian, kennst du das Video von ABC über die Arbeit von IDEO - findest du hier:http://www.youtube.com/watch?v=M66ZU2PCIcM. Es ging in Scrum immer darum ALLE Beteiligten der Product-Entwicklung zusammen zu würfeln. Vielleicht liesst du dazu auch nochmal den Artikel - The New New Product Development Game von Nonaka. Wichtig - klar sind das dann keine 5 Personen Teams mehr, sondern ganze Bereiche von bis zu 200 Personen. Aber die Prinzipien gelten dann auch. Für eine erste Annäherung kann das bedeuten, dass man die Fachbereiche und die Spezialisten tageweise dazu holt, oder man beteiligt sie intensiv beim Sprint Planning. Stell dir doch einfach einen kleinen Start Up von ca 25 Personen vor. Da sollte doch auch alles aufeinander eingespielt sein. So ähnlich ist auch ein wirkliches Product Development Scrum-Team. Viel Spass beim Lesen und schauen des Videos. -- Boris Hi Sebastian,

kennst du das Video von ABC über die Arbeit von IDEO – findest du hier:http://www.youtube.com/watch?v=M66ZU2PCIcM.

Es ging in Scrum immer darum ALLE Beteiligten der Product-Entwicklung zusammen zu würfeln. Vielleicht liesst du dazu auch nochmal den Artikel – The New New Product Development Game von Nonaka. Wichtig – klar sind das dann keine 5 Personen Teams mehr, sondern ganze Bereiche von bis zu 200 Personen. Aber die Prinzipien gelten dann auch.

Für eine erste Annäherung kann das bedeuten, dass man die Fachbereiche und die Spezialisten tageweise dazu holt, oder man beteiligt sie intensiv beim Sprint Planning.

Stell dir doch einfach einen kleinen Start Up von ca 25 Personen vor. Da sollte doch auch alles aufeinander eingespielt sein. So ähnlich ist auch ein wirkliches Product Development Scrum-Team.

Viel Spass beim Lesen und schauen des Videos. — Boris

]]> Von: Sebastian Radics http://borisgloger.com/2013/02/06/es-geht-nicht-um-software-entwicklung/comment-page-1/#comment-55831 Sebastian Radics Fri, 08 Feb 2013 02:41:00 +0000 http://borisgloger.com/?p=18953#comment-55831 Danke für die Antwort. Mit ging es dabei nicht um die Auslastung des Mitarbeiters, sondern um die Integration im Team. Bzgl. der Integration mit Ops, da stimme ich Dir zu. Wenn es um Fachexperten geht, dann kann ich mir das im Team aus Teamentwicklungssicht im Moment schlecht vorstellen, da aus meiner Sicht der Beitrag dann doch eher punktuell ist. Wie kann dann konkret die Integration aussehen (Durchlaufen der Teamphasen und gemeinsames Wachsen in Richtung High-Performance-Team)? Siehst Du dann den Fachexperten für ein paar Tage im Sprint zusammen vor Ort mit dem Team und dann arbeitet er wieder in der Fachabteilung (und wandert damit zwischen den Welten?) Werden die Teams dann für jedes neu kommende Thema neu zusammengestellt? Kannst Du evtl. ein Beispiel für eine Teamzusammenstellung geben? Danke für die Antwort. Mit ging es dabei nicht um die Auslastung des Mitarbeiters, sondern um die Integration im Team.

Bzgl. der Integration mit Ops, da stimme ich Dir zu.

Wenn es um Fachexperten geht, dann kann ich mir das im Team aus Teamentwicklungssicht im Moment schlecht vorstellen, da aus meiner Sicht der Beitrag dann doch eher punktuell ist. Wie kann dann konkret die Integration aussehen (Durchlaufen der Teamphasen und gemeinsames Wachsen in Richtung High-Performance-Team)? Siehst Du dann den Fachexperten für ein paar Tage im Sprint zusammen vor Ort mit dem Team und dann arbeitet er wieder in der Fachabteilung (und wandert damit zwischen den Welten?)

Werden die Teams dann für jedes neu kommende Thema neu zusammengestellt?

Kannst Du evtl. ein Beispiel für eine Teamzusammenstellung geben?

]]> Von: Marc Bless http://borisgloger.com/2013/02/06/es-geht-nicht-um-software-entwicklung/comment-page-1/#comment-55830 Marc Bless Thu, 07 Feb 2013 23:14:00 +0000 http://borisgloger.com/?p=18953#comment-55830 Um die Wertschöpfungskette so weit wie möglich zu agilisieren, stoßen Organisationen oft schon an ihre Grenzen, wenn es darum geht, alle technischen Bereiche einzubeziehen. Das typische Beispiel ist der Betrieb, der sich erst nach der Entwicklung darum kümmern kann, das Produkt auch tatsächlich produktiv zu schalten. Noch weiter weg sind im Regelfall Fachexperten wie z.B. Übersetzer, Redakteure oder Marketing-Profis, die sich bereits während des Sprints im Team darum kümmern können, dass pünktlich beim Live-Deployment am Sprint-Ende auch die Social Media Marketingmaßnahmen starten. Die Frage nach dem Beitrag über den kompletten Sprint hinweg entspricht letztlich der Frage nach der Auslastung eines Mitarbeiters. Und diese ist zweitrangig im Vergleich zu dem Ziel, am Sprint-Ende ein fertiges Produkt zu liefern. Findet ein Teammitglied während des Sprints tatsächlich nicht genügend Arbeit im Team und langweilt sich, kann es möglicherweise auch in weiteren Teams "Teilzeitmitglied" sein. Noch einmal explizit: unser Ziel ist niemals, jeden Mitarbeiter immer auszulasten! Aber das ist vielleicht ein Thema für einen weiteren Blog-Beitrag. Um die Wertschöpfungskette so weit wie möglich zu agilisieren, stoßen Organisationen oft schon an ihre Grenzen, wenn es darum geht, alle technischen Bereiche einzubeziehen. Das typische Beispiel ist der Betrieb, der sich erst nach der Entwicklung darum kümmern kann, das Produkt auch tatsächlich produktiv zu schalten.

Noch weiter weg sind im Regelfall Fachexperten wie z.B. Übersetzer, Redakteure oder Marketing-Profis, die sich bereits während des Sprints im Team darum kümmern können, dass pünktlich beim Live-Deployment am Sprint-Ende auch die Social Media Marketingmaßnahmen starten.

Die Frage nach dem Beitrag über den kompletten Sprint hinweg entspricht letztlich der Frage nach der Auslastung eines Mitarbeiters. Und diese ist zweitrangig im Vergleich zu dem Ziel, am Sprint-Ende ein fertiges Produkt zu liefern. Findet ein Teammitglied während des Sprints tatsächlich nicht genügend Arbeit im Team und langweilt sich, kann es möglicherweise auch in weiteren Teams “Teilzeitmitglied” sein.

Noch einmal explizit: unser Ziel ist niemals, jeden Mitarbeiter immer auszulasten! Aber das ist vielleicht ein Thema für einen weiteren Blog-Beitrag.

]]> Von: Sebastian Radics http://borisgloger.com/2013/02/06/es-geht-nicht-um-software-entwicklung/comment-page-1/#comment-55828 Sebastian Radics Thu, 07 Feb 2013 05:31:00 +0000 http://borisgloger.com/?p=18953#comment-55828 Interessanter Post, danke dafür! Wie sieht denn dann so ein cross funktional besetztes Team genau aus? Ich hatte das bisher immer cross funktional im Sinne der Technik verstanden - z.B. im Java-Umfeld also ein Teammitglied, dass sich mit Tests auskennt, Java Entwickler mit unterschiedlichen Schwerpunkten, Architekt. Im Artikel klingt es so, als würden im Team auch Fachexperten mit dabei sein? Dabei würde es mich dann interessieren, wie ein Sprint-Tag dann aussieht - denn ich kann mir den Beitrag über den kompletten Sprint hinweg so nicht vorstellen. Interessanter Post, danke dafür!
Wie sieht denn dann so ein cross funktional besetztes Team genau aus? Ich hatte das bisher immer cross funktional im Sinne der Technik verstanden – z.B. im Java-Umfeld also ein Teammitglied, dass sich mit Tests auskennt, Java Entwickler mit unterschiedlichen Schwerpunkten, Architekt. Im Artikel klingt es so, als würden im Team auch Fachexperten mit dabei sein? Dabei würde es mich dann interessieren, wie ein Sprint-Tag dann aussieht – denn ich kann mir den Beitrag über den kompletten Sprint hinweg so nicht vorstellen.

]]>