Regel vier: Es braucht Zeit. Es braucht Fehler. Es ist nie zu Ende.
Mit meinen Kunden diskutiere ich immer wieder Timelines, Deadlines und Timing Charts - also die Festlegungen, wann etwas fertig sein soll. Immer wieder trete ich dabei für mehr Zeit ein. Mehr Zeit für Mitarbeiter, mehr Zeit für Entwicklungen, mehr Zeit für Prozesse. Wer in einem großen Konzern mit jahrelang gewachsenen hierarchischen Strukturen Agilität in vier Wochen einführen möchte, hat meiner Meinung nach eine falsche Vorstellung davon, was Agilität schaffen kann.
Deutlich mache ich das am Beispiel Sicherheit: Für mehr Sicherheit warten wir gerne länger am Flughafen, aber für bessere Qualität planen wir - vielleicht abgesehen von der Weinreife - ungern mehr Zeit ein. Dabei bringt ein qualitativ hochwertiges Produkt viel mehr Erfolg und Gewinn als ein schnelles, schlecht gemachtes Produkt, egal, ob es sich um ein Auto oder eine Software handelt.
Zeit kann man nicht kaufen, deshalb ist sie auch in Projekten von unschätzbarem Wert. Besser als eine Pufferplanung finde ich eine ehrliche Kommunikation über den verfügbaren und den nötigen Zeitrahmen. Diese Entscheidung ist individuell und von vielen Faktoren abhängig. Auch wenn es dafür keine Faustformel gibt, sollte man auf jeden Fall darüber sprechen.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Regel drei: Projektmanager müssen wissen, was Entwickler tun | Regel fünf: Mentalität, Kultur und Überzeugungen müssen sich grundlegend ändern |
Das funktioniert in der Entwicklung von Webanwendungen, wo SCRUM bekanntlich herkommt...
Manager können gar keine guten Kundenbeziehungen machen. Der Kontakt mit dem Kunden...
Wie Du selbst schreibt: "hat sich schon einiges (...) und der Kultur geändert" Ja die...
Sehe oft das Problem im SCRUM Teams dass es heisst "das Team organisiert sich selbst...
Hallo Maconry, Danke für den Kommentar zum Artikel. Im speziellen Fall war es eine Lösung...