Weiterhin Verbesserungspotential bei Zusammenarbeit zwischen Linienführungskräften und Projektleitung

Stefan Hagen führt immer wieder sogenannte “Blitzungfragen” durch. Das Ergebnis zur Fragen “Wie bewerten Sie das Verhalten der Linien-Führungskräften bei Projekten in Ihrem Unternehmen?” ist für Projektleiter relativ ernüchternd und das Ergebnis kann ich leider aus eigener Erfahrung bestätigen.

Es ist nicht wirklich überraschend, dass lediglich ca. 19 % der Befragten das Verhalten der Führungskräfte in ihrem Unternehmen im Zusammenhang mit Projektmanagement als gut oder sehr gut einschätzen. In der überwiegenden Anzahl der Unternehmen wird das Verhalten als “mittelmäßig” eingeschätzt bzw. es sind große Unterschiede im Führungsverhalten vorhanden. In meines Erachtens alarmierenden 34 % der Fälle scheint das Management den Erfolg von Projekten jedoch durch sein Verhalten unmittelbar zu gefährden und negativ zu beeinflussen.

Quelle: http://pm-blog.com/2010/04/29/verhalten-der-linienfuhrungskrafte/

Mehr Details, Erläuterungen und Verbesserungsvorschläge gibt es in seinem Artikel.

Treffen der Scrum User Group Karlsruhe 7. April

Morgen (Mittwoch, 7. April) trifft sich die Scrum User Group Karlsruhe wieder einmal im Restaurant Großer Kurfürst (Sophienstraße 80, 76135 Karlsruhe). Wie immer beginnt der “offizielle Teil” um ca. 20:00 Uhr, erste Teilnehmer dürften ab ca. 19:30 Uhr fleißig Schnitzel bestellen und über Scrum reden.

Der Termin – obwohl schon länger bekannt – ist wohl etwas in Vergessenheit geraten, erst Heute wurde der entsprechende Xing-Termin angelegt wo man sich auch schön registrieren kann. Wer will kann aber auch einfach vorbeischauen.

Das Thema diesmal: “Scrum in unseren Unternehmen”.

Projekt oder nicht Projekt?

Jeder, der Projektleiter für die Anlaufstelle für alles (unangenehme, störende) sieht, sollte sich den Artikel von Stefan Hagen und die sehr interessanten Kommentare durchlesen.

Projektleitung sollten sich auf Projekte konzentrieren und die Linie die Finger von Projekten (“nebenher”) lassen sondern die normalen Abläufe optimieren.

Die Übergabe eines Projektes nach Abschluss der Errichtungsphase an eine Linienorganisation ist häufig ein (ungelöstes) Problem. Wenn dies jedoch nicht gelingt, werden die Projektleiter zunehmend mit Routineaufgaben aus der Wartungsphase beschäftigt sein und die Organisation letztendlich keine Projekte mehr erfolgreich durchführen können.

ABER: Auch Projektarten, die in Unternehmen regelmäßig durchgeführt werden, können niemals vollständig standardisiert werden, da sie IMMER auch neuartige Elemente enthalten. Ist dies nicht der Fall, handelt es sich nicht um Projekte, sondern um standardisierbare (Geschäfts)Prozesse.

Wann ist ein Projekt ein Projekt?

Die dunkle Seite von Scrum

Ich glaube, dass Scrum als moderner iterativ-inkrementeller Softwareentwicklungsansatz der auf Werten beruht ein großes Potential für langfristige Produktivitätssteigerungen besitzt.

Aber “reines” Scrum funktioniert nicht überall. Und “reines” Scrum hat – wie andere “reine Lehren” auch – viele “dunkle” Seiten.

Selbst Evangelisten wie Ken Schwaber gehen auf Probleme bei Einführung von Scrum in Unternehmen ein. Einige der Punkte aus “The Enterprise and Scrum” von Ken möchte ich aus einer eher skeptischen Perspektive kommentieren.

Aus Part I, “Adopting Scrum”:

