Clean Agile: "Agile in the Large" [Inhalte in Englisch]

[paedubucher]

Wir haben es schon an einer anderen Stelle diskutiert: Ich schreibe aus didaktischen Gründen gerade eine Zusammenfassung über das Buch Clean Agile. Back to Basics von Robert C. Martin. Dabei sind Meillo und eggy einige Widersprüche und Unzulänglichkeiten aufgefallen, die weniger an meiner Interpretation des Buchinhalts liegen, als an dessen Inhalt selbst.

Heute habe ich das Unterkapitel "Agile in the Large" zusammengefasst. Dabei ist bei mir der Verdacht auf weitere Widersprüche entstanden. Ich zitiere hier ein paar Stellen (S. 144-147, meine Hervorhebungen sind fett):

Agile is for small- to medium-sized teams, period. It works well for such teams. Agile was never intended for large teams.

Why weren't we trying to solve the problem of large teams? Simply because the problem of large teams is a problem that many experts have worked on for well over five millenia. The problem of large teams is the problem of societies and civilizations. And, if our current civilization is any measure, it appears to be a problem that we have solved rather well.

How do you build the pyramids? You need to have solved the problems of large teams. [...]

Large teams are a solved problem.

(p. 145)

Wir wissen schon, wie wir grosse Teams managen, schliesslich konnten wir ja die Pyramiden bauen. Nun bauen wir aber keine Pyramiden, sondern Software:

The problem that was not solved back in the late '80s when the Agile movement began was the problem of small software teams. We did not know how to effectively organize a relatively small group of programmers to be effective. And it was this problem that Agile solved.

It's important to understand that this was a software problem, not a small team problem. The problem of small teams had been solved millenia before by military and industrial organizations around the world. The Romans could not have conquered Europe if they had not solved the problem of organizing small squads.

Agile is the set of disciplines by which we organize small software teams. Why do we need a special technique for this? Because software is unique. There are very few tasks like it. [...]

(p. 146)

Das Problem ist somit nicht die Organisation von kleinen Teams, sondern die Organisation kleiner Teams, die Software entwickeln. Software ist etwas radikal anderes.

Dijkstra hat das an anderer Stelle gut dargelegt: So gibt es bei einer Stadt auf jeder Ebene andere Spezialisten (vom Bürgermeister für die Verwaltung des grossen Ganzen, über die Architekten, welche einzelne Häuser bauen, bis hinunter zu den Chemikern, die an Werkstoffen für diese Gebäude tüfteln). Beim Computer ist aber der Programmierer verantwortlich für ganze Terabytes bis hinunter zum letzten Bit. Eine solche Spanne gibt es sonst nur in der Biologie (Ökosysteme bis Molekularbiologie), hier ist aber das wenigste menschgemacht. Bei der Software ist alles menschgemacht!

Ironischerweise behauptet Robert C. Martin noch folgendes:

Software is like mathematics, except that nothing can be proven. (p. 146)

Dem würde Dijkstra wohl kaum zustimmen, aber darum geht es hier jetzt nicht. Sondern:

The bottom line here is that Agile is about software. In particular, it is about small software teams. [...] (p. 146)

Soweit so gut. Jetzt kommt aber der Teil, der mich stört:

What about Agile in the large? I don't think there is such a thing. Organizing large teams is a matter of organizing them into small teams. Agile solves the problem for small software teams; the problem of organizing small teams into larger teams is a solved problem. [...]

Now the question that could be asked is that, since software for small teams was so unique that it required us to invent Agile, why doesn't that uniqueness hold for organizing small software teams into larger software teams? Isn't there some unique aspect to software that carries beyond the small team and affects the way larger teams ought to be organized?

I doubt it, because the problem of large teams, which we solved more than 5000 years ago, is the problem of getting many diverse kinds of teams to cooperate. Agile teams are just one of myriad kinds of teams that need to be coordinated in a large project. (p.147)

Vor 5000 Jahren konnten "wir" bereits Pyramiden bauen, und natürlich benötigte es dort "diverse" Teams, d.h. Architekten, Bauleiter, Lastenträger usw. Aber eben keine Softwareentwickler!

Wie will ich nun ein grosses Projekt abteilungsübergreifend, d.h. top-down organisieren, wenn da ein Team in der Organisation ist, das agil arbeitet? Bauprojekte funktionieren top-down, auch ein Krieg wird top-down geführt. Aber wie soll denn bitte top-down und bottom-up gleichzeitig funktionieren? Hat nicht Gerald Weinberg ganze Bände darüber gefüllt, wie sich die Organisation um die Entwickler herum auf die Software auswirkt? Na gut, der war halt noch nicht "agil", bzw. "Agile". Somit ist er sicherlich obsolet, und ausserdem auch schon tot

