Ihr habt das Scrum falsch gemacht!

Das PHP BarCamp in Salzburg dieses Wochenende war super. Herzlichen Dank an Evelyne Selak, die scheinbar die Organisation zum Großteil auf sich gezogen hat. Ich könnte sowas nicht leisten und hätte Angst, dass Hotel & Sponsoren absagen und niemand kommt.

Nett fand ich mal wieder Sebastian Bergmanns Vorstellungen zu testbarer Software zu hören. Im Wesentlichen basierte seine Argumentation in letzter Konsequenz auch auf „_man will ja dieses und darum muss man jenes so und so machen_“. Finde ich nicht falsch und für mich gut verständlich. Nur: Wenn man das so einem normalen Entwickler erzählt, schaut dieser nur befremdlich und sagt dann, dass es anders doch auch geht und viel einfacher ist.

In der Praxis ist es so, dass man schon vor einer großen Herausforderung steht, wenn man Entwickler nur dazu bringen muss, nicht allen Code in eine Klasse zu schreiben. Von „_Separation of Concerns_“ haben gefühlte 30% der Entwickler schon was gehört. In Büchern wie „PHP Quick and Dirty“ wird es als tolle Idee angesehen, einen PHP-Interpreter herauszubringen der deutsche Keywords versteht, weil man Entwicklern nicht zumuten kann, Englisch zu lernen oder ein Wörterbuch zu verwenden. Alles Zeitverschwendung. In einem anderen Buch zu objektorientiertem PHP wird auf endlosen Seiten auf die Implementierung des Countable-Interfaces aus der SPL eingegangen um dann zum Fazit zu kommen: „Ohne Countable geht es nicht“. Damn, ich habe das in den letzten 10 Jahren nicht gebraucht.

Wenn man auf so ein BarCamp geht, entsteht der Eindruck, alle Anwesenden würden fast immer das richtige Design Pattern verwenden und streng nach Test-Driven-Development (TDD) und Extreme-Programming (XP) Grundsätzen arbeiten. Dass das nicht so ist, ist anzunehmen, zumindest hinterlässt meine berufliche Praxis ein schmerzhaft anderes Bild. Insbesondere problematisch finde ich solche in den Raum gestellten Statements, wenn der Source-Code (wie bei fast allen Web Anwendungen) nicht einsehbar ist. Lieber wird an Open-Source Projekten wie Zend Framework und Magento kleinteilig herumkritisiert. Bei Magento gibt es keine Tests, im Source sind dumme Fehler zu finden, langsam ist es eh und die meisten Zend Framework Klassen seien auch nur schnell zusammengehackt worden. Leider sind die meisten Closed-Source Anwendungen noch sehr viel schlimmer!

Um diesem Problem zu begegnen wird von verschiedener Seite „Scrum“ als Lösung propagiert. Insbesondere wird in dem Zusammenhang die niedrige Fehlerrate und der hohe Grad an Selbstorganisation, die durch Vertrauen und Eitelkeit ermöglicht wird, hochgehalten. Im Nebensatz werden dann noch schnell XP und TDD erwähnt, und schnell ist klar, dass es sich hier um ein Rezept für erfolgreiche Projekte handelt.

Zunächst einmal sollte man TDD, XP und das eigentliche Scrum-Projekt-Management auseinander halten. Das Tests die Qualität erhöhen, hat zunächst nichts mit agilem Projekt-Management zu tun. Häufig wird das in einen Topf geworfen, und dann heißt es pauschal, Scrum würde die Qualität erhöhen. Agiles Projekt-Management soll flexibel auf geänderte Anforderungen reagieren und daher in kurzen Iterationen arbeiten. Dabei sind Tests nicht nur hilfreich, sondern wegen der laufenden Refactorings dringend notwendig – deswegen wird beides zu Recht zusammen genannt. Nur Vertrauen alleine schafft noch lange keine guten Tests, selbst wenn ein Team tatsächlich schafft welche zu schreiben, was IMO auch eine Seltenheit ist. Ich kenne es auch so herum, dass die Entwickler vor lauter Eitelkeit in Panik verfallen und gezielt schlampig arbeiten, um am Iterationsende ein Stück schlechten Code mit schlechten Tests vorweisen zu können. Traut sich dann wirklich immer jemand die Wahrheit auszusprechen, die Arbeit von ein oder zwei Wochen zu verwerfen und neu anzufangen? Eventuell sogar den Mitarbeiter zu kündigen, obwohl seine Familie das Geld dringend benötigt, weil gerade Nachwuchs gekommen ist? Das ist doch so realistisch wie die freie Marktwirtschaft.

Formale Methoden verfolgen das gleiche Ziel der Fehlerfreiheit, werden jedoch oft gar nicht erwähnt oder auch nur in Erwägung gezogen. Weiter sollte es klar sein, dass es Entwickler gibt, die sich selbst organisieren können und andere, die mehr Unterstützung benötigen und nicht die Erfahrung haben um an allem arbeiten zu können. Man hat oft kein Team, das nur aus Senior Entwicklern besteht und selbst diese unterscheiden sich untereinander. Am Ende des Tages kommt es einzig und allein auf die Kompetenz der Projekt-Beteiligten auf allen Ebenen an und nicht so sehr darauf, welche trendige Management-Methode man angewendet hat. Siehe dazu auch Cargo Cult Software Engineering. Statt das anzuerkennen, wird gegenüber Scrum-Kritikern polemisch das Bild vom autoritären Chef gezeichnet, der boshaft Befehle verteilt, so dass dann natürlich nur die offensichtlich bessere Option der magischen Selbst-Organisation bleibt. Von eiserner Disziplin will niemand gerne reden, das wäre am Ende ja noch anstrengend und würde mit alternativen oder hybriden Ansätzen, die nicht der reinen Scrum-Lehre entsprechen, möglicherweise genauso gut funktionieren.

„Most teams purporting to be doing agile software development are not applying the level of technical rigor necessary to succeed at it. Most “agile” teams have actually only adopted Scrum’s project-management practices and have failed to effectively adopt “the hard disciplines” like test-driven development, refactoring, pair programming, simple design, and continuous integration.” Jean-Raymond Abrial, Faultless systems: Yes we can!, IEEE Computer 92009

Niemand ist ein Gegner von Vertrauen, Selbstorganisation, Selbstmotivation und Agilität. Soweit ich sehe funktioniert agiles Vorgehen gut in kleinen Teams mit sehr erfahrenen Entwicklern oder wenn die grundsätzliche Architektur zentral vorgegeben ist und nur noch konkrete Details von den einzelnen Entwicklern mit Hilfe eines bereits fertigen Frameworks implementiert werden. Zudem muss man gnadenlos konsequent sein, was je nach Team viel Kraft und Zeit kosten kann bis alles rund läuft. Was nicht geht, ist sich vorne hin zu stellen und zu erzählen, wie toll und einfach alles ist (“klar gibt es hin und wieder Probleme, aber dann redet man halt”). Diejenigen bei denen es wie zu erwarten nicht gut ausgeht, haben es dann einfach falsch gemacht. Solche Totschlag-Argumente erinnern einen an religiöse Gemeinschaften.