Good leaders make people feel that they’re at the very heart of things, not at the periphery.Warren Bennis
Good Leaders
G
Don’t put people to projects
D
Ein in der Projektmanagement-Literatur verbreiteter Hinweis ist: „Don’t put people to late projects.“ Das heißt so viel wie: Wenn zum Ende eines Projekts auffällt, dass die Zeit zu knapp ist für den eigentlich noch umzusetzenden Umfang, dann bringt es in der Regel nichts, kurzfristig noch andere Personen in das Team zu stecken.
(mehr …)Experte oder nicht Experte, das ist hier die Frage
E
Wenn ich ein Projekt bewältigen muss, dann versuche ich möglichst viele geeignete Experten in ein Team zu bekommen, denn nur eine ausreichende Anzahl von Experten kann ein erfolgreiches Projekt sicherstellen. Lieber arbeite ich mit (noch) mehr Spezialisten, die mir zu 75% oder 50% oder nur 25% ihrer Zeit zur Verfügung stehen, als auf diese Spezialisten zu verzichten oder ich verschiebe das Projekt, bis mir ausreichend Spezialisten wenigstens anteilig zur Verfügung stehen, oder?
(mehr …)Money for nothing, change for free
M
Ziel jeder Softwareentwicklung ist das Entstehen eines gewissen Werts. Niemand – vor allem keine Unternehmen – entwickeln Software zum Spaß (es sei denn Spaß an der Entwicklung ist der ausgesprochene Wert). Auch in einem typischen Auftraggeber Dienstleister Verhältnis geht es darum, für beide Seiten Wert zu erzeugen.
(mehr …)Scrum funktioniert immer
S
In einem Vortrag zu Scrum in Festpreisprojekten hieß es mal plakativ, es gäbe im Hinblick auf Scrum eine gute und eine schlechte Nachricht. Die Gute: Scrum funktioniere immer. Die Schlechte: Projekte können dennoch scheitern. Auch wenn ich “Scrum funktioniert immer” zumindest so relativieren will, dass die erfolgreiche Einführung der Regeln von Scrum auch etwas zu tun hat mit Durchhaltevermögen und Konsequenz, macht es dennoch deutlich, was Scrum ist und was nicht. Scrum ist ein Framework um einen Entwicklungsprozess zu strukturieren und keine reine Projektmanagement-Methode.
(mehr …)Projektleiter geteilt durch drei
P
Die Verantwortlichkeiten eines klassischen Projektleiters sind umfangreich, manchmal vielleicht zu umfangreich, als dass ihnen eine Person allen gleich gut gerecht werden kann. An manchen Stellen entstehen aus den vielen Verantwortlichkeiten sogar konkurrierende Aufgaben. Scrum fängt das ab, indem die Verantwortlichkeiten des Projektmanagers auf die drei Rollen aufgeteilt werden.
(mehr …)Product Owner in Kanban?
P
In seinem Blog “Lean und Kanban” stellt sich Autor Arne Roock die Frage, ob wir in Kanban einen Product Owner brauchen. Da Kanban weder ein Entwicklungsprozess noch eine Projektmanagement-Methode ist, gibt es auch keine klar definierten Rollen – diese Rollen gibt es eventuell durch den bestehenden Prozess oder die bestehende Organisationsstruktur. Allerdings deckt Kanban schnell auf, wenn Rollen mit ihren Verantwortlichkeiten gebraucht werden.
Das Fazit aus seinem Artikel: Kanban schreibt keine Rollen vor, sinnvoll wäre es aber sowohl in der Produktentwicklung, als auch in Service-Agenturen eine Rolle mit den typischen Aufgaben eines (Scrum) Product Owners zu haben, der unter anderem
- Anforderungen von verschiedenen Seiten einsammelt und priorisiert;
- Mit den Stakeholdern in Kontakt bleibt, ihre Bedürfnisse abfragt und sie auf dem Laufenden hält;
- Das Realisierungsteam abschirmt;
- Zusammen mit dem Team eine möglichst klare Produktvision erstellt;
- Dafür sorgt, dass möglichst häufig neue Produktinkremente erstellt werden, zu denen Kunden und andere Stakeholder ihr Feedback geben können. Das wiederum hat bestimmte Auswirkungen auf den Zuschnitt von Anforderungen.
Hier kann man den ganzen Artikel “Brauchen wir in Kanban einen Productowner” (Arne Roock) lesen.
