Das Meetings nicht unnötig sind, ist den meisten Teamplayern bewusst, der Austausch an Informationen ist wichtig für den Projekterfolg, auch die gemeinsamen Diskussionen beeinflussen die Qualität der Produkte, die es zu erstellen gibt. Trotzdem werden schätzungsweise 50 Prozent aller Gruppentermine als nicht erfolgreich wahrgenommen. Da zu einem erfolgreichen Projekt auch erfolgreiche und nicht weitverbrennende Termine gehören, gilt es zu analysieren, warum das teure Beisammensein häufig erfolglos scheint. Im Normalfall sind es immer wieder die gleichen Probleme die auftreten:

• Durcheinanderreden und Monologe der Teilnehmer – Viele dominante Kollegen nutzen solche Augenblicke, um sich zur Schau zu stellen und all ihr Wissen in minutenlangen Monologen wiederzugeben. Zusätzlich passiert es bei hitzigen Debatten, dass alle Teilnehmer gleichzeitig reden wollen. Ist die Stimmung eines solchen Termins erst mal vergiftet, ist es schwer wieder auf eine sachliche Ebene zu gelangen.
• Abschweifen vom eigentlichen Thema – Häufig passiert es, dass die Teilnehmer weit vom eigentlichen Thema abkommen, da kommt von vom eigentlichen Fokus schnell zu Problem B und von dort zu Problem C. Diese Punkte sind sicherlich auch für den Projekterfolg wichtig, trotzdem helfen sie einem nicht beim eigentlichen Grund des Meetings.
• Überziehen der Termine – Eine Stunde rum, diverse hitzige Diskussionen hinter sich gebracht, aber ein Konsens wurde nicht gefunden. So oder so ähnlich enden viele schlecht laufende Besprechungen. Durch die harten Anschläge weiterer Termine bleibt in einem solchen Fall auch keine Zeit mehr noch schnell ein Ergebnis zu formulieren und wenn es dann doch gelingt, wurde es übers Knie gebrochen und wird sicherlich nach kurzer Zeit wieder auf dem Tisch landen.
• Unsicherheit beim Ergebnis – Termin abgeschlossen. Die Teilnehmer gehen mit einem guten Gefühl raus, im Nachgang wird aber klar, dass gar nicht alle Teilnehmer das Ergebnis des Termins identisch in Erinnerung haben. Nach einer Woche werden es immer mehr, die sicher sind, dass genau das Ergebnis in ihrem Köpfen das richtige war und man sich wundert, dass andere nicht genau das gleiche denken.

Meetings werden häufig als nervend wahrgenommen und der Grund dahinter nicht analysiert. Häufig sind es aber genau die vier aufgeführten Punkte, die einen eigentlich nützlichen Termin als Strapaze enden lassen. Dabei hilft die Erstellung und die Einhaltung einfacher Meetingregeln bereits das gröbste aus der Welt zu schaffen.

• Es existiert eine Agenda - In der Einladung der Besprechung wird bereits genau beschrieben, wie der Termin ablaufen soll. Dieser Ablaufplan wird am Anfang einmal durchgesprochen, damit alle Teilnehmer wissen, was sie erwartet. Das Abschweifen wird somit bereits unterbunden, da eine klare Struktur des Themas behilflich ist sich selbst klarer zu strukturieren.
  Zusätzlich können sich Teilnehmer auf Grund der Agenda gezielt vorbereiten. Bemerkungen werden wertvoller und die eingebrachten Informationen hochwertiger. Oft sind Lösungen, die auch den gemeinsamen Tenor treffen, im Vorfeld in den Köpfen ausgearbeitet – vielleicht auch unterbewusst – und müssen nur erläutert werden. Gur vorbereitete Termine finden häufig schneller zu einem Konsens als spontane Treffen.
