Archiv für Januar, 2010

Material, Fitness und Motivation

Sonntag, Januar 10th, 2010

Heute beim Trainingslauf im Schnee: In der Ferne ein Läufer auf Langlaufskiern. Ich nähere mich langsam – er scheint das bessere Material bei diesen Verhältnissen zu haben. Aber ich bin etwas schneller.

Vielleicht bin ich einfach fitter. Ich hole ihn ein. Kurz bevor ich ihn erreiche, kommen zwei junge Damen in Sicht. Vor uns, in unserer Richtung unterwegs. Der Langläufer erhöht das Tempo und überholt die Damen lässig und zügig. Was doch für Motivation entstehen kann!

Der Abstand zu mir wird wieder größer. Er scheint doch fitter zu sein. Oder sein Material ermöglicht eine Steigerung der Geschwindigkeit, während ich auf meinen Laufschuhen bei diesen Witterungsbedingungen weniger Reserven habe.

Er lässt wieder nach – ich hole auf. Eine ältere Dame auf Langlaufskiern kommt entgegen. Plötzlich beiderseits ein Freudenschrei – sie kennen sich. Sofort endet seine Motivation zum Sport. Er hält an, um zu plaudern.

Ich ziehe vorbei. Mit schlechterem Material und einer im Vergleich zum Wettbewerber unbekannten Kombination aus Fitness und Motivation.

Genauso, wie im Gründerleben.

Scrum, einer für alle, alle für einen

Montag, Januar 4th, 2010

Scrum dient dazu traditionelle Arbeitsstrukturen aufzubrechen und Hierarchien abzuflachen. Hier liegt die Chance, aber auch die Herausforderung der agilen Softwareentwicklung. Wir sind keine Verwaltung. Wir sitzen nicht in unseren kleinen Büros, gießen die Zimmerpflanzen und googlen uns selbst. Wir können und wollen uns nicht hinter einem schützenden Vorgesetzten verstecken, wenn es brenzlich wird.

Scrum zeichnet sich dadurch aus, dass alle ihr Commitment geben. Jedes Teammitglied ist ebenso wie der ScrumMaster, der Product Owner und der Kunde für den Erfolg oder Misserfolg verantwortlich.

Der Product Owner kennt die Software und die Arbeitsweise des Programmierteams, er muss die Kundenwünsche und -bedürfnisse in eine Sprache übersetzen, die von Technikern verstanden wird. Er muss den Wunsch des Kunden so konkret wie möglich definieren, es ist jedoch nicht seine Aufgabe eine genaue Programmieranleitung zu liefern. Der Product Owner ist kein Programmier.

Das Team besitzt technisches Know-How. Es ist dafür verantwortlich, dass die Software in einer lauffähigen Version vorliegt. Es bringt die Kundenwünsche mit den technischen Möglichkeiten in Einklang. Das Team darf nicht für ungenau beschriebene Aufgaben verantwortlich gemacht werden. Das Team ist nicht zuständig für das Produktmanagement.

Doch Vorsicht: Scrum entbindet nicht vom selbstständigen Denken, im Gegenteil, es fordert dazu auf. Die Kommunikationswege sind kurz. Durch das tägliche Stand-Up kennen alle Beteiligten den Prozess und die Aufgaben des Einzelnen. Es steht jedem frei, Fragen zu stellen, Anregungen zu geben und Ideen einzubringen. Jeder kann und sollte das Team vor möglichen Fehlern warnen.

Der Product Owner leistet einen guten Job, wenn er auch die technischen Abläufe mit durchdenkt. Nach einer Weile hat er viele Restriktionen durchschaut und kann es vermeiden dem Kunden Features zu versprechen, deren Kosten und Nutzen in keinem Verhältnis stehen. Das Team zeichnet sich dadurch aus, technische Sackgassen frühzeitig zu erkennen, die Warnung offen auszusprechen und alternative Lösungen zu finden.

Die Prinzipien klingen einfach und innovativ. Schnell umzusetzen für ein junges Team? Nein, auch das Erlernen und der Umgang mit Scrum sind viel Arbeit. Die richtige Anwendung von Scrum braucht Zeit, Erfahrung und erfordert das Zusammenspiel des gesamten Unternehmens. Wir arbeiten jetzt seit einem Jahr mit Scrum, haben ein Projekt erfolgreich abgeschlossen und noch immer gibt es viele Ideen wie der Prozess verbessert werden kann.