Sonntag, September 30, 2007

Ideenfluss

Bei der Veranstaltung zum Lean-Management in der Nordakademie ist mir nochwas aufgefallen: Ideen nehmen manchmal merkwürdige Wege. Wir Softwareentwickler haben mit der ganzen agilen Softwareentwicklung die Prinzipien von Lean Production, Lean Product Development und Lean Management aus dem produzierenden Gewerbe (vor allem: Toyota) genommen und auf IT übertragen.
Jetzt kommt anderes produzierendes Gewerbe an und sagt: "Die ITler sind ja immer ganz vorne mit dabei. Die machen Scrum. Wie können wir das bloß auf unsere Probleme übertragen?"
Dabei müssten sie doch nur gucken, was Toyota macht. Das sollte sich sich deutlich einfacher übertragen lassen. Aber vielleicht ist das zu langweilig?

Post bewerten

Agil: Wann was bewerten?

Vor kurzem habe ich zusammen mit meinem Kollegen Henning Wolf einen Workshop bei der Nordakademie zum Thema Lean Management und Scrum mitgestaltet. Für uns war es eine besondere Erfahrung, weil unter den Teilnehmern so gut wie niemand war, der Software entwickelt. Ca. die Hälfte der Teilnehmer beauftragt die Entwicklung oder Einführung von Software, die andere Hälfte entwickelt physikalische Dinge wie Züge, Tablettenpressmaschinen oder Gabelstapler - individuell oder in Serie.
In diesem Sinne hatten wir interessante Diskussionen, die sich vor allem um die Frage drehte, wie man mit den Scrum-Sprints umgehen soll: Bei der Entwicklung eines Zuges hat man erst sehr spät den Zug und kann den nicht bereits am Anfang dem Kunden zeigen. Außerdem stand die Frage im Raum, wie man vom klassischen Vorgehen schrittweise in Richtung Scrum kommt. Dabei hat sich herauskristallisiert, dass es drei zusammenhängende Aspekte gibt, die man gemeinsam in Richtung Scrum entwickeln muss:
  1. Was wird präsentiert?

  2. Wem wird es präsentiert?

  3. Wann wird es präsentiert?

Klassisch hat man einen Projektplan mit Meilensteinen. Bezogen auf die o.g. Fragen gilt für das klassische Projektvorgehen:
  1. Was wird präsentiert? Immer unterschiedlich, je nach Meilenstein. Mal eine Konzeption, mal ein physikalisches Teil.

  2. Wem wird es präsentiert? Manchmal dem Kunden. Häufig gibt es aber gar keinen richtigen Kunden für das, was das präsentiert wird. Es sind nur interne Dokumente.

  3. Wann wird es präsentiert? In unregelmäßigen Abständen, jeweils wenn ein Artefakt fertig ist. Wenn es zum geplanten Zeitpunkt nicht fertig ist, wird der Termin häufig verschoben.

Scrum hingegen fordert:
  1. Was wird präsentiert? Das, was der Kunde später auch bekommt, wofür er bezahlt.

  2. Wem wird es präsentiert? Dem Kunden. Wenn es ein Serienprodukt für viele (vielleicht anonyme) Kunden ist, übernimmt ein Kundenvertreter (Produktverantwortlicher) die Kundenrolle.

  3. Wann wird präsentiert? In der Regel alle 2 bis 4 Wochen, aber auf jeden Fall in regelmäßigen Abständen (Timeboxing).

Wie kommt man jetzt von Meilensteinen zu Scrum? Der erste Schritt ist einfach: Man macht Punkt drei genauso wie Scrum es fordert: Man definiert einen festen Rythmus, in dem man den Projektfortschritt bewertet und ggf. die Pläne anpasst. Seine Meilensteine kann man erstmal parallel dazu bestehen lassen. Es ist jedoch das Ziel, die Meilensteine komplett zu ersetzen.
Und jetzt muss man sich für die Punkte eins und zwei schrittweise an Scrum annähern. Derjenige, dem präsentiert wird, muss dem Kunden immer ähnlicher werden und das, was präsentiert wird, muss dem immer ähnlicher werden, wofür der Kunde bezahlt.
Das wird im ersten Schritt häufig bedeuten, dass man intern einen Kundenvertreter benennt, der den Kunden vertritt - selbst dann, wenn es einen echten Kunden gibt. Wenn sich mit dem Kundenvertreter das Vorgehen intern eingespielt hat, lädt man den Kunden zu den Präsentationen mit ein. Und schließlich kommt der interne Kundenvertreter nicht mehr. im gleichen Zuge wie der interne Kundenvertreter durch den echten Kunden ersetzt wird, muss sich das Artefakt ändern, das präsentiert wird. Schließlich muss der Kunde auch bewerten können, was er präsentiert bekommt. Und hier ist es natürlich auch bei der Entwicklung physikalischer Dinge so, dass man sie in Einzelkomponenten zerlegen kann. Und diese Einzelkomponenten werden weitgehend unabhängig voneinander entwickelt und getestet. Einige Einzelkomponenten können also auch bereits lange vor Ende des Projektes präsentiert werden. Und dort wo es nicht geht, muss man Dinge finden, die der Kunde versteht: Prototypen, Konzepte und Präsentationen in der Sprache des Kunden etc.

Fazit 1: So anders ist die Entwicklung physikalischer Dinge auch wieder nicht.
Fazit 2: Das skizzierte Vorgehen funktioniert genauso gut für Softwareprojekte, die den Sprung ins kalte Scrum-Wasser scheuen und sich lieber schrittweise vorarbeiten wollen.

Post bewerten

Freitag, September 21, 2007

Power-Point bei Google

Neben einem Word- und einem Excel-Ersatz gibt es bei Google Docs jetzt auch ein Programm für Präsentationen. Von Power-Point-Ersatz kann bisher aber leider nicht die Rede sein. Man kann lediglich ein paar Texte und Listen anordnen. Das ging mit dem Word-Ersatz eigentlich auch schon ganz gut. Es fehlen die Möglichkeiten für Grafiken.

Von den Features her ist Zoho Show da deutlich weiter.

Post bewerten