• Ein Moderator wurde bestimmt – Die Kunst der Moderation ist sicherlich keine einfache. Die Ernennung eines Moderators erhöht die Struktur aber auf mehreren Ebenen. Zum einen versucht ein guter Moderator fachlich neutral zu agieren, was bedeutet, er kann unterschiedliche Meinungen an einen Tisch bringen und bei der Konsensfindung behilflich sein. Zusätzlich hat er die Aufgabe den Prozess zu verteidigen.
• Nähert sich der Termin dem Ende, so muss den Teilnehmern frühzeitig dies mitgeteilt werden, so dass sich auf ein Ergebnis oder weiteres Vorgehen geeinigt werden kann.
• Unnötig lange Monologe können, mit Verweis auf die zur Verfügung stehenden Zeit, abgebrochen werden.
• Abschweifende Kommentare und Nebendiskussionen müssen unterbunden werden. Je früher hier gestoppt wird, desto einfacher ist der Weg zurück zum Hauptthema.
  • Bestimmung der Ziele – Damit der Erfolg eines Termins eintreten kann, muss klar definiert werden, was eigentlich das Ziel ist. Dieses Ziel gilt es bereits in der Einladung neben der Agenda festzuhalten. Das Ziel ist zusätzlich ein wichtiges Werkzeug des Moderators. Nur so kann bestimmt werden, ob Monologe, Abschweifungen oder sonstige vermeintliche Störungen zielführend sind.
  • Ergebnisprotokoll – Nach Durchführung des Termins müssen die Ergebnisse schriftlich festgehalten werden. Damit dies nicht zur Qual wird – wir wissen wie Informatiker auf die Erstellung von Protokollen reagieren – gilt es das Protokoll bei einem Standardtermin möglichst kurz zu halten. Ein guter Moderator lässt noch im Termin die Teilnehmer selbst die Ergebnissätze formulieren und beharrt darauf, dass kurz und prägnant sind. Wenn man ein Ergebnis nicht auf den Punkt bringen kann, dann ist es noch zu schwammig und muss noch einmal in die Runde gehen.

Wie bei allen Regeln sollte mit einer kleinen Anzahl begonnen werden. Reichen sie, dann sollte man mit dem gleichen Verfahren durch alle Termine kommen. Reichen sie nicht, gilt es wieder in die Analysephase zu gehen und Punkte zu entfernen oder hinzuzunehmen.

Standards scheinen auch in der Softwareentwicklung ein gerne angenommenes Geschenk zu sein, doch leider gibt es immer wieder den Trend zu sagen, dass Standards toll sind, sie aber leider nicht auf die aktuelle Situation passen. Dies ist ein wiederkehrendes Muster bei Bibliotheken [Die Bibliothek], aber noch häufiger sträuben sich Softwareprofis, wenn es um Prozesse geht.

In traditionellen Unternehmen sind es nicht die Entwickler, die die Prozesse machen, sondern das Management oder die Projektverantwortlichen. Wenn die Personen an der organisatorischen Spitze gut und erfahren sind, ist dies auch von Vorteil, da sie sich stärker mit der Materie befasst haben. Leider besteht häufig eine anscheinend natürliche Spannung zwischen Projektmanagement und Softwareentwicklung.

Programmierer neigen dazu Prozessfragen erst einmal sehr kritisch zu sehen. Jede Vorgabe, die einen daran hindert genau so zu arbeiten, wie es für einen als Individuum am besten ist, wird primär als Behinderung wahrgenommen.  Jeder Mensch ist einzigartig, warum sollte es eine funktionierende Methode geben alle möglichst produktiv zu steuern. In dieser Aussage stecken gleich zwei „Fehler“. Sind wir wirklich so unterschiedlich? Als Person betrachtet mag dies natürlich stimmen, wenn man aber die Person in ein Unternehmensumfeld steckt, so achtet man darauf, dass ein Team homogen zusammengestellt wird. Man ähnelt seinen Kollegen mit der Zeit immer mehr – so wie es bei Ehepaaren auch zu beobachten ist. Auch ein Teamleiter ist gut damit beraten sein Team so zusammenzustellen, dass ein ähnliches Gedankengut vorhanden ist. Die zweite falsche Annahme ist, dass es wichtig ist, dass man als einzelner maximal Produktiv sein muss. Natürlich arbeitet man gerne so optimiert wie möglich, das steht außer Frage. Einem Projektverantwortlichen ist es nicht wichtig, dass ein bestimmter  Mitarbeiter produktiv ist, sondern das Team muss maximale Leistung bringen. Wenn dies bedeutet, dass einer der Kollegen nicht sein ganzes Potential ausschöpfen kann, dann muss man damit umgehen können. Einfach ist dieses Umdenken sicher nicht, denn man muss sein egozentrisches Weltbild liegen lassen und das Gesamte sehen. Hat man dies geschafft, kann es einfacher sein, das Projektmanagement und seine Methoden zu verstehen.