Mein Eindruck: der Autor drückt sich um die Frage herum, wie agile Teams in einer übergeordneten Organisation funktionieren sollen.

Was mich auch stört, ich aber vorübergehend als Prämisse akzeptieren musste: Die Behauptung, dass die Organisation grosser Teams ein gelöstes Problem sei. Ich habe bisher immer nur das Gegenteil erfahren: Die Organisation grosser (aber auch kleiner) Teams ist das grösste Problem an der Softwareentwicklung überhaupt!

Das ganze erinnert mich an eine andere Aussage aus dem Buch Clean Architecture: "The database is just a detail." Na dann haben wir das ja auch schon längst gelöst...

Was denkt ihr darüber? Spricht da meine Allergie gegen Robert C. Martin aus mir, oder sind die Aussagen wirklich widersprüchlich, oder zumindest bloss ausweichend?

[Meillo]

Da bisher niemand etwas dazu gesagt hat, poste ich jetzt doch als erster meine Meinung, auch wenn die wenig Kontrast bietet. Mir waere es lieber, wir haetten hier eine sachliche Diskussion zu einzelnen Aspekten als kollektives Oncle-Bob-Bashing. Das bringt ja auch nichts und ist so negativ ...


Jedenfalls: Ich verstehe nicht, warum er hier ueberhaupt auf die Groesse der Teams eingeht. Was ist die Aussage dieser Stellgroesse im Bezug auf das was er sagen will? Muss er die Groesse des Teams ueberhaupt erwaehnen um seine eigentliche Aussage (Informatik ist anders als der Rest) zu erklaeren und transportieren?

Wenn er sagt, das Problem grosser Teams sei geloest, dann bin ich gegenteiliger Meinung. Das Problem grosser Teams ist voellig ungeloest; wir schaffen die Dinge ja gerade mal in kleinen Teams halbwegs wenn alle Faktoren guenstig sind. Grosse Teams sind auch gar keine Teams, sondern hierarchische Strukturen, Disziplin, Gleichfoermigkeit. Das widerspricht meinem Verstaendnis von einem Team. Das grosse ``Team'' militaerisch zu organisieren und/oder als Organe eines Koerpers zu betrachten, das funktioniert und das haben wir gelernt. Nur funktioniert diese Art halt schlecht fuer die Informatik. Dort sind Dinge wichtig, die beim Pyramidenbau unwichtig waren. (Die Pyramide hat nach halber Bauzeit z.B. nicht ploetzlich die Form wechseln muessen, weil dann was anderes Mode geworden ist.)

Das was du so zitiert hast (wohl gemerkt, dass ich nur diese aus dem Kontext und Gesamtwerk gerissenen Schnipsel gelesen habe, nicht ab das ganze Buch) macht auf mich den Eindruck, dass es mehr erste Gedanken als fundiert durchdachte Ueberlegungen sind. Das ist sicher unserer Zeit geschuldet. Wenn er erst zehn Jahr darueber nachdenken wuerde, ob seine Sichtweise wirklich passend ist oder ob da nicht doch noch ein tieferliegendes Phaenomen vorhanden ist, um das es eigentlich geht, dann ... -- Ach! Ich sollte aufhoeren, mich ueberhaupt noch damit zu befassen. Es frustriert mich nur und vergeudet meine Zeit. Wenn ich wirklich etwas verstehen will, dann lese ich Weinberg. Das wirkt zwar veraltet (was aber kaum relevant ist, da eher viel genereller ansetzt und darum die Aussage viel andauernder ist) und ist sehr viel anstrengender zu lesen (weil man viel Ruhe, Zeit und einen klaren Kopf braucht), aber dafuer umso befriedigender und ich komme dort wirklich weiter.

[paedubucher]

Da bisher niemand etwas dazu gesagt hat, poste ich jetzt doch als erster meine Meinung, auch wenn die wenig Kontrast bietet. Mir waere es lieber, wir haetten hier eine sachliche Diskussion zu einzelnen Aspekten als kollektives Oncle-Bob-Bashing. Das bringt ja auch nichts und ist so negativ ...

Och, menno, das wäre endlich wieder mal etwas gewesen, was ich könnte

Doch Spass beiseite...

