Bitte geben Sie einen Grund für die Verwarnung an
Der Grund erscheint unter dem Beitrag.Bei einer weiteren Verwarnung wird das Mitglied automatisch gesperrt.
Skalierung von Scrum
Sehr interessanter Artikel über die Skalierung von Scrum, dem ich inhaltlich absolut zustimmen kann. Was meint ihr dazu?
http://agilix.nl/blog/blog-528-how-to-sc...uestion-to-ask/
Äußerst verständlich erklärt ... und ergibt Sinn.
#3
Hm, ich werde nicht warm damit. Es ist mir vieles zu unkonkret. Beispiele:
Angenommen ich habe ein Scrumteam für ein Produkt, zuerst mit 5 Leuten, nun sind es 8. Nun sollen noch vier Leute dazu kommen. Für orginal Scrum ist das zuviel. Was soll an der Frage falsch sein wie man Scrum skaliert?
"Find a Product Owner that understands the market, has an entrepreneur mentality and give her the funding to lead the product lifecycle." - das ist doch Scrum. Aber wie soll EIN PO das alles schaffen?
"Develop teams that can produce end-to-end customer features (a.k.a. Scrum Teams) and use them as your main organisational building block." - auch das ist doch Scrum.
"Organise your teams, that work on 1 product, to work in a single iteration..." - dito
"Move to cross functional line managers" - und wie sollen die konkret arbeiten? Was ist deren Ziel, die hängen die mt Scrummaster PO und Entwickler zusammen?
"Introduce a Human Operations system" - den Begriff habe ich noch nie gehört.
Zitat von LaberKachelSülz im Beitrag #3
Hm, ich werde nicht warm damit. Es ist mir vieles zu unkonkret. Beispiele:
Angenommen ich habe ein Scrumteam für ein Produkt, zuerst mit 5 Leuten, nun sind es 8. Nun sollen noch vier Leute dazu kommen. Für orginal Scrum ist das zuviel. Was soll an der Frage falsch sein wie man Scrum skaliert?
"Find a Product Owner that understands the market, has an entrepreneur mentality and give her the funding to lead the product lifecycle." - das ist doch Scrum. Aber wie soll EIN PO das alles schaffen?
"Develop teams that can produce end-to-end customer features (a.k.a. Scrum Teams) and use them as your main organisational building block." - auch das ist doch Scrum.
"Organise your teams, that work on 1 product, to work in a single iteration..." - dito
"Move to cross functional line managers" - und wie sollen die konkret arbeiten? Was ist deren Ziel, die hängen die mt Scrummaster PO und Entwickler zusammen?
"Introduce a Human Operations system" - den Begriff habe ich noch nie gehört.
Ich versuche es mal mit einem Beispiel zu verdeutlichen, wie ich den von mir zitierten Blogartikel interpretiere.
Beispiel für ein Unternehmen:
Geschäftsführung --> Fachbereiche A, B, C --> IT-Abteilungen 1, 2, 3 / Betrieb / Datawarehouse
Zum "Ausprobieren" von Scrum sagt das Unternehmen nun IT-Abteilung 1, dass sie aus ihren Mitgliedern doch mal ein Scrum Team bilden sollen und die Scrum Events, Rollen und Artefakte benutzen wollen. Nun läuft es gut, das Team ist motiviert und glücklich und das Unternehmen glaubt, dass es agiler werden muss, weil die Anforderungen von außen sich häufiger und schneller ändern.
Frage: Wie geht man nun vor?
Was ich am häufigsten sehe ist, dass man in den vorhandenen Silos (einzelne Fachbereiche, einzelne IT-Abteilungen, Betrieb, Datawarehouse, ...) nun Scrum einführt bzw. mehrere Teams mit Scrum arbeiten lässt und glaubt/hofft, dass dadurch das ganze Unternehmen agiler wird. Das Problem daran ist, dass es nicht funktioniert. Denn die ganze Steuerung (z.B. durch Fachbereiche) ist Silo/Hierarchie getrieben. Die Teams arbeiten zwar ein bisschen nach Scrum, doch der Product Owner soll eher feste Anforderungen umsetzen und hat eigentlich nichts zu entscheiden (der Fachbereich entscheidet den Scope Monate vorher). Er kann auch nicht wirklich spontan die Software produktiv schalten, da sie zu viele Abhängigkeiten zu anderen Produkten des selben Unternehmens hat.
Ich persönlich habe langjährige Erfahrung damit, dass dies nicht funktioniert. Wenn das Unternehmen agiler werden will, dann muss es die Organisation verändern. Dann muss es in Frage stellen, ob die Silo-Struktur und damit das Silo-Denken mit der Anforderung der Agilität vereinbar ist. Dann muss die Organisation überlegen, ob sie nach jedem Sprint etwas in Produktion liefern kann, nur weil eine IT-Abteilung in Scrum Teams arbeitet oder ob nicht doch die Abhängigkeiten zu anderen Anwendungen, zum Betrieb und zu DataWarehouse das verhindern. So interpretiere ich den Artikel und deswegen stimme ich dem inhaltlich zu.
Vielleicht sollten wir gedanklich von Scrum weg. Viele Unternehmen sind der Meinung, agil zu sein, wenn sie in einem Bereich Scrum einführen. Wie auch schon beschrieben, ist es sicherlich in vielen Bereichen kein Problem, einen ("geschützten") Bereich mit Scrum arbeiten zu lassen. Das heißt dann aber nicht, dass das Unternehmen agil ist.
Anders herum betrachtet kann ein Unternehmen sehr wohl agil arbeiten, ohne dabei Scrum zu verwenden.
Wenn das gedanklich in den Köpfen drin ist, ist der Rest gar nicht so schwer. Ich habe mit 4 Teams angefangen und für die 4 Teams gab es einen PO. Unser Vorteil war, dass sich niemand darüber Gedanken gemacht hat, ob das vielleicht gar nicht funktionieren könnte (frei nach: Alle sagten: Das geht nicht. Dann kam einer der das nicht wusste - und hat es gemacht.)
Wir haben gar nicht darüber nachgedacht, ob das nun nach den Scrum Regeln ist oder nicht. Und es hat funktioniert.
Ihr glaubt gar nicht, wie lange ich mich gefragt habe, was überall von Skalierung gesprochen und geschrieben wird. Tatsächlich war mir nicht mal klar, wo das Problem liegen soll. Unwissenheit ist manchmal also gar nicht soooo schlimm.
Moderator - Admin - www.DasAgileForum.de
Zitat von Niklas im Beitrag #6Zitat von Nina im Beitrag #5
Wenn das gedanklich in den Köpfen drin ist, ist der Rest gar nicht so schwer.
Da gebe ich dir vollkommen Recht... aber wie häufig finden wir das vor, speziell in großen, alten Unternehmen?
Das ist für erfolgreich agiles Arbeiten aber eben Grundvoraussetzung. Alles andere ist Geld- und Zeitverschwendung. Ich sehe das ähnlich. Wer es mal verstanden hat, hat mit dem Skalieren auch keine Probleme.
Zitat von Coach F. im Beitrag #7
Das ist für erfolgreich agiles Arbeiten aber eben Grundvoraussetzung. Alles andere ist Geld- und Zeitverschwendung. Ich sehe das ähnlich. Wer es mal verstanden hat, hat mit dem Skalieren auch keine Probleme.
Ich gebe dir vollkommen recht, dass dies für (erfolgreich) agile Arbeiten Grundvoraussetzung ist. Aber ich sehe dies zusätzlich als meine Aufgabe, meine Kunden diese Grundvoraussetzung zu erklären und dabei zu unterstützen, diese zu schaffen. Ich sehe mich weniger als jemanden, der nur dorthin geht, wo eh schon alles funktioniert und nur ein Moderator für bestimmte Events gesucht wird.
Hallo,
ich arbeite in einem Startup dass sich darauf spezialisiert eine Projektmanagement-Software zu entwickeln. Das ist es auch, um was es sich hauptsächlich auf unserem Blog dreht. Wir erforschen alle möglichen Projektmanagement-Methoden, darunter auch SCRUM. Erst nenulich ist hierzu ein Beitrag inline gegangen, wie man trotz fester Strukturen in Scrum agil arbeiten kann. Schaut Ihn euch gerne an! Mich würde eure Meinung interessieren.
Hi Elen,
zunächst mal ein herzliches Willkommen hier im Forum :)
Ich finde den Blog Beitrag sehr gut und verständlich geschrieben. Insbesondere, weil dabei Scrum nicht als das Heilmittel für Alles angepriesen wird. Genau wie es beschrieben wird, kommt es in einem Projekt nämlich darauf an, welche Projektmanagement Methode zum Team, zum Projekt und zu den allgemeinen Umständen in einem Unternehmen passt. Damit steht und fällt meiner Meinung nach der Erfolg eines Projektes.
Es gibt lediglich einen Satz, den ich so nicht bestätige "Scrum ist eine der beliebtesten Projektmanagement Methoden." Ich bezeichne Scrum eher als die Methode, die am "hippsten" ist. Auf große Freude und Beliebtheit stößt man mit Scrum nämlich nicht allzu oft. Das liegt aber sicherlich daran, dass viele Unternehmen und deren Mitarbeiter diese Art agiler Arbeitsweisen nie richtig kennengelernt haben.
Hey, falls ihr euch fragt welche Methode denn am besten zu eurem Projekt passt, dann hab ich hier was für euch. Wir haben ein Quiz entwickelt, das gezielt beantwortet, welche Projektmanagement Methode zu eurem Projekt passt. (Falls es mal nicht Scrum sein sollte ;) ) Hier könnt ihr es ausprobieren, würde mich über Feedback sehr freuen: https://zenkit.com/de/blog/quiz-zur-pass...gement-methode/
#13
Zitat von LaberKachelSülz im Beitrag #13
Hat jetzt mit Skalierung von Scrum nur bedingt zu tun, bitte dann einen neuen Thread anfangen
Stimmt. @Luisa: Mach doch einfach einen passenden neuen Thread auf.
- Das Forum
- Was ist Agile und für wen und was ist das Forum gedacht?
- Neues und Wichtiges
- FAQs
- Regeln
- Agile Methoden
- Kanban
- Design Thinking
- Lean Management
- DevOps
- SCRUM
- Konklave - Backlog - Backlog Refinement - Planning I
- Sprintplanung - Planning II
- Daily Standup Meeting
- Demo - Sprint Review
- Retrospektive
- Implementierung von Scrum
- Rollen
- Softskills
- Übungen zur Aktivierung von Teams
- Feedback geben, bekommen und einfordern
- Moderationstechniken
- Werkzeuge und Hilfsmittel
- Hardware
- Software
- Kennzahlen und Messmethoden
- Medien
- Youtube
- Literatur
- Artikel und Berichte
- Dokumente und Schulungsunterlagen
- Umfragen für wissenschaftliche Arbeiten
- Support und allgemein Technisches
- Support
- Ausbildungen und Veranstaltungen
- Ausbildungen, Schulungen und Workshops
- Vorträge
- Meetups
- Konferenzen und Kongresse
- Plauderecke
- Premiumbereich
Jetzt anmelden!
Jetzt registrieren!