Jens Coldewey beschreibt in seinem Artikel “Certified Scrum Developer und implizites Wissen” sehr anschaulich wie implizites Wissen eigentlich aufgebaut wird und welche Gefahren in  Zertifizierungen von Programmierern  lauern.

Er geht davon aus, dass das der Erfolg von Scrum auch zum Teil auf den Zertifizierungen der Scrum-Alliance beruht, was ich genau so sehe.  Weiterhin geht er davon aus, dass ein unfähiger Scrum Master nicht so großen Schaden im Projekt anrichten kann wie es die nicht so talentierten Programmierer könnten.  Dieser Schaden könnte dann auf die Scrum-Zertifizierungen oder gar Scrum zurückfallen.

Dies hat mich dazu bewegt mich mit dem Thema nochmals auseinanderzusetzen. Tatsächlich sehe ich es auch so, dass schlechter Code das Projekt weit zurückwerfen kann, nämlich genau dann wenn der Programmierer aufgrund seiner Leistungen (meist wird ein anderer Grund gefunden) aus dem Projekt ausscheidet und die verbleibenden oder nachfolgenden Programmierer ein Refactoring  durchführen müssen.

Faktisch habe ich in meinem Studium ebenfalls erlebt, dass einigen Professoren die Meinung vertreten: “Programmieren ist Sekretärinnen Arbeit.” Insgesamt kommt es aber sicherlich auf das Projekt und das Umfeld an. Ich habe Programmierer kennen gelernt, die nicht mehr geleistet haben als fertige Konzepte in Code zu gießen.

Da wir uns hier aber in agilen Projekten bewegen, werden solche Programmierer sicherlich nicht daran beteiligt sein.

Dass Programmieren als niedere Tätigkeit angesehen wird, liegt  einerseits  an den Hochschulen, die es so lehren, andererseits aber auch an den Unternehmen, die diese “homogene Tätigkeit” in  Niedriglohnländer verlegen.

Für mich entscheidend  liegt es aber auch an den Programmierern selbst, die wie Administratoren ihre Tätigkeiten nicht angemessen kommunizieren und zu wenig Eigenmarketing betreiben. So werden IT-Spezialisten von den Fachabteilungen häufig als arrogant und überheblich angesehen.  Da man sich nicht mit den “Standard Nerds” auseinandersetzen möchte, wird deren Tätigkeit eben degradiert.

Also, Informatiker aller Länder redet mehr mit anderen Menschen!

(Bildquelle: Stock Exchange, Zela)

Der letze Beitrag zur agilen Systemadministration enthielt einen Vorschlag wie man die agilen Methoden auf das Tagesgeschäft eines Administrators übertragen kann.

Nun versuche ich einen Überblick zu geben wie Systemadministratoren in agilen Projekten involviert werden können. Dabei sind offensichtlich drei Aspekte relevant:

• Zusammenarbeit mit Menschen
• Iteratives Vorgehen
• Beraten und Coachen

Diese Punkte sind in meiner Sysadmin-Zeit immer wieder aufgetreten und haben sich in Projekten erfolgreich bewährt.

Punkt 1: Zusammenarbeit mit Menschen.
In (agilen) Projekten ist es häufig erforderlich, dass die Administratoren mit ihrem Wissen das Projektteam unterstützen.  Leider gibt es Vertreter dieser Zunft, die ständig versuchen das Projektteam zu manipulieren und ihre eigenen Regeln getreu dem Motto: “Ich bin root, ich darf das” durchzusetzen. Dabei bedienen sie sich häufig starrer Regeln und Policies (ITIL sei Dank). Hier zeigt sich der grundsätzliche Konflikt zwischen Projektteam und Serviceteam. Die einen wollen ihr Projekt erfolgreich zu Ende bringen (da stören diese Richtlinien eben). Und die Anderen müssen das operative Tagesgeschäft samt Rechteverwaltung sicherstellen.

Daher stammt vermutlich auch das alte Klischeedenken, dass der Administrator der natürliche Feind des Entwicklers ist. Vielmehr muss hier auch dem Admin daran gelegen sein, das Projekt erfolgreich zu beenden und nicht zu behindern.

Punkt 2: Iteratives vorgehen.
So wie das Projektteam arbeitet, muss auch der Administrator iterativ arbeiten.  Das bedeutet, dass die Systeme zuerst grundsätzlich installiert werden und in Folgeschritten die User angelegt und berechtigt werden. Eine komplette Berechtigungsliste kann man hier noch nicht erwarten. Auch kann es sein, dass Systeme während einer langen Projektlaufzeit aktualisiert werden müssen, weil das Projektteam die neuen Funktionalitäten dringend benötigt, oder das Netzwerk aktualisiert werden muss, da die Bandbreite nicht ausreicht.

Punkt 3: Beraten und Coachen.
Hier geht es darum den Entwicklern die Richtlinien und Policies zu erläutern, die für den operativen Betrieb gelten; sie von der Einhaltung der Richtlinien zu überzeugen.  Der Kampf ist bereits verloren, wenn der Administrator versucht die Regeln einfach durchzusetzen. Insgesamt gilt es aber auch die bestehenden Richtlinien selbst immer wieder zu hinterfragen und zu prüfen, ob sie tatsächlich dienlich oder hinderlich sind.

Ebenso müssen dem Projektteam die Zusammenhänge der IT-Infrastruktur erläutert werden. Dies ist insbesondere dann interessant, wenn die IT-Architektur ausschließlich von dem Team festgelegt wird.