Staff turnover will occur

Ja, manche Personen möchten nicht mehr Verantwortung und mehr Freiheit. Manche Angestellten arbeiten, um Geld zu verdienen – nicht weil es sich um ihre Berufung handelt. Zugrunde liegt ein Vertragsverhältnis und ein Vertrauensverhältnis. Die Organisation möchte dies nun einseitig ändern. Widerstand wird die Folge sein, Kosten entstehen, Veränderung verlangsamt sich.

Conflict will occurimage

Veränderungen führen zu Konflikten. Sind alle darauf vorbereitet mit Konflikten richtig umzugehen? Hat die Organisation Antworten auf die Fragen die in den Gesprächen gestellt werden? Hat die Organisation die Kraft die Konflikte zu lösen? Meine Erfahrungen hier sind ernüchternd. Mir ist keine ältere Organisation bekannt, die gut mit Konflikten umgehen kann. Unternehmenspolitik spielt hierbei eine wichtige Rolle. Möchte man dies überwinden, so kostet dies Geld und Zeit. Oft müssen auch Personen im mittleren und höheren  Management ausgetauscht werden.

Product management’s job will change and will be harder

Klar, Scrum verschiebt die wirklich komplexen Entscheidungen dorthin, wo sie hingehören: Zum Management. Die wichtigsten Fragen sind: WAS will ich tun – und vor allem was will ich NICHT tun?

Dafür, dass diese Fragestellungen von zentraler Bedeutung sind, wird die Rolle des PO meiner Meinung nach zu wenig beachtet. Der gestiegenen Verantwortung steht im Allgemeinen leider keine gestiegene Entlohnung gegenüber. Im Grunde ein Verlustgeschäft für die betroffenen Manager – zumindest wenn man nur die finanziellen Aspekte betrachtet und eine mögliche gestiegene Motivation durch schnellere Ergebnisse vernachlässigt.

Meiner Erfahrung nach ist es aber auch häufig so, dass aus verwaltenden Produktmanager einfach verwaltende ProductOwner gemacht werden. Zu häufig ist der PO eben nicht er “Gold Owner” und damit geht viel Einflussmöglichkeit dieser Rolle verloren.

Engineering is accountable for quality

Eine Frage, die ich mir immer wieder stelle: Woher wissen die Techniker, was Qualität ist? Qualität muss im Kontext betrachtet werden. Eine Entwicklung für eine Messepräsentation muss nicht unbedingt wartbar oder performant sein. Für eine Software, die der Grundstein für ein Produkt ist, ist dies jedoch sehr wichtig. Zu oft erlebe ich in der Praxis, dass hier immer mit einem Maß gemessen wird. Technik ist nicht Business, Business soll aber die Richtung (“was”) vorgeben. Wenn Technik dann nur eine Art von Qualität liefern kann, dann ist dies zu teuer und es wird kein Geschäftswert generiert.

Compensation policies need to change

Damit wird Scrum zur Restrukturierungsmaßnahme im großen Stil. Viel Spaß mit dem Widerstand, auf den man treffen wird. Betriebsrat? Gewerkschaft? Sind die Manager wirklich so gut, diese Veränderungen an die Belegschaft zu verkaufen?

Jobs will change

Für Deutschland eine spannende Sache. Veränderung der Stellenbeschreibung bei Festangestellten. Vielleicht wollen diese ihre alte Position behalten und klagen dagegen? Nicht jeder ist mit den Veränderungen einverstanden. Mit Widerstand ist zu rechnen – wiederum muss mit Kosten und Verzögerungen gerechnet werden.

Management’s primary responsibility will shift from command to servant leadership

Das Management wird reduziert auf die Beseitigung von Hindernissen. Hier wird stets davon ausgegangen, dass Selbstorganisation funktioniert. Ich bezweifle dies. Leider sprechen meine Erfahrungen dagegen. Die meisten Teams, die ich kenne, denken zu technisch und zu sicherheitsorientiert. Zu langsam und damit unbezahlbar. Der Grund? Meist Überforderung in Form von Multi-Projekt-Abarbeitung und dauernde Veränderung des Fokus. Ja, ein Management-Problem. Ihr könnt aber sicher sein, dass das Management dies gerne lösen würde – aber nicht kann. Superheld Produktmanager (PO) scheitert an der Realität. Wer hätte das erwartet?

