# Scrum & Co



## schalentier (26. Jan 2011)

Hallo,

da das Thema inzwischen mehrfach am Rande in verschiedenen Thread genannt wurde, und es mich auch einfach so interessiert:

Was haltet ihr so von Scrum, KanBan und anderen agilen Softwareentwicklungsmethoden? 
Setzt ihr das bei euch in der Firma ein? Erfolgreich? 
Oder is das alles nur ein uebertriebener Hype?

Besonders interessiert mich, wie man in einem bestehenden Team Scrum oder ein scrum-aehnliches Vorgehen erfolgreich einfuehren kann. Hat sowas vielleicht schon mal jemand gemacht?


----------



## Grey_M (26. Jan 2011)

Wir, die Java-Entwicklung unseres Unternehmens nutzen Scrum. Das Team in dem ich arbeite ist mit 3 internen und 2-3 externen ziemlich klein.

Wir haben damit angefangen unsere Aufgaben in max 16h große Blöcke aufzuteilen und diese für 2 Wochen zu planen.
Morgens erzählt dann jeder kruz was er gemacht hatt, was er vor hat und was ihn gestört hat.

Neben uns Entwicklern ist dann noch der stellvertretende Produkt-Manager im Morgenmeeting dabei. Der kann dann anhand unserer Meldungen seine Planung kontrollieren,

Ich bin auf jeden Fall sehr zufrieden mit Scrum. Es hilft einem selbst einen Überblick zu erhalten. In Zusammenarbeit mit Jira ist auch die Planung und Auswertung relativ einfach.


Der Fachbereich bzgl. Produkt-Manager muss aber mitziehen. Er sollte sich für 2 Wochen auf definierte Aufgaben festlegen können.


----------



## bygones (26. Jan 2011)

2wochen ? das ist schon ganz schön kurz... aber wenns klappt 

bei uns hier in der firma wird die einführung diskutiert, erstmal aber mit dem Versuch intern dies zu nutzen bzw mit einem ausgewählten Kundenkreis. Denn leider nicht jeder Kunde ist da flexibel genug.

Das einführen ist meiner ansicht nach in bestehende Strukturen etwa so gefährlich wie ein existierenden Build komplett auf Maven umzustellen.... schwierig und mit vielen Hürden.

Es kommt viel darauf an wie die Entwickler sind und wie das Arbeitsumfeld. Nur weil es ein Hype ist oder es ansich die entwicklung verbessert, heißt das noch lange nicht, dass es in seinem Team klappen wird. Je mehr Zweifler und starre Menschen man drinnen hat umso unwahrscheinlicher ist es, dass es erfolgreich wird.

Ansich denk ich, dass man eher eine seichte einführung mit zb Kanban gehen sollte und nicht von heute auf morgen auf zb Scrum umstellen sollte. Weiterhin sollte man sich dringenst von außen einen Fachmann reinholen, um den Übergangsprozess so schnell und einfach wie möglich zu schaffen.


----------



## ItseMe (26. Jan 2011)

Lustige Frage, aber ganz ehrlich, Scrum ist eine "Managementtechnik", hier wirst Du es schwer haben einen Projektleiter (oder Ähnliches) zu finden, der freiwillig und gerne darüber schreibt, dass er mist gebaut hat. Hier würde "Scrum war schuld" oder "XP war schuld" oder so nur eine Ausrede. 

Aber um auf die eigentliche Frage einzugehen, agile Softwareprozesse sind super, wenn sie zum Projekt passen. Hast Du wirklich statische Anforderungen gibt es bessere Lösungen, aber für viele Firmen passt das gut zum Produkt- und Projektgeschäft. Man kann wirklich effizient damit arbeiten. 
Allerdings gibt es ein paar Fallstricke, die relativ häufig beobachtet wurden/werden:

Die Einführung kostet Zeit! Man wird nicht in einem Monat einen funktionierenden Scrum-Prozess inkl. Mehrwert aus dem Boden stampfen
Konsequenz ist alles! Auch wenn man von agilen SW Prozessen spricht, muss man den Prozess strikt einhalten!
Hilfe von außen ist gut (und das ist nicht nur ein Verkaufsargument der ScrumMaster).