Ein Paradebeispiel und gerade derzeit sehr aktuell ist die Einführung von agilen Prozessen, wie zum Beispiel Scrum. Obwohl es eine enorme Erleichterung für den Softwareentwickler bedeutet, ist er häufig sehr kritisch dem gegenübergestellt. Zu viele Unbekannte gilt es zu verstehen. Gewiss sollte man in einer solchen Situation nicht beginnen die neue Methodik zu bekämpfen. Den Gedanken, dass das eigene Projekt so individuell und das Team so besonders ist, dass dieses Vorgehen bei anderen klappen kann, aber leider bei einem selbst nicht, sollte man fürs erste unterdrücken.

Standards entstehen nicht einfach. Die meisten wurden von Experten erstellt, die sich mit der Thematik auskennen und die jahrelange Erfahrungen haben. Standards befinden sich bei anderen auch im täglichen Einsatz und dort funktionieren sie. Wenn man die Personen anspricht, die vor der Einführung kritisch waren, so werden die meisten sicher zurückrudern und sich eingestehen, dass es vielleicht doch eine gute Idee war.

Wichtig bei der Einführung neuer Standards ist, dass die Betroffenen offen mit dem Thema umgehen. Bedenken dürfen ausgesprochen werden, dürfen einen aber nicht dabei behindern es auszuprobieren. Wenn nur genügend Leute versuchen unterbewusst ein System zu sabotieren, dann werden sie es auch schaffen – egal wie gut das System ist. Klar ist auch, dass der Aspekt des Ausprobierens ein wichtiger ist.

Wir leben in einer agilen Welt. Entscheidungen, die getroffen wurden können revidiert werden. Wenn nach ein paar Wochen klar ist, dass der Standard wirklich nicht zu einem passt, dann hat man kaum etwas verloren. In den meisten Fällen wird man aber überrascht sein, dass es sich bei einem doch gut in das Gesamtsystem einbetten lässt.

„Leute, die sagen es kann nicht klappen, sollen denen nicht im Wege stehen, die es gerade machen.“

Mögliche Beweise kann man viele finden. So wurde zur Unterlegung der Theorie ein vollkommen intakter Jaguar in die südliche Bronx gestellt. Vier Tage vergingen und das Auto konnte ohne Kratzer wieder abgeholt werden. Keiner kam auf die Idee den Wagen anzufassen oder schlimmeres damit zu machen. Das gleiche Experiment wurde kurz darauf wieder mit diesem Jaguar ausgeführt. Die einzige kleine Schraube an der gedreht wurde, war das Einschlagen eines der kleinen Fenster. Innerhalb von vier Stunden lag das Auto auf dem Rücken, wurde angezündet und ausgenommen. Die Lehre aus diesem Test lautet „Beschädige etwas und kümmere dich nicht darum, andere werden es somit genauso behandeln“. Man muss aber nicht unbedingt ein Auto opfern, um einen Beweis für eine solche Theorie zu gewinnen. Die Beobachtung seines eigenen Mikrokosmos reicht häufig aus. Da wäre die aufgeräumte Wohnung, in der man sich am wohlsten fühlt und die erste Zeit wird man den Teufel tun und irgendwo etwas liegen lassen, sobald aber die ersten Teile nicht mehr auf ihrem Platz liegen findet das Chaos seinen Weg.