Trotz Selbstorganisation wird im Allgemeinen auch nur der Manager an die Wand gestellt. Single wrinkable neck eben.

Management turnover will occur

Für viele Manager ist der Deal mies: Mehr Verantwortung, mehr Stress und Druck. Weniger Einflussmöglichkeiten. Immer noch im Schussfeld, wenn es Probleme gibt – während die Entwicklung ziemlich geschützt ist. Naja, da kann man verstehen, dass der eine oder andere Manager eine Position vorzieht, in denen er mehr bewegen kann.

Fazit

Aus meiner Sicht sieht das Fazit so aus:

Mit Scrum werden die Defizite einer Organisation deutlich. Jede Organisation hat Defizite und Probleme. Was tun? Ken warnt davor, Scrum anzupassen – da dann die Probleme nicht beseitigt werden. Verständlich – aber auch realistisch? Vielleicht. Wenn man in der Lage ist die Kosten einer Einführung von Scrum (as from the book) zu bezahlen. Falls dies nicht der Fall ist, muss mit Kompromissen gearbeitet werden.

Sorry, wollte euch nicht den Tag vermiesen ;-)

Sequenzdiagramme im Netz – Beispiel Angebotsprozess

Sequenzdiagramme sind hilfreich, um Abläufe und daran beteiligte Akteure zu visualisieren. Als Teil der UML werden Sequenzdiagramme von diversen Modellierungswerkzeugen unterstützt.

Vor einiger Zeit bin ich auf einen netten Dienst im Internet gestoßen: WebSequenceDiagrams.com. Aus einer einfachen textuellen Beschreibung werden Sequenzdiagramme erstellt.

Beispiel: Angebotsprozess in Unternehmen

Der Angebotsprozess in den meisten Unternehmen lässt sich ebenfalls in einem Sequenzdiagramm visualisieren. An dieser Stelle geht mein Dank an Andreas L., der meine rudimentäre Skizze des Prozesses in eine umfassende und universell gültige Beschreibung des Angebotsprozesses überführt hat. Andreas, wolltest Du nicht schon länger den einen oder anderen Artikel schreiben? Dann könnte das Niveau dieses Blogs endlich wieder steigen! ;-)

Here we go:

Kunde->Vertrieb:Anfrage
Vertrieb->Projektmanagement:Abschaetzung
Projektmanagement->Entwicklung:Abschaetzung
Entwicklung->Projektmanagement:Keine Zeit
Projektmanagement->Vertrieb:Keine Zeit
Vertrieb->Projektmanagement:Abschaetzung jetzt!
Projektmanagement->Entwicklung:Abschaetzung jetzt!
Entwicklung->Projektmanagement:Abschaetzung geraten
Projektmanagement->Vertrieb:Abschaetzung geraten
Vertrieb->Projektmanagement:Zu Teuer
Entwicklung->Projektmanagement:Keine Leute
Qualitaets-\nmanagement->Projektmanagement:Zu Schlecht
Senior\nManagement->Projektmanagement:Alles ganz einfach
Projektmanagement->Vertrieb:Funktioniert so nicht
Vertrieb->Projektmanagement:Ist strategisch!
Projektmanagement->Vertrieb:Na dann!
Vertrieb->Vertrieb:Kaffeesatz
Vertrieb->Kunde:Kein Problem!

 

Das Ergebnis ist ein Sequenzdiagramm, hier im Stil “napkin” gehalten:

image

Prophet im eigenen Lande …

Es gibt doch das Sprichwort, dass der Prophet im eigen Land nicht viel gilt. Irgendwie fühle ich mich so, nachdem ich die Excel-Tabelle von Jeff Sutherland gesehen habe.