2. ist wirklich essentiell, viele Leute und Chefs hören agil und weichen den Prozess (wie auch andere) auf. Man hat dann doch noch eine dringende Änderung, die unbedingt noch zwischen gehört, eine Person ist plötzlich ProductOwner und ScrumMaster (man hat ja keine Ressourcen) usw. Das alles führt unweigerlich zum Scheitern! 
Das agile bezieht sich immer darauf, dass man in einem Sprint eine bestimmte Flexibilität bei der Auswahl und Abarbeitung der Tasks hat, die im Sprintbacklog stehen, das Sprintbacklog wird aber eben nicht während des Sprints geändert. Genau das löst nämlich eines der Probleme der SW-Entwicklung, es gibt den Entwicklern Planungssicherheit (und wenn auch von außen klar ist, dass man 2-4 Wochen keine Änderungen einbringen kann, dann überlegt man gerne auch dort vorher etwas mehr). Natürlich ist auch Scrum nicht so statisch, dass man keine Änderungen mehr vornehmen kann, aber hierbei ist der aktuelle Sprint zu unterbrechen und anschließend ein neuer Sprint zu starten. Ein Vermischung ist aber ein no go.
Genauso sieht es eben mit den Rollen aus, die haben teilweise einen gegenteiliges Interesse, so dass eine Vermischung ganz schnell zu Problemen führt. 

Externe ScrumMaster klingen erstmal nach viel unnötigem Geld, bieten aber verschiedene Vorteile. Die schauen einfach wirklich von außen drauf und haben auch einen anderen Stand vorm Chef und dem Team (externen wird immer andere Aufmerksamkeit zu teil, als internen Angestellten, bewußt oder nicht), der hat Erfahrung und kennt auch die typischen Probleme und der steht eben auch für die Fragen und Unsicherheiten (die es nunmal gibt wenn man etwas Neues macht) zur Verfügung. Sowas kann sich schnell rentieren! Und um es klar zu sagen, nein, weder bin noch war ich ScrumMaster oder habe so jemanden im näheren Bekannten-/Freundeskreis ;-)

Allerdings habe ich hier schon mit mehreren Leuten zu tun gehabt, die in ihrer Firma Scrum mit und ohne Unterstützung eingeführt haben und auch Vorträge von z.B. Allen Atlas gehört (der hat Scrum bei Amazon eingeführt) und die Probleme waren immer die gleichen, offene Fragen wie man mit bestimmten Problematiken umgeht und bei (zu) vielen Firmen das Sparen am Anfang und erstmal vorsichtig gucken. Das ist wie "ein wenig schwanger", es gilt auch hier ganz oder gar nicht. 

Wer auch immer so einen Prozess einführt, der sollte sich vorher klar machen (und das auch mit der nächst höheren Etage abklären), dass es erstmal so ein gutes halbes Jahr Frust geben wird. Die Erwartungen sind riesig, alle sind anfänglich hoch motiviert und trotzdem ist es ein neuer Prozess den man erst lernen und verstehen muss. Man spart nicht vom ersten Tag, die Einführung kostet erstmal und der Gewinn kommt (nachhaltig) erst später, es gibt Dinge die einem nicht klar sind und auch wenn die Zeit knapp ist, Reviews und Planung sind wichtig und Sprints können nicht unterbrochen oder aufgeweicht werden (aber abgebrochen und durch einen neuen ersetzt). 
Stellt man sich einfach realistisch darauf ein, dass auch so ein Prozess nicht in jeder Situation glänzt und das die Schätzung erst mit der Zeit scharf und die Burndown-Charts schön werden, dann kann man sich (imho) den Prozess ruhig mal anschauen, schlecht ist er nicht, GMV ersetzt aber kein Prozess der Welt!


----------



## fastjack (26. Jan 2011)

Ein paar Beispiele aus meiner Erfahrung:

In einer Firma (kein Scrum, kein agil etc) wurde alles (aus Sicht des Management) total durchorganisiert. Es gab Projektleiter, einen Oberguru, hunderte von Projekten (teilweise überflüssige). Jeder Entwickler arbeitet an einer handvoll Projekten gleichzeitig. Änderungen, Erweiterungen, Bugfixing musste man selbstständig "eintakten". Für Tests, Doku etc. wurde keine Zeit eingeplant. Entwicklungszyklen waren viel zu kurz (so schwer kanns doch nicht sein oder?). Letztendlich trug das zur völligen Bewegungsuntauglichkeit der Firma bei... Überstunden bis in die Nacht, Demotivation wo man nur hinsah (nur ganz Oben war gutes Wetter  ). Unstabile Software...

