KANBAN hat eine Retrospektive!

Wie jeden Tag habe ich auch heute wieder etwas dazu gelernt.
Henning Wolf und Arne Rook von it-agile haben heute bei der GPM Regionalgruppe eine Einführung in KANBAN und Scrum gegeben.
Und was musste ich da hören? KANBAN hat eine Retrospektive! Verdammt, das hab ich echt vergessen bei der Einführung bei der ABIAN.
Eigentlich aber logisch, schließlich ist das Kaizen ein Kern der Lean Philosophie.
Das hole ich jetzt natürlich schnell mal nach 😉
Und wenn ich so ein bisschen drüber nachdenke dann merke ich, dass diese Retrospektive bei den Teams schon von alleine begonnen hat, ich sollte bloß mal mitmachen.
Was mich wiederum freut, denn es zeigt doch, dass die Jungs schon „Lean“ leben.
Zur eigenen Erinnerung nochmal die vier Grundprinzipien von KANBAN:
– Visualisierung
– Limitierung (WIP)
– Pull Prinzip
– Kaizen

Werbung

Wie überzeuge ich meinen Kunden von Scrum?

Eine Frage, die wir im Februar auf dem it-Camp von oose diskutiert haben, will mir nicht aus dem Kopf: wie bringe ich denn meinen Kunden dazu, das Experiment Scrum zu wagen?

Klar, ich kann ihn mit Argumenten und Literatur überschütten. Und das Killerargument Nummer 1: die Anderen machen das ja auch.

Aber mal eine andere Idee: Warum denn nicht mal auf Belohnung für den Kunden setzen?

Meine Idee: Wir machen zunächst eine klassische Projektkalkulation. So wie wir sie brauchen, um ein Projektangebot zu erstellen. Und dann bieten wir dem Kunden an, dass wir das Projekt agil durchführen wollen und wir uns die eingesparten Kosten mit ihm teilen.

Das wär doch mal was, oder?

Dat wusste ich nich….

Weder kannte ich Fritz B. Simon noch die systemische Organisationstheorie mit der er sich beschäftigt. Diese Wissenslücke durfte ich heute füllen – und es hat sich gelohnt. Auf dem oose it-camp in Hamburg hat Fritz B. Simon einen sog. „Impulsvortrag“ gehalten, um die Teilnehmer auf den Rest des Tages einzustimmen. Das ist, zumindest bei mir, voll gelungen.

Kanban in der IT (Part 1 – Systemhaus)

Seit zwei Monaten kann ich erste praktische Erfahrungen im Einsatz von KANBAN Prinzipien in der IT sammeln. Sowohl in der Softwareentwicklung als auch im klassischen Systemhausbereich der Firma ABIAN GmbH in Hannover habe ich ein KANBAN Board eingeführt.

Experiment SCRUM

Jetzt sind wir drin im ersten SCRUM Projekt. Ich werde hier unregelmäßig meine Erfahrungen mitteilen.
Die ersten Erfahrungen mit Scrum zeigen mir folgendes:
1. Die Entwickler sind wirklich motiviert. Das macht Spaß!
2. Wir alle müssen uns an die Disziplin und das Timeboxing in SCRUM gewöhnen. Von wegen AGIL=alles ist frei 😉
3. Vieles aus dem guten alten IPMA Kurs findet man wieder – heißt halt nur anders. Ist ja schließlich das „hippe“ Scrum.
4. Als Product Owner muss ich ja noch mehr mit dem Kunden sprechen als vorher als Key Accounter. Uff.
5. Whiteboards kann man nie groß genug planen.
6. Ralf Wirdemanns Buch „Scrum mit User Stories“ liefert uns jede Menge Input und auch Diskussionsstoff. Leider fällt mein Exemplar schon fast auseinander. Gut dass es das ebook dazu gibt.
7. User Stories sind wirklich ein gutes Mittel um die Anforderungen zu abstrahieren und der Kunde besteht es tatsächlich.

Die alten Scrum Hasen werden jetzt sicher grinsen – aber allen anderen kam ich nur Mut machen es zu probieren.

Agil nach innen – klassisch nach außen?

Habe heute einen interessanten Artikel zum Thema Agile Entwicklung vs. V-Modell XT gelesen. Interessant deshalb, weil ich mir gut vorstellen kann, so das immer wieder auftretende Problem zu lösen: Wie sag ichs meinem Kunden?
Immer wieder stehe ich vor dem Problem, dass meine Kunden nur den klassischen Weg kennen und ihn auch nur ungern verlassen wollen. Sie wollen zur eigenen Absicherung ein Pflichtenheft, einen Projektplan, ein Angebot mit einem konkreten Projektpreis.
Und all das passt ja dann doch nicht so ganz zu SCRUM als agilem Vorgehensmodell. Klar: ich habe mein Backlog, ich habe Releases, aber ich habe keine angeblich „verlässliche“ Featureliste für die Leistungsebene. Ich habe auch keinen Preis für die definierten Inhalte des Pflichtenheftes sondern nur ein Budget, welches meiner Zeit und Ressourcenplanung für die Sprints entspricht.
Da klingt der Vorschlag, die beiden Weten miteinander zu verbinden, verführerisch.
Mal sehen, ob ich eine Projekt mal so angehe.