Jedenfalls: Ich verstehe nicht, warum er hier ueberhaupt auf die Groesse der Teams eingeht. Was ist die Aussage dieser Stellgroesse im Bezug auf das was er sagen will? Muss er die Groesse des Teams ueberhaupt erwaehnen um seine eigentliche Aussage (Informatik ist anders als der Rest) zu erklaeren und transportieren?

Der Kontext ist, dass man von aussen von einem agilen Team beeindruckt ist, und dann die ganze Firma darauf umstellen möchte. "Agile im Grossen" ist wohl eine Frage, die dem Autor oft gestellt wird. (Das ganze Buch kann als eine Art FAQ gelesen werden.)

Wenn er sagt, das Problem grosser Teams sei geloest, dann bin ich gegenteiliger Meinung. Das Problem grosser Teams ist voellig ungeloest; wir schaffen die Dinge ja gerade mal in kleinen Teams halbwegs wenn alle Faktoren guenstig sind.Grosse Teams sind auch gar keine Teams, sondern hierarchische Strukturen, Disziplin, Gleichfoermigkeit. Das widerspricht meinem Verstaendnis von einem Team. Das grosse ``Team'' militaerisch zu organisieren und/oder als Organe eines Koerpers zu betrachten, das funktioniert und das haben wir gelernt. Nur funktioniert diese Art halt schlecht fuer die Informatik. Dort sind Dinge wichtig, die beim Pyramidenbau unwichtig waren. (Die Pyramide hat nach halber Bauzeit z.B. nicht ploetzlich die Form wechseln muessen, weil dann was anderes Mode geworden ist.)

Mir wird erst jetzt so richtig bewusst, dass tatsächlich die Rede von "large Teams" und nicht einfach von "large Organizations" ist. Also offenbar schreibt er wirklich von grossen Teams, was also ein Oxymoron ist. Umgangssprachlich ist ja oft die Rede von Firmen, die "ein gutes Team" haben, womit einfach die Belegschaft gemeint wird. Oder "Lehrerteam" an einer grösseren Schule. Aber dieser Gebraucht des Wortes "Team" ist in diesem Kontext wirklich etwas eigenartig. So habe ich das bei der Lektüre gar nicht gesehen...

Das was du so zitiert hast (wohl gemerkt, dass ich nur diese aus dem Kontext und Gesamtwerk gerissenen Schnipsel gelesen habe, nicht ab das ganze Buch) macht auf mich den Eindruck, dass es mehr erste Gedanken als fundiert durchdachte Ueberlegungen sind. Das ist sicher unserer Zeit geschuldet. Wenn er erst zehn Jahr darueber nachdenken wuerde, ob seine Sichtweise wirklich passend ist oder ob da nicht doch noch ein tieferliegendes Phaenomen vorhanden ist, um das es eigentlich geht, dann ... -- Ach! Ich sollte aufhoeren, mich ueberhaupt noch damit zu befassen. Es frustriert mich nur und vergeudet meine Zeit. Wenn ich wirklich etwas verstehen will, dann lese ich Weinberg. Das wirkt zwar veraltet (was aber kaum relevant ist, da eher viel genereller ansetzt und darum die Aussage viel andauernder ist) und ist sehr viel anstrengender zu lesen (weil man viel Ruhe, Zeit und einen klaren Kopf braucht), aber dafuer umso befriedigender und ich komme dort wirklich weiter.

Einerseits spricht hier der erfahrene Consultant ("Uncle Bob") zu uns, andererseits steht ganz am Ende des Unterkapitels folgendes:

Now, again, this is not a subject that I have diligently researched. What you just read is my opinion, and I could be very wrong. [...] (p. 147)

Hätte ich vielleicht fairerweise gleich zu Beginn so zitieren sollen. Wenn sich aber in einem gedruckten Buch ein Experte zu einem Thema erklärt, erwarte ich schon eine gewisse Expertise. Sonst soll er das Unterkapitel einfach weglassen statt wieder "bold claims" abzugeben ("Large teams are a solved problem").

Das erinnert mich an einen Vortrag von Brian Kernighan, wo er eine Folie zum Thema funktionale Programmierung drin hatte. Der Inhalt? "This slide has been left blank intentionally". Er meinte dann, dass er sich mit dem Thema nicht auskenne, und darum nichts darüber sagen werde.

Vielleicht sollte ich es mit diesem Boomer Bob einfach auf sich beruhen lassen und, wie du schreibst, besser Weinberg lesen. Unserem Entwicklungsleiter ist der Name sogar ein Begriff, also kein Grund da mit "Clean Agile" auftrumpfen zu wollen...