In einer anderen Firma gab es ITIL. Es wurde dort eingeführt, ohne Berater etc. einfach nur aus dem Wissen zweier Personen, die ein Buch darüber gelesen hatten, was womöglich auch der Fehler für den Misserfolg  war. Anfangs gut, später grausame Erfahrung für jeden Entwickler. (Über)Organisation wo man nur hin sah. Viele Projekte, viele Projektzettel, tausende Meetings, Boards hier Boards da. Es gab Entwickler, die in einem Projekt alle Funktionen inne hatten (Changemanager etc.). Einige Wochen später wollte die Leitung die Projekte nicht mehr verwalten. Meetings und Boards wurden seltener, Projektzettel nicht mehr aktualisiert und schließlich den Personen übertragen, die in den Projekten sowieso schon alle Funktionen hatten. Irgendwann völlige Lähmung...

Eine Firma mit einem agilen Team von 3-4 Entwicklern. Die agile Entwicklung wurde hier auch nicht durch einen Berater eingeführt, da ein früherer bestellter Berater nur "heiße" Luft erzählte und verkaufte. Userstories werden in einem zweiwöchentlichen Meeting besprochen. Daraus entstanden Aufgabenzettel. Jeder Entwickler konnte sich Morgens Aufgaben von der Wand nehmen und diese bearbeiten und nach der Bearbeitung an eine andere Wand hängen. Nach zwei Wochen war normalerweise alles bearbeitet. Kamen zwischendurch größere Aufgaben hinzu, wurde besprochen, ob das zu schaffen sei oder nicht, dementsprechend wurden andere Aufgaben dafür "verlegt". Es gab noch Optimierungsbedarf beim Bugfixing, da hier die Meinung galt, das man das nebenbei machen konnte. Grundsätzlich gab es eine gute Stimmung bei allen Angestellten und sehr wenig Streß und Überstunden. Für Entwicklung und Test etc. wurde genügend Zeit einberaumt. Die Software war stabil und wartungsarm. Kosten für die Einführung des agilen Systems - fast keine, sieht man mal von den Reisszwecken ab, mit denen die Zettel an den Wänden befestigt wurden.


----------



## Herr K. (30. Jan 2011)

> In einer anderen Firma gab es ITIL. ... Anfangs gut, später grausame Erfahrung für jeden Entwickler.



Ich finde es schön, dass hier gleich deutlich gezeigt wird, woran die meisten solcher Prozesse in der Praxis scheitern. Der einfache Grund für dieses Beispiel besteht darin, dass ITIL sich zur Softwareentwicklung verhält wie Äpfel zu Eiern (anders als bei Birnen kannst Du da nicht mal Obstsalat draus gewinnen).
Wenn der IT-Betrieb auf ITIL gesetzt hätte, dann wäre abzuwarten ob und wie das mit einem Buch geklappt hätte (wahrscheinlich würde man auch hier scheitern, kann aber sicher auch vom Buch abhängen ;-)). 

Meiner Meinung nach sieht man hier etwas, das man nicht selten findet, da hat jmd. ein cooles neues Buzzword aber nicht die Idee dahinter verstanden. Einen Prozess kann man einführen, solange der nicht gelebt wird, wird man scheitern. Das gilt für ITIL, Cobit, Grundschutz/ISO 27001, Scrum, XP usw. gleichermaßen. 
Damit ein Prozess gelebt wird sind verschiedene Punkte wichtig, es fängt jedoch damit an, dass man den Sinn verstanden hat. Es geht in keinem der Prozesse darum sich Vorschriften zu unterwerfen und die stupide 1:1 umzusetzen. In meiner ITIL Schulung wurde vom Vortragenden z.B. mehrfach darauf verwiesen, dass ITIL (und kein anderer Prozess) einem vom Mitdenken befreien. Zentral ist also weiterhin der Verstand der beteiligten.

Für die Softwareentwicklung ist ein Prozess wie ITIL einfach völlig ungeeignet, während Scrum sich hier deutlich eher anbietet. Aber auch hier muss man schauen, die Qualitätssicherung oder das Erstellen von Fachkonzepten lassen sich nicht unbedingt sinnvoll in ein Scrum gießen, auch sollte das Projekt bestimmen welche Technik gut zur Umsetzung geeignet ist und nicht umgekehrt. 

