Einführung in Scrum/agiles Projektmanagement/Design Thinking

[Aldwin]

Hallo in die Runde,

ich bin am Freitag bei einem interessanten Arbeitgeber bei mir in der Region zum gegenseitigen Kennenlernen eingeladen. Mein Lebenslauf passt sehr gut zu zwei der ausgeschriebenen Stellen. Leider kenne ich mich aus meinem Studium und den bisherigen Berufsstationen (eher Schlipsträgermafia-Bereich) noch kaum mit den Begrifflichkeiten im agilem Projektmanagement/Scrum/Design Thinking aus. Ich war in der vergangenen Woche auf einem Design Thinking-Meetup, aber war mir danach nicht ganz sicher, ob das Buzzwordbingo ist oder eine klar abgegrenzte Managementstrategie. Vermutlich irgendwie beides ..

Ich würde mir gerne morgen ein paar Sachen anschauen, womit ich einen guten Einblick erhalte. Reicht da einfach ein paar gut bewertete Youtube-Videos zu schauen oder könnt ihr Podcasts oder Literatur (habe Zugang zu einer großen Unibib um die Ecke) empfehlen? Basiskram reicht .. Würde einfach gerne wissen worum es geht. Mein Eindruck ist, dass viele kleine Teams so arbeiten, es aber meistens gar nicht wissen, dass es Scrum oder agiles Projektmanagement ist.

Danke für Tipps!

Beste Grüße

 

[Mextli]

Die meisten Entwicklerteams arbeiten heutzutage nach agilen Methoden, Scrum ist lediglich eines von mehreren agilen Frameworks (geeignet für kleinere Gruppen) und wird auch gerne kombiniert (z.B. durch Einsatz von SW wie JIRA, Slack etc. die Kanban Boards unterstützen).
DT ist als Innovationsmethode stark im kommen, da es den Kunden in den Fokus setzt. Für viele Firmen tatsächlich ein ganz neuer Ansatz. *hust

Bücher die mir geholfen haben:
Scrum verstehen und erfolgreich einsetzen, dpunkt Verlag
Design Thinking Das Handbuch - Frankfurter Allgemeine Verlag

 

[nik_]

https://www.amazon.de/Agile-Testing-agile-Weg-Qualität/dp/3446431942

das buch beschäftigt sich eher mit testen.

ansonsten balzert, sommerville

 

[hallo7]

Scrum ist ja komplett im Internet beschrieben und kann man nachlesen (auf Wikipedia oder Scrum.org). Einem Unternehmen welches Scrum zu 100% umsetzt bin ich noch nicht begegnet, meist hat man eine unternehmensspezifische Abwandlung davon.

Die grundlegenden Ideen dahinter sind nicht wirklich neu, man hat ihnen einfach neue Namen verpasst, vereinheitlicht bzw. setzt es mal um

 

[Aldwin]

Vielen dank euch dreien!

Ich habe mir heute Nachmittag einiges auf Youtube zu den Themen Scrum und Design Thinking angeschaut. Macht auf mich einen sinnvollen Eindruck, gerade um Schwächen des klassischen Projektmanagements aufzuzeigen. Ganz konkret weiß ich immer noch nicht, ob das im Grunde nicht genau das gleiche ist, wie ein gut funktionierendes Team, dass gemeinsam die Aufgaben anpackt, kurzfristige Etappenziele festlegt anstatt wochenlang isoliertere Projektarbeit zu betreiben und im Zweifel bereit ist über Zielvorstellungen konstruktiv nachzudenken.

Macht schon alles Sinn, auch wenn das auf mich ein wenig sehr nach Innovationshype ausschaut. Habe die Keywörter nun drauf und weiß zumindest mitzureden.

Danke in die Runde!

Beste Grüße

 

[ayngush]

Hallo,

die "Klassiker" werden auch im agilen nicht verschwinden.
Das Requirements Engineering ist im agilem Vorgehen genau so wichtig wie im klassischen Vorgehen.
Viele fangen leider vorne an die User Storys zu formulieren - aber eigentlich gehört da am Anfang eine klassischer "Produktprozess" (IST-SOLL-Transfer) dazu mit all den Fragegebilden und Dokumentationen. Und erst, wenn ich die Anforderungen, Qualitätsvorgaben und Rahmenbedingungen erfasst, verstanden und Dokumentiert habe kann ich (mit dem Auftraggeber ZUSAMMEN) die User Storys formulieren. Die sind nämlich nichts anderes als die Anforderungen, Qualitätsvorgaben (manchmal leider auch nicht funktionale Anforderungen genannt) und Rahmenbedingungen anstatt in UML- / Whatever-Modellen Dokumentiert in natürlicher Sprache dargestellt.