Wir als Softwareentwickler kennen dieses Vorgehen nur zu gut. Ist der erste Verstoß gegen die geltenden Regeln erst mal geschehen, so lassen der zweite und dritte nicht lange auf sich warten. Ist das System aber sauber, so tut es uns Entwicklern in der Seele weh, den ersten Fehler zu begehen, denn die meisten erkennen die Eleganz eines reinen Systems.

Es darf nicht vergessen werden, dass es viele Junior-Entwickler in Projekten gibt. Häufig passen sie sich an die Qualität des Codes an, den sie vorfinden. Sollten also keine Kommentare vorhanden sein, so wird er auch keine schreiben. Fehlt die Testabdeckung, so wird sich ein Junior nicht hinsetzen und Unit Tests schreiben. Dafür fehlen meist einfach die Erfahrungswerte und das Wissen, dass diese Eigenschaften von gutem Code einem zum späteren Zeitpunkt weiterhelfen.

Um ein System auf die Dauer sauber zu halten, gilt es möglichst viele Regeln, die man sich gesetzt hat automatisiert zu überprüfen. Es darf nicht passieren, dass sich der Verfall heimlich einschleicht. Ist ein Verstoß erst mal eine Weile im System wird sich niemand mehr verantwortlich fühlen, passiert das Auffinden jedoch zeitnah, so existiert auch noch eine Bindung zum Code.

Regeln die heutzutage einfach automatisiert geprüft werden können sind beispielsweise:

• Formatierungsregeln
• Validierung des Output-Formats
• Einhaltung minimaler Testabdeckung
• Fehlerfreier Testdurchlauf
• Softwaremetriken

Alles was einfach überprüft werden kann, sollte auch gemacht werden.

Bei der Einführung solcher Prüfungen, kann auch sehr viel falsch gemacht werden. Leicht kann der verantwortliche Qualitätsmanager über sein Ziel herausschießen. Sollte zum Beispiel jemand auf die Idee kommen nach dem Lesen dieses Abschnitts die aufgestellten Formatierungsregeln automatisiert zu testen, so ist dies fürs erste eine gute Idee. Wenn der Mechanismus dann das erste Mal durchgelaufen ist, wird man feststellen, dass bereits hunderte von Fenstern eingeschlagen wurden, also viele falsche Formatierungen gefunden wurden. Die Entwickler werden auf diese Art nicht mitgenommen werden. Ob man jetzt 50 oder 51 Probleme hat, ist einem herzlich egal.

Um neue Regeln sauber einzuführen müssen wir das Problem in kleine Häppchen zerlegen und diese dann peu à peu bereinigen. Wir haben neue Formatierungsregeln? Diese müssen vielleicht nur für neuen Code gelten oder wir schalten jeden Monat ein neues Verzeichnis zur Überprüfung hinzu. Wichtig dabei ist, dass der Schmutz, welcher sich über die Jahre gesammelt hat überschaubar bleibt, die Entwickler müssen das Gefühl haben es in einer humanen Zeit hinzubekommen. Wer räumt schon gerne den Müll von anderen auf?

Man sollte diese Phasen und den Ablauf der Teamentwicklung kennen. Wenn man diese ignoriert, stellt sich ein beliebig gutes oder schlechtes Ergebnis ein (was Motivation des Teams / Abwanderung und Zulauf, Zusammenarbeitsformen, Arbeitsergebnisse angeht).

Wenn man diese Prozesse kennt, kann man steuernd und bewusst eingreifen, um insgesamt bessere Ergebnisse zu erzeugen. Der Vortrag reflektiert sowohl berufliche Teams als auch Open Source Projekte und beantwortet Fragen zur Zielsetzung und -erreichung, Motivation und Beständigkeit.