Fazit:
Gerade wenn in Projekten agil gearbeitet wird, ist es erforderlich die agilen Werte für die Zusammenarbeit auch zu leben. Das gilt insbesondere für den Urkonflikt zwischen Systemadministratoren und Programmierern.  Allerdings sollte nicht nur der schnelle Projekterfolg im Auge gehalten werden, sondern auch die Gesamtheit der Maßnahmen, durch die ein stabiler und störungsfreier IT-Betrieb möglich wird.

Innerhalb nur einer Woche erreichte die Petition gegen die Internetsperre die benötigten 50.000 Stimmen, damit der Petitionsausschuss des Bundestages sich mit dem Antrag in einer öffentlichen Sitzung beschäftigt.

Laut dem Gesetzentwurf der Bundesregierung soll das BKA Websites mit Kinderpornografie in einer Liste benennen und die dort aufgeführten Seiten müssen Internet-Provider sperren:

Wir halten das geplante Vorgehen, Internetseiten vom BKA indizieren & von den Providern sperren zu lassen, für undurchsichtig & unkontrollierbar, da die “Sperrlisten” weder einsehbar sind noch genau festgelegt ist, nach welchen Kriterien Webseiten auf die Liste gesetzt werden. Wir sehen darin eine Gefährdung des Grundrechtes auf Informationsfreiheit.

Nun hoffe ich, dass doch noch erkannt wird, dass dieses Vorhaben vollkommen am Ziel vorbeischießt. Denn eine Eindämmung der Kinderpornografie wird damit definitiv nicht erreicht, wohl aber eine Zensur des Internets vorgenommen.

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.

Wir sind derzeit dabei ein Wiki für einen bestimmten Teilbereich neu einzuführen.  Dieser Bereich hat sich bisher vor dieser Technologie verschlossen und möchte das nun ändern.  Bei der Präsentation  stellten die Stakeholder natürlich die Frage, wie wir die Qualität der Wiki-Inhalte sicherstellen.

Im Vergleich zu Wikipedia, wo mehrere 100 Autoren die Beiträge prüfen, ist ein Firmenwiki auf sich alleine gestellt. Sofern ein Wiki überhaupt eine Qualitätssicherung benötigt, sollte man sich vielleicht nochmal vor Augen führen was zu Qualität führt:

• Strukturiertes Vorgehen
• Einsatz von Hilfsmitteln / Werkzeugen
• Ausbildung

Unter Beachtung dieser Punkte können auch in einem vermeintlich unstrukturierten Wiki Beiträge hoher Qualität erzeugt werden. Ideen für die Umsetzung dieser Punkte möchte ich in diesem Beitrag anregen.

Punkt 1: Strukturiertes Vorgehen
Es muss zu Beginn klar sein was in das Wiki gestellt wird. Es muss ein Zielbild entwickelt, Kategorien geschaffen, Namensräume und klare Rollendefinitionen vergeben werden.  Dies zielt auf die Planung vor Einführung eines Wikis ab. So können beispielsweise Mitarbeiter die Rolle des “Wiki Gärtners” übernehmen, der die Beiträge kontrolliert. Dabei  sollte sich die Kontrolle auf folgende Bereiche konzentrieren:

• Kategorienzuordnung,
• Vervollständigung,
• Konfliktlösung  bei inhaltlichen Diskussionen
• Redundanz der Artikel

Es ist also ein manueller Aufwand erforderlich, um die Qualität des Systems zu gewährleisten.

Punkt 2: Einsatz von Hilfsmitteln / Werkzeugen

Es ist inzwischen unbestritten, dass der richtige Einsatz von Werkzeugen die Qualität eines Systems erhöht.  So bleibt bei einem Wiki die Frage wie ein “Wiki Gärtner” über neu zu prüfende Beiträge informiert wird.  Hier scheiden sich die Geister ob ein Push- oder Pull-Mechanismus die richtige Wahl ist.  So kann der Wiki-Gärtner über alle neuen Einträge informiert werden, oder der Autor eines jeweiligen Beitrags einen Benachrichtigungs-Button aktivieren.  So kann durch einen Workflow versucht werden, eine Bewertung der Beiträge zu organisieren.  Vielleicht reicht es einfach, wenn der Wiki-Gärtner sich über bestimmte Suchkriterien einen RSS-Feed abonniert, um auf die neuen Beiträge aufmerksam zu werden.

Punkt 3: Ausbildung

Die Mitarbeiter, die ein das Wiki nutzen sollen, müssen über die notwendigen Fähigkeiten verfügen dieses zu tun. Viele werden da sagen, dass das selbstverständlich ist, in der Praxis wird dieser Faktor leider häufig unterschätzt.  Es sollte also vorab klar sein, was in das Wiki eingestellt werden soll. Es muss transparent sein, was ein Howto ist, ein  Artikel, eine Notiz etc. Ebenso sollte die Meta-Syntax des Wiki-Systems klar und eine Hilfe zur Benutzung verfügbar sein. Denn mangelnde Ausbildung des Personals kann gleichzeitig auch das Scheitern des Wiki-Projekts zur Folge haben. Nämlich genau dann, wenn die beteiligten Personen das Wiki boykottieren und immer noch die Dokumente per Email versenden, die eigentlich in das Wiki gehören.

Fazit:

Die Bedenken bei einer Wiki-Einführung, die oft vom Management eingebracht werden, können durch eine gute Planung ausgeräumt werden. Die Qualität eines Wikis steht insgesamt mit der Art und Weise, wie das Projekt Enterprise 2.0 angegangen wird.  Leider werden die Ziele häufig zu hoch angesetzt und die Erwartungen nicht erfüllt.  Das Wiki ist auch nur ein Werkzeug, und bildet mit vielen anderen Arbeitsmethoden und Hilfsmitteln einen Weg zum Enterprise 2.0.