Ein ähnliches Planungswerkzeug habe ich zusammen mit ein paar anderen POs vor fast zwei  Jahren bei unseren Teams eingeführt und im Allgemeinen sehr gute Erfahrungen damit gemacht. Unser Werkzeug war nicht ganz so detailliert, hat aber stets seine Aufgaben erfüllt.

Leider konnte es sich auf Grund erheblichen Widerstands von “Traditionalisten” (und einiger externer Berater) nicht durchsetzen. Naja, vielleicht lernen sie nun von Jeff, dass Excel nicht böse sein muss, und dass eine genauere Betrachtungsweise der Teamzusammensetzung in der Vergangenheit ein relevanter Parameter für die zukünftige Velocity sein kann.

Sweden-Nordic-Museum-King

Urlaub? Warum soll ich Urlaub berücksichtigen – wir mitteln einfach über das ganze Jahr!

Wunderbar, wenn es fixe externe Termine gibt und man frühzeitig wissen muss, ob diese eingehalten werden können.

Alle weiteren Kommentare verkneife ich mir jetzt.

New book from Kniberg: Kanban and Scrum – making the most of both

Falls ihr es (wie ich) übersehen habt, dann für alle der “late majority” der Hinweis, dass Henrik Kniberg zusammen mit Mattias Skarin ein neues Buch veröffentlich hat.

Nach seinem fantastischen “Scrum and XP from the Trenches” und seiner Scrum Checklist (vgl. auch ArmerKater) sicherlich ein lesenswertes Buch. Mal sehen, wann ich dazu komme.

Bei InfoQ gibt es Informationen zum Buch und ein Link zum PDF Download.

In gedruckter Form natürlich auch bei Amazon:

PS: Freue mich natürlich über Kommentare zum Buch, falls ihr es schon gelesen habt!

Termin: Roundtable (FZI) Forschungszentrum-Informatik Karlsruhe "Near-/Offshore"

Ein weiterer Termin in Karsruhe zum Themengebiet um Near- und Offshore. Diesmal wird auch auf eine agile Projektdurchführung eingegangen.

03.02.2010, 18:30-20:30 Uhr, Schlosshotel Karlsruhe, Bahnhofplatz 2 , 76137, Karlsruhe, Germany

  • Dr. Nagi (POET Egypt) wird einen Vortrag halten zu: “Nearshore-Entwicklung und -Services mit agilen Methoden”
  • Dr. Mevius & Herr Stephan (FZI, Mitglied im Team ZIKS (http://www.ziks.de/)):
    “Projekterfahrungen mit internationalen, kollaborativen Softwareprojekten”
  • Ashant Chalasani, Vertreter des Indo-German Software Competence Network (http://indescon.org): “Kooperation zwischen indischen und deutschen Firmen in der IT-Branche: Nicht nur ein Einwegmodell!”

Interessenten können sich via XING registrieren:

Termine: Indescon X-Table Dinner in Karlsruhe & Scrum User Group Karlsruhe

Demnächst gibt es wieder ein paar interessante Termine in Karlsruhe.

Here we go:

29.01.2010, 18:00-20:00 Uhr: Indescon X-Table Dinner in Karlsruhe

Restaurant Punjab, Amalienstraße 46, 76133, Karlsruhe

Treffen der indisch-deutschen IT-Community. Ziel ist es, dass Kontakte zwischen regionalen Softwareeunternehmen, Indescon-Mitgliedern und indischen IT-Experten geknüpft werden.

Termin bei Xing: https://www.xing.com/events/indescon-table-dinner-karlsruhe-439618

 

03.02.2010, 20:00–22:00 Uhr: Scrum User Group Karlsruhe

Großer Kurfürst, Sophienstraße 80, 76135 Karlsruhe

Thema diesmal: “Konflikte im agile Umfeld und wie geht ihr damit um?”

Termin bei Xing: https://www.xing.com/events/scrum-user-group-karlsruhe-453234