Für die meisten Prozesse gilt, dass man einfach realistisch rangehen lernen muss. Am Anfang ist die Motivation hoch und jeder erwartet schon kurzfristig eine Verbesserung. Gibt es aber so gut wie nirgends. Auch wird gerne der Fehler gemacht, dass man erstmal nur ein paar wenige Ressourcen zugesteht und wenn's gut läuft, dann kann man ja immer noch nachlegen.
Dem steht aber gegenüber, dass etwas neu eingeführt wird, es fehlt an Expertenwissen und den hohen Erwartungen folgt erstmal Veränderung (der Mensch ist aber eher ein Gewohnheitstier). Erfahrungsgemäß sind viele Leute bei einem Konsequenten ITIL z.B. anfänglich negativ überrascht, wenn man plötzlich das Incident Management bemühen muss. Vorher ging man zu Klaus-Erwin, der hat sich auch immer gekümmert, das geht dann plötzlich nicht mehr.

Auch was die vielen Boards angeht, die gibt es so nicht, man hat das CAB und das ist auch gut so. Das entscheidet über Änderungen und muss dabei einfach die Risiken abschätzen. Ganz wichtig, das CAB darf auch Vorautorisieren und das wird in der Praxis auch gemacht!

Mit mindestens einem halben Jahr darf man eigentlich bei fast allen Prozessen dauern, bis die mal anlaufen. Bei Grundschutz oder ISO 27001 Zertifizierungen spricht man sogar eher von einem Jahr oder mehr (deshalb gibt es beim Grundschutz auch die Zwischenzertifizierung). Und für den Verantwortlichen werden das belastende Monate sein, den (häufig falschen) Erwartungen folgt anfänglich Frust. 
Eine gute Umsetzung führt dazu, dass diese Phase nicht lange anhält, dass sie komplett ausbleibt ist aber eher selten. Denn natürlich muss man sich erstmal an die Änderungen gewöhnen und die verinnerlichen, hat Fragen und muss ggf. auch mal länger auf eine Antwort warten. Wurde aber der Prozess passend ausgewählt (ITIL für SW-Entwicklung kann nicht klappen) und wird der richtig motiviert und etabliert, dann stellen sich auch die Vorteile ein. So kann z.B. ITIL tatsächlich das Leben vereinfachen, weil es eine klare Rollenverteilung gibt. Viel zu gerne machen gerade ITler vieles zu ihren Problemen, ohne dass dem so ist, aber das ist ein anderes Thema.

Zu guter letzt, das positiv Beispiel überrascht mich wenig. Bei 3-4 Entwicklern wird jede Entscheidung (fast automatisch) gelebt. Da werden sicher alle zusammengesessen und sich gemeinsam für eine Lösung entschieden haben. Die Beteiligten haben vielleicht den Prozess auf Anhieb verstanden und wussten, dass die anderen nicht beeindruckt sind, wenn man ständig betont, dass man jetzt "Scrum" oder "XP" oder "HAST_DU_NICHT_GESEHEN" macht.
Letzteres wird gerne einem übergeordneten Management unterstellt (in bestimmten Schichten sind Buzzwords wichtiger als die Technik dahinter zu verstehen). 

Aber hier muss ich auch eine Lanze für gutes Management (das gibt es tatsächlich auch) brechen, bei 3-4 Personen gestaltet sich die Schwierigkeit ganz anders, als bei 30-40 Personen (oder gar 300-400 Personen). Je größer die Teams sind, um so mehr Struktur und Overhead ist nötig um die Arbeit überhaupt noch koordinieren zu können. 
Aber auch hier ist es nicht damit getan einen populären oder gut klingenden Prozess zu suchen und zu sagen, so, machen wir. Vielmehr muss der Kern erfasst und gelebt werden (durch alle Mitarbeiter). Die Kunst besteht ja gerade darin, dass der Mehrwert auch bei den Leuten ankommt und sich auch für sie zeigt. Und wie bereits gesagt, man darf nicht den Verstand zu Gunsten des Prozesses abschalten! Ein Prozess wird wie jedes Werkzeug zu dem Ziel ausgesucht das man erreichen möchte, niemals sollte in Prozess/Werkzeug das Ziel vorgeben.


----------