Ich kann ein vorher analysiertes Problem also mit UML- / ER- / Systemkontext- / usw.- modellen abbilden oder auch mit User Storys.
Diesen RE-Prozess "vergessen" nur leider sehr viele agile Teams am Anfang, da sie der Meinung sind, dass "drauf los wurschteln" im agilen ja so vorgesehen ist (man muss am Anfang nicht alles wissen und kennen - dennoch muss man wissen, was der Auftraggeber überhaupt haben möchte).
Das stimmt aber nicht, das Hauptkonzept ist das "Improvement" und das haben die sich einfach vom "Kaizen Management" abgeschaut. Hauptziel ist es also mit weniger, dafür besseren, (human) Ressourcen mehr Qualität herzustellen und diese kontinuierlich zu verbessern. Diesen Transfer haben bisher alle externen Teams die mir als AG gegenüber behaupteten sie würden agil arbeiten hart verkackt. Häufig steht agil in der Praxis (leider) für professionelles Wurschteln, solange bis entweder eine Seite kein Bock mehr hat oder es irgendwann passt. Sprich: Sie verwechseln ernsthaftes agiles Vorgehen mit Code & Fix!

Deshalb werde ich immer sehr hellhörig, wenn mir einer "agil" verkauft, ich habe Projektmanagement (von den Grundlagen "Deming Kreis" über die Definitionen wie DIN & Pince2 bis hin zu den einzelnen Vorgehensmodellen (Spiral, RUP, Scrum, XP, ...) und dem Warum machen wir das überhaupt) nämlich ernsthaft gerlernt und zertifiziert bekommen. Andere schauen leider zu viel Youtube Videos und kapieren nicht, dass man die Grundlagen aus Büchern, Kursen & Workshops erfährt und nicht von Youtube

 

[hallo7]

Beim echten Scrum schreibt auch der Product Owner die User Stories und das ist im Idealfall der Kunde selbst. Weiß dann der Kunde auch noch was er tut, funktioniert das ganz gut.

Somit kann das agil arbeitende Projekt Team eigentlich nichts dafür, denn diese Aufgabe hat nunmal der Product Owner, also die Auftraggeberseite, zu erledigen
Und ja, der Auftraggeber sollte nach Scrum beim Entwicklerteam sitzen und täglich den Fortschritt kontrollieren und für Fragen bereitstehen.

Natürlich wird das meistens nicht so gemacht bzw. viele Auftraggeber könnten das auch gar nicht. Somit wird er häufig auch vom Entwicklungsunternehmen gestellt und meist wird die Rolle falsch angewandt.

Der Product Owner hat nur die Auftraggeberseite zu vertreten und hat vorzugeben was gemacht wird - allerdings nicht wie es gemacht wird, was es kostet usw.

Natürlich sollte der Product Owner eine Planung machen - da wären die klassischen Ansätze sicher nicht verkehrt
Nur hat das halt nichts mit der Kompetenz des agil arbeitenden Teams zu tun.

Als Auftraggeber, sprich Stakeholder wärst du dann übrigens auch verantwortlich einen geeigneten Product Owner zu stellen und ihn mit den nötigen Infos zu versorgen oder es gleich selbst zu machen.

 

[ayngush]

Der Product Owner ist nicht der Auftraggeber.
Das sind alles Aufgaben, die ich als Auftraggeber ganz klar und definitiv nicht erledige, wenn ich jemanden beauftrage für uns eine Webanwendung zu programmieren z.B.
Als Auftraggeber wirke ich bzw. meine Experten in Workshops mit und erwarte, dass der Typ, der sich am anderen Ende "Projektleiter" bezeichnet daraus etwas "macht". Das ist schließlich seine Rolle und seine Verantwortung in dieser Rolle - intern kann der sich dann ja in der Umsetzung Product Owner oder Dagobert Duck nennen - das ist mir egal.
Fakt ist: Agil hat sehr viel, sehr gute und sehr richtige Ansätze, die, richtig angewendet, zu sehr guten Ergebnissen in einem erstklassigen Umfeld führen.
Ich sage: Erlebt habe ich das bisher ausschließlich dann, wenn es sich um ein vollständig internes Projekt innerhalb eines Unternehmens handelt.
Stakeholder sind übrigens alle möglichen vom Projekt betroffenen (und nicht nur der Auftraggeber) - das kann sogar die Öffentlichkeit sein, sofern es sich um öffentliche Gelder handelt.

Der Auftraggeber bezahlt, wird informiert und wird beliefert. Nichts weiter.

 

[hallo7]

Der Projekt Manager/Leiter sollte nicht der Product Owner sein. Das wäre gegen das Scrum Prinzip, da diese beiden Rollen unterschiedliche Aufgaben und Ziele verfolgen. Einen klassischen Projektleiter/-manager gibt es bei Scrum gar nicht.
Der Auftraggeber hat mit dem Product Owner zu kommunizieren

Wie gesagt, der Product Owner hat den Auftraggeber zu vertreten!

Im echten Scrum muss sich auch der Auftraggeber entsprechend einbinden und wissen was er zu tun hat, sonst funktionierts nicht und es ist eben nicht so das er nur bezahlt.
Die Agilen Methoden wurden entwickelt um den Auftraggeber möglichst umfangreich einzubinden und eben das Hauptproblem -> der Auftraggeber weiß nicht was er will bzw. unterschiedliche Vorstellungen vom Endprodukt - zu minimieren.
Das Funktioniert nur wenn der Auftraggeber beim Entwickler verfügbar ist (sei es indem er direkt den Product Owner stellt oder diesen weitreichende Informationen bzw. Feedback geben kann).

Wird in der Praxis selten gelebt und ist übrigens auch einer der Hauptgründe wenns nicht funktioniert