Vollste Zustimmung. Meine Erfahrung hat gezeigt, dass eine gute Fehlerkultur im Team plus eine Begegnung auf Augenhöhe schon im engsten Team eine tolle Zusammenarbeit ermöglichen. Agile Methoden sollte man kennen und das ein oder andere Mal probieren. Der beste Tipp von mir: Nutzt nicht den Begriff Scrum, das holt nur Klugscheißer auf den Plan die an dem Projekt rum mäkeln und die Form über das eigentliche Projekt stellen. Eine eigene Methode in eigenem Namen (z.B. AWOA - Agile Way of Us) macht erstmal neugierig und bringt gutes Projektmarketing, was auch sehr wichtig ist. Klasse Video. Gerne mehr :-)
[gr] Vielen Dank für das Lob - und natürlich auch für den Kommentar an sich. Du hast einen sehr guten Punkt genannt: Wenn man von "Scrum" spricht, haben direkt alle ein bestimmtes Bild vor Augen, und es geht mehr um das Lehrbuch als um den persönlichen Bedarf. Tatsächlich haben wir vor vielen, vielen Jahren so etwas wie AWOA (gelungener Name 😉) für uns gebaut, namens ADF - das "Agile Development Framework". Das war, um es an andere weiterzugeben, zu komplex - aber für uns hat es den enormen Nutzen gehabt, dass wir uns sehr explizit und sehr intensiv mit unserem eigenen Prozess befasst haben, den wir bis dahin gar nicht so ausformuliert hatten, aber dadurch kam das dann - und das hat geholfen, einfach, weil man über vieles noch einmal gründlich nachdenken musste. Wenn Du sagst "gerne mehr" - meinst Du damit, speziell zu Themen wie agilen Methoden, oder allgemein?
@@thenativeweb Wir sind scheinbar auf einem Nenner mit dem Verständnis (ob Philosophie oder einzige Wahrheit sei jetzt mal dahin gestellt). Teils wurde ich in euren Videos bestätigt, teils ergänzt. Daher sowohl native Softwareentwicklung als auch agile Projektmanagement sind gern gesehen Themen. Da ich in anderen Sprachen beheimatet bin, tendiere ich mehr in die allgemeinen Programmierskills und eben Agiles :-)
Sehr informatives Video :) Für mich ergeben sich noch zwei Fragen: Wie geht man am besten vor wenn ein Team an mehreren Projekten arbeitet? Für mich ist es noch etwas schwierig zu verstehen (wahrscheinlich da ich bisher auch noch nicht in einem agilen Team gearbeitet habe) wie man den agilen Ansatz und ein gut konzeptioniertes Produkt unter einen Hut bekommt. Ich verstehe Scrum so, dass für sich stehende User Stories ohne Abhängigkeiten geschrieben und in Sprints umgesetzt werden. Aber wie lässt sich so eine gute Grundlage mit wiederverwertbarem und gut strukturiertem Code schaffen?
[gr] Danke für Dein Feedback, das freut mich 😊 Zu Deinen Fragen … wenn ein Team an mehreren Projekten arbeitet, ist Scrum IMHO schon nicht mehr so übermäßig gut geeignet, weil Du dann konkurrierende POs und Anforderungen hast, und da geht es dann schon los mit so Fragen, wie was wann warum priorisiert wird … klar funktioniert es irgendwie, aber doch eher nur "irgendwie". Was die zweite Frage angeht: Aufräumarbeiten, Refactoring & Co. müssen mit eingeplant werden, das heißt, jede Story ist nicht nur das neue Feature, sondern bedeutet auch, nach dem Umsetzen des Features stets auch die Zeit haben, aufzuräumen, sauber zu machen, … also es geht schon, erfordert aber viel Disziplin (aber das gilt bei Clean Code vermutlich ohnehin immer).
[gr] Danke für Deinen Kommentar 😊 Ich orientiere mich, was XP angeht, hauptsächlich an extremeprogramming [dot] org, was eine sehr ursprüngliche Darstellung von XP ist. Natürlich hat sich XP in den vergangenen 20 Jahren auch weiterentwickelt und wurde auf verschiedene Arten ergänzt. Schaut man sich die ursprünglichen Regeln an, fällt auf, dass es da einige wenige gibt, die man durchaus als organisatorischen Rahmen bezeichnen kann - im Gesamtkontext sind das aber nur sehr wenige, und sie sind verhältnismäßig unspezifisch. Auch im Vergleich zu Scrum und Kanban fällt auf, dass der Schwerpunkt von XP ein ganz anderer ist. Insofern: Ja, XP enthält gewisse organisatorische Elemente, aber sie stehen weder im Vordergrund, noch sind sie allzu konkrete Handlungsanweisungen. Was den Eintrag bei Wikipedia angeht, kenne ich den, allerdings ist mir nicht klar, wann der von wem wie ergänzt wurde, und auf welcher Basis dort beispielsweise ganz konkrete verschiedene Rollen genannt werden. Bei XP gibt es natürlich auch Rollen, wie das Team oder den Kunden, aber bei weitem nicht so konkret und spezifisch wie das bei Wikipedia dargestellt wird. Letztlich kommt es am Ende des Tages ja aber ohnehin darauf an, dass man - so wie ich das auch im Video beschreibe - die für sich passten Elemente herausfindet und kombiniert. Eine einzige agile Methode wird häufig nicht ausreichen, einfach weil Software Entwicklung in sehr komplexer Prozess ist. Das heißt, dass man zum Beispiel natürlich Rollen brauchen wird, aber da muss man abgesehen von einigen wenigen Standardrollen dann ohnehin schauen, was jeweils passt.
Sehr cooles Video. Ich kann in dem Zusammenhang auch einen Vortrag von Allen Holub empfehlen, The death of Agile. Seine Thesen sind sehr polarisierend aber scheinen plausibel. Er meint, wie kann Scrum Agil sein wenn man dabei einen strikten Prozess folgen muss: ua-cam.com/video/vSnCeJEka_s/v-deo.html
Man hört deutlich deine negativen Erfahrungen mit Scrum durch. Schade, dass du das nicht positiver siehst. Ich habe auch viel negatives im Zusammenhang mit Scrum erlebt. Das lag aber in der Regel nicht an Scrum. Die positiven Erfahrungen überwiegen bei mir.
[gr] Ja, ich habe sehr viele negative Erfahrungen mit der Umsetzung von Scrum (nicht Scrum an sich!) erlebt. Es gab auch Teams, wo das hervorragend geklappt hat. Allerdings ist es dann in aller Regel genau so gewesen, wie im Video beschrieben, dass hier die Voraussetzungen ideal waren - da, wo das nicht gegeben war, funktioniert Scrum auch nicht. Das ist kein Makel von Scrum, sondern eher ein falscher oder unpassender Einsatz von Scrum. Das kann man dann nicht Scrum vorwerfen, aber es wird eben einfach zu oft eingesetzt, ohne die passenden Bedingungen zu schaffen, dass es funktionieren kann.
Vollste Zustimmung. Meine Erfahrung hat gezeigt, dass eine gute Fehlerkultur im Team plus eine Begegnung auf Augenhöhe schon im engsten Team eine tolle Zusammenarbeit ermöglichen. Agile Methoden sollte man kennen und das ein oder andere Mal probieren. Der beste Tipp von mir: Nutzt nicht den Begriff Scrum, das holt nur Klugscheißer auf den Plan die an dem Projekt rum mäkeln und die Form über das eigentliche Projekt stellen. Eine eigene Methode in eigenem Namen (z.B. AWOA - Agile Way of Us) macht erstmal neugierig und bringt gutes Projektmarketing, was auch sehr wichtig ist.
Klasse Video. Gerne mehr :-)
[gr] Vielen Dank für das Lob - und natürlich auch für den Kommentar an sich. Du hast einen sehr guten Punkt genannt: Wenn man von "Scrum" spricht, haben direkt alle ein bestimmtes Bild vor Augen, und es geht mehr um das Lehrbuch als um den persönlichen Bedarf.
Tatsächlich haben wir vor vielen, vielen Jahren so etwas wie AWOA (gelungener Name 😉) für uns gebaut, namens ADF - das "Agile Development Framework". Das war, um es an andere weiterzugeben, zu komplex - aber für uns hat es den enormen Nutzen gehabt, dass wir uns sehr explizit und sehr intensiv mit unserem eigenen Prozess befasst haben, den wir bis dahin gar nicht so ausformuliert hatten, aber dadurch kam das dann - und das hat geholfen, einfach, weil man über vieles noch einmal gründlich nachdenken musste.
Wenn Du sagst "gerne mehr" - meinst Du damit, speziell zu Themen wie agilen Methoden, oder allgemein?
@@thenativeweb Wir sind scheinbar auf einem Nenner mit dem Verständnis (ob Philosophie oder einzige Wahrheit sei jetzt mal dahin gestellt). Teils wurde ich in euren Videos bestätigt, teils ergänzt. Daher sowohl native Softwareentwicklung als auch agile Projektmanagement sind gern gesehen Themen. Da ich in anderen Sprachen beheimatet bin, tendiere ich mehr in die allgemeinen Programmierskills und eben Agiles :-)
@@GeckoHero [gr] Freut mich 😊
Schön kompakt zusammen gefasst! danke
[gr] Vielen Dank 😊
ielen Dank für Dein sehr spannendes und informatives Video. 😊
[gr] Vielen Dank 😊
Ich glaube du hast alle Scrum Fallen beschrieben. Zum Glück gibt es die Retrospektive, in der alles nachgebessert werden kann.
[gr] Das stimmt 😊
Sehr informatives Video :) Für mich ergeben sich noch zwei Fragen: Wie geht man am besten vor wenn ein Team an mehreren Projekten arbeitet? Für mich ist es noch etwas schwierig zu verstehen (wahrscheinlich da ich bisher auch noch nicht in einem agilen Team gearbeitet habe) wie man den agilen Ansatz und ein gut konzeptioniertes Produkt unter einen Hut bekommt. Ich verstehe Scrum so, dass für sich stehende User Stories ohne Abhängigkeiten geschrieben und in Sprints umgesetzt werden. Aber wie lässt sich so eine gute Grundlage mit wiederverwertbarem und gut strukturiertem Code schaffen?
[gr] Danke für Dein Feedback, das freut mich 😊
Zu Deinen Fragen … wenn ein Team an mehreren Projekten arbeitet, ist Scrum IMHO schon nicht mehr so übermäßig gut geeignet, weil Du dann konkurrierende POs und Anforderungen hast, und da geht es dann schon los mit so Fragen, wie was wann warum priorisiert wird … klar funktioniert es irgendwie, aber doch eher nur "irgendwie".
Was die zweite Frage angeht: Aufräumarbeiten, Refactoring & Co. müssen mit eingeplant werden, das heißt, jede Story ist nicht nur das neue Feature, sondern bedeutet auch, nach dem Umsetzen des Features stets auch die Zeit haben, aufzuräumen, sauber zu machen, … also es geht schon, erfordert aber viel Disziplin (aber das gilt bei Clean Code vermutlich ohnehin immer).
Laut Wikipedia hat XP sehr wohl organisatorische Regeln in petto. Diese ähneln sogar denen von Scrum.
[gr] Danke für Deinen Kommentar 😊
Ich orientiere mich, was XP angeht, hauptsächlich an extremeprogramming [dot] org, was eine sehr ursprüngliche Darstellung von XP ist. Natürlich hat sich XP in den vergangenen 20 Jahren auch weiterentwickelt und wurde auf verschiedene Arten ergänzt.
Schaut man sich die ursprünglichen Regeln an, fällt auf, dass es da einige wenige gibt, die man durchaus als organisatorischen Rahmen bezeichnen kann - im Gesamtkontext sind das aber nur sehr wenige, und sie sind verhältnismäßig unspezifisch. Auch im Vergleich zu Scrum und Kanban fällt auf, dass der Schwerpunkt von XP ein ganz anderer ist.
Insofern: Ja, XP enthält gewisse organisatorische Elemente, aber sie stehen weder im Vordergrund, noch sind sie allzu konkrete Handlungsanweisungen.
Was den Eintrag bei Wikipedia angeht, kenne ich den, allerdings ist mir nicht klar, wann der von wem wie ergänzt wurde, und auf welcher Basis dort beispielsweise ganz konkrete verschiedene Rollen genannt werden. Bei XP gibt es natürlich auch Rollen, wie das Team oder den Kunden, aber bei weitem nicht so konkret und spezifisch wie das bei Wikipedia dargestellt wird.
Letztlich kommt es am Ende des Tages ja aber ohnehin darauf an, dass man - so wie ich das auch im Video beschreibe - die für sich passten Elemente herausfindet und kombiniert. Eine einzige agile Methode wird häufig nicht ausreichen, einfach weil Software Entwicklung in sehr komplexer Prozess ist. Das heißt, dass man zum Beispiel natürlich Rollen brauchen wird, aber da muss man abgesehen von einigen wenigen Standardrollen dann ohnehin schauen, was jeweils passt.
Sehr cooles Video. Ich kann in dem Zusammenhang auch einen Vortrag von Allen Holub empfehlen, The death of Agile. Seine Thesen sind sehr polarisierend aber scheinen plausibel. Er meint, wie kann Scrum Agil sein wenn man dabei einen strikten Prozess folgen muss: ua-cam.com/video/vSnCeJEka_s/v-deo.html
Man hört deutlich deine negativen Erfahrungen mit Scrum durch. Schade, dass du das nicht positiver siehst. Ich habe auch viel negatives im Zusammenhang mit Scrum erlebt. Das lag aber in der Regel nicht an Scrum. Die positiven Erfahrungen überwiegen bei mir.
[gr] Ja, ich habe sehr viele negative Erfahrungen mit der Umsetzung von Scrum (nicht Scrum an sich!) erlebt.
Es gab auch Teams, wo das hervorragend geklappt hat.
Allerdings ist es dann in aller Regel genau so gewesen, wie im Video beschrieben, dass hier die Voraussetzungen ideal waren - da, wo das nicht gegeben war, funktioniert Scrum auch nicht.
Das ist kein Makel von Scrum, sondern eher ein falscher oder unpassender Einsatz von Scrum. Das kann man dann nicht Scrum vorwerfen, aber es wird eben einfach zu oft eingesetzt, ohne die passenden Bedingungen zu schaffen, dass es funktionieren kann.