Eben erst hatte ich Zeit mir die neue  iX anzusehen und mir spring sofort der Artikel auf Seite 110 in die Augen. Ein Beitrag über agile Softwareentwicklung speziell mit Scrum – insgesamt lesenswert. Was mir aber besonders gefallen hat, ist die Liste der Scrum-Anti-Patterns:

1. Der Scrum Master weist Aufgaben zu und zerstört so das sich selbst steuernde und organisierende Team.
2. Der Sprint wird von außen gestört. Es werden neue Aufgaben eingefügt oder Änderungen an den gewählten User Stories vorgenommen.
3. Es finden keine Review Meetings statt.
4. Es findet keine Retrospektive statt.
5. Es gibt keine regelmäßigen Daily Standup Meetings.
6. Der Product Owner hat keine ausreichende Kompetenz und nimmt seine Rolle nicht wahr.
7. Es gibt kein „1 to 1 Agreement“, also keine persönliche Vereinbarung zwischen dem Product Owner und dem Team.
8. Die Beteiligten sind nicht ausreichend geschult.
9. Meetings sind nicht Timeboxed.
10. Anstatt Features werden Aktivitäten erfasst.
11. Man schickt ein paar Scrum Master zum Training und denkt, nun werde alles gut.

Diese Liste ist bei weitem noch nicht vollständig. Mir fallen da spontan noch ein paar Ding wie „Bug-fix Sprints“ oder die aktive Beteiligung des Management am Daily Scrum ein.

Fallen Ihnen vielleicht noch ein paar schöne Scrum-Anti-Patterns ein? Ich bin gespannt.

(Bildquelle: Stock Exchange, johnmckeag)

Mein Blog-Kollege Jan Poczynek hat eine interessante Präsentation zum Management des Projektmanagements erstellt. Er beschäftigt sich mit dem Spannungsfeld, das Projekte innerhalb von Stammorganisationen erzeugen und welche Maßnahmen ergriffen werden können die Integration zu verbessern.

Aber seht selbst:

Einen Vertiefung ist mit dem ausführlichen Artikel möglich.

Es gibt derzeit ja viele Doku-Soaps im deutschen Fernsehen. Zwischen den ganzen weniger brauchbaren Sendungen finde ich eine dennoch erwähnenswert,  “Rach, der Restauranttester”.  Diese Sendung ist wunderbar geeignet für Projektmanger oder Berater, da  die Konzepte sich sehr gut auf die IT-Projekte übertragen lassen. Vielleicht sollte ich damit anfangen, was Christian Rach überhaupt macht:
Er besucht pro Folge ein Restaurant, das kurz vor der Pleite steht. Seine Aufgabe ist es, das Lokal vor dem Ruin zu retten. Dazu testet er die Küche, den Service und die Führung der Gastronomie.

Das ist alles!

Genau das machen viele Berater aber auch. Sie zeigen auf, dass die Kommunikation unter den Abteilungen schlecht ist,  keine klare Aufgabenverteilung besteht und dass bestimmte Bereiche zusammengelegt werden sollen – in Form von Kompetenzzentren.  So, oder so ähnlich werden die Vorschläge wohl lauten.  Allerdings macht es Rach etwas anders. Er adaptiert nicht ein Schema F auf alle Restaurants, sondern jeder muss sich selbst treu bleiben.

Aber was kann man davon auf IT-Projekte übertragen?

Zuerst die Vorgehensweise:

1. Probleme offen ansprechen
   Wird von vielen Beratern häufig nicht gemacht. Die Gründe dafür sind unterschiedlich. Einerseits könnte man dadurch Folgeaufträge zunichte machen, andererseits kann es klare Vorgaben durch das Management geben, eine bestimmte Meinung zu propagieren.
2. Eigeninitiative verlangen
   Genau das sollte jeder Projektmanager oder Berater von seinem Team oder Kunden verlangen. Es geht nicht darum, einen Alleingang hinzulegen, sondern Teamarbeit ist das Stichwort.
3. Beteiligte mit einbeziehen
   Ist kein Geheimnis, wird in der Praxis aber dennoch selten umgesetzt. Die Beteiligeten haben sich in der Regel bereits mit dem Thema auseinander gesetzt und können guten Input liefern.
4. Sich selbst treu bleiben
   Hier trennt sich die Spreu vom Weizen. Während viele versuchen ihre Methoden, Werkzeuge und bekannte Software in allen Projekten anzuwenden, schaffen es andere die Eigenarten des Projekts und die Besonderheiten des Kunden zu berücksichtigen.
5. Klare Aufgeben verteilen
   Nur Mitarbeiter, die wissen was sie zu tun haben, können sich auf die Arbeit konzentrieren und kommen sich nicht gegenseitig ins Gehege.
6. Mitarbeiter motivieren
   Wenn die vorherigen Punkte umgesetzt werden, schafft das Anreize, damit sich die Mitarbeiter auch motivieren. Getreu dem Amerikanischen Sprichwort:

Tell me and I´ll forget;
show me and I may remember;
involve me and I´ll understand.

Genau an diese Punkte hält sich Christian Rach, wenn er ein Restaurant unter die Lupe nimmt. Nach einer Analyse, spricht er die Probleme offen an – und das mehr als deutlich. Er bezieht von Anfang an die Beteiligten mit ein und verlangt ihnen eigene Ideen zur Problemlösung ab. Dabei versucht er nicht einem traditionellen Wirtshaus eine System-Gastronomie aufzudrücken. Während der Umsetzung findet Rach immer wieder Worte des Lobs, um die Mitarbeiter zu motivieren (sofern diese es verdient haben).
Viele dieser Punkte werden von Projektmanagern und IT-Beratern bereits so umgesetzt, lediglich der vierte Punkt ist mir ein Dorn im Auge. Diesem Punkt wird leider nicht genug Beachtung geschenkt. Das zeigt die zunehmende Verbreitung von Standardsoftware auch in den Bereichen, in denen bisher aufgrund der speziellen Besonderheiten individuell entwickelt wurde.

Wikis sind derzeit in aller Munde.  Die Unternehmen experimentieren mit diesen einfachen Tools, um das vorhandene Wissen zu bündeln.  Auch ich habe bereits eine Wiki-Plattform eingeführt und wenn man nach der vermeintlich besten Strategie zur Einführung sucht, wird man schnell fündig. Zu nennen einerseits der Blog von //SEIBERT/MEDIA oder vielleicht ein Beitrag in der Computerwoche zur Einführung eines Wikis.
Vorerst meine Meinung. Ich denke nicht, dass jede Abteilung oder Firma geeignet ist ein Wiki zu nutzen, da es doch sehr stark die vorhandenen Denk- und Arbeitsweisen in Frage stellt.  Häufig sind auch die kreativen Freiräume, die ein Wiki gewährt, vom Management nicht gewünscht. Daher muss dies bereits in der Vorplanung mit berücksichtigt werden.  Darüberhinaus gibt es zwei Arten der Wiki-Einführung.

1. Als schleichender Prozess, der meist von der IT-Abteilung initiiert wird
2. Als geplantes Projekt

Ich  beschäftige  mich mit dem zweiten Ansatz, der allerdings höhere Erwartungen an das Wiki stellt und den Beteiligten eine kürzere Lernphase abverlangt.  Die genannten Punkte habe ich mal in einer Mindmap zusammen getragen und hoffe so, anderen eine Arbeitsgrundlage zur Verfügung stellen zu können.

Wiki-Einführung

Ich habe einen etwas älteren aber dennoch aktuellen Beitrag von Jens Wagener in seinem Blog gefunden, der sehr viel über das Verhalten von uns allen in Projekten widerspiegelt.

In diesem Beitrag geht es konkret darum Regeln in agilen Projekten zu hinterfragen.

Regeln können und müssen jederzeit hinterfragt werden. Wer das nicht tut und stattdessen dumme Antworten sang und klanglos akzeptiert, ist selber schuld und wird nie an die Bananen gelangen.

Ich würde sogar noch einen Schritt weiter gehen:

Wir müssen “Um-Die-Ecke-Denken” um auch zukünfig in Projekten oder im Tagesgeschäft erfolgreich zu sein. Wer dies nicht tut, trägt dazu bei in einer “Bananenrepublik” zu arbeiten.

Die Vorteile von agilen Vorgehensweisen in IT-Projekten sind hinlänglich bekannt (oder hier nachzulesen).  Kritiker meinen, dass bei diesen Methoden häufig der Gesamtüberblick verloren geht. Dadurch dass das Big Design Up Front (oder Bug Desgin Up Front) fehlt, und die Systeme iterativ entworfen werden, kann man schnell das ingenieurmäßige Vorgehen vermissen.

Agile Projekte stehen aber nicht im Konflikt mit den Ingenieurswissenschaften. Ganz im Gegenteil, dort werden sie seit den 80 erfolgreich eingesetzt. Ziel agiler Projekte ist vielmehr der Blick auf das Wesentliche zu beschränken. Dennoch fehlt häufig das „Big Picture“ für den Gesamtüberblick.

Genau dort kommt das Fundamental Modeling Concept (FMC) zum Einsatz. Mit Hilfe des FMC kann man Fach- und IT-Landkarten erstellen,  die allen Projektbeteiligten helfen einen schnellen Überblick zu bekommen.  Ich habe mir das Landkartenkonzept einmal näher angesehen und bin davon überzeugt. Im Vergleich zu Unified Modeling Language (UML), kann man FMC –Blockdiagramme ohne großen Lernaufwand auf Anhieb verstehen.  Das genügt um nach meinem Grundsatz zu handeln:

“So einfach wie möglich – aber nicht einfacher”

Probieren Sie es mal aus: http://www.fmc-modeling.org/