Für ein gemeinsames Projekt ppfgb (Johannes Link, Henning Wolf, Marco Schulz, Christoph Stock, Sebastian Eichner, Bernd Schiffer, Stefan Roock und ich) haben Sebastian und ich heute „Remote Pairing“ betrieben. Dabei haben wir in folgender Umgebung gearbeitet:

• In der linken Ringecke: Sebastian mit Ubuntu „Intrepid“ (8.10) mit der standardmäßig mit ausgelieferten Desktop Sharing Software Vino (unter System -> Preferences -> Remote Desktop) sowie NetBeans (glaube 6.5). Damit das Desktop Sharing funktioniert, musste Sebastian seinen Router noch das Durchschleifen des RFB/VNC Traffics auf Port 5900 erlauben. Durchsatz maximal 448 kBit/s Upload
• In der rechten Ringecke: Windows XP und TightVNC version 1.3.9 (siehe http://www.tightvnc.com). Durchsatz maximal 6 MBit/s Download

Nachdem ich über Skype Sebastian nicht gehört habe, sind wir kurzerhand aufs Telefon mit Lautsprecher umgestiegen, was sich über die 3 Stunden auch gut bewährt hat. Nachdem mitunter der Bildaufbau etwas langsam anmutete, hat Sebastian zum Vergleich den TightVNC Server angeworfen. Mein Versuch sich mit diesem zu verbinden dauerte aber nur ganz kurz, da ich daraufhin nur psychedelisch anmutende Bilder in buntesten Farben zu sehen bekam. Also wieder zurück zu Vino, Ubuntus Standard Desktop Sharing Software.

Joo, und dann konnten wir schon loslegen. Prozesstechnisch nahmen wir uns vor, zweimal 50 Minuten zu programmieren und darauf jeweils eine 5 Minuten Retrospektive folgen zu lassen. Und nachdem uns Christoph von seiner letzten Programmier Session noch einen gebrochenen Test hinterlassen hatte, war auch bereits die Frage geklärt, welchen Punkt wir als Nächstes angehen würden.  Letztlich ging es um nichts anderes als eine korrekte Validierung von Eingabedaten mit Fehlerausgabe.

Klingt ganz einfach soweit. Dennoch haben wir uns in der ersten Iteration erst einmal komplett verrannt und standen am Ende vor Fehlermeldungen, die etwas sagen sollten, aber uns doch mehr verwirrten. Selbst eine parallel mittels Scaffolding hochgezogenen Anwendung und Durchsicht deren Quellcodes brachten uns nicht aus der Sackgasse.

Also Retrospektive: Während wir von der benutzten Infrastruktur recht angetan waren, schätzten wir unseren Entwicklungsfortschritt doch als zäh ein. So verdrängt Grails nicht Sebastians Haus und Hof Sprache Rails.

Was tun? Wir beschlossen, in der zweiten Iteration die gleiche Problemstellung in einem anderen Kontext zu lösen und warfen erst mal alle unsere Änderungen aus der ersten Iteration weg. Und siehe da, wir kamen dann wirklich Schritt für Schritt ans Ziel. Ja, es waren an mancher Stelle noch Details zu lösen. So scheiterten aufgrund der neuen Constraints erst mal noch mehr Tests. War aber auch klar, denn bis dato hatte testübergreifend noch keiner auf deren Einhaltung geachtet. Also hat Sebastian kurzerhand noch eine Setup Methode für jeden Test geschrieben, welcher den Datenbankinhalt vor jedem Test soweit zurücksetzte, dass alle wieder grün waren.

Abschließende Retrospektive: Zwar hatten wir unsere Time Box etwas überzogen, aber dafür waren wir in Fluss gekommen und konnten die vorgenommene Aufgabe wirklich abschließen. Grails läuft bei Sebastian zwar immer noch unter Bewährung, wir waren aber einhellig der Meinung, dass die Session wirklich Spaß gemacht hat und produktiv war.

Haben soeben noch einmal über Skype mit Sebastian telefoniert, nachdem er seine Einstellungen angepasst hatte. Jetzt habe ich ihn zwar gehört, aber mitunter höre ich dann doch mein Echo oder Sebastians Stimme fängt das Stottern an. Ich denke wir werden beim Telefon bleiben.

Fazit:

• Pairing mit Desktop-Sharing und parallelem Telefon auf Freisprechanlage funktionierte erstaunlich gut.
• Erst wenn man mal schnell etwas macht, war der Bildaufbau zu langsam. War aber nicht so oft der Fall, dass es bis dato wirklich störte.
• Bewährt hat es sich interessanterweise auch, auf einem zweiten Bildschirm parallel etwas suchen zu können, selbst wenn der Pairing Partner es nicht sieht.
• Interessant wird es, wie sich das Remote Pairing anfühlt, wenn die Verarbeitungsgeschwindigkeit steigt
• Hat Spaß gemacht und es wird interessant zu sehen sein, wie sich das Remote Pairing mit anderen Partnern funktioniert, insbesondere was sich gleich oder ganz anders anfühlt

Software macht man nicht „einfach“, indem man dem Fisch respektive dem Entwickler das Wasser vorenthält. Was ist das Wasser des Entwicklers? Es besteht aus den drei Dingen Kommunikation, Zeit, Selbstvertrauen.

Nun stellen Sie sich folgende Situation vor. Sie wollen einen neuen Mitarbeiter einstellen. Möchten ihn einschätzen. Wie würden Sie vorgehen? Richtig, Sie würden Fragen stellen. Nun hat es damit eine besondere Bewandtnis.

Sie können Fragen auf genau zwei Arten stellen. Zum einen können Sie versuchen, herauszufinden, was Ihre Leute nicht können, mit der Betonung auf dem „nicht“. Oder aber Sie versuchen zu verstehen, was sie können. Und was sie gern machen würden. Das ist ein himmelweiter Unterschied. Selbst wenn Sie eine vollständige Liste der Dinge besitzen, die Ihr neuer Mitarbeiter nicht kann: Was nutzt Ihnen das? Richtig. Nichts. Denn Sie haben immer noch nicht die geringste Ahnung, was er eigentlich so drauf hat. Oder weshalb er bei Ihnen arbeiten will – falls er das will. Um bei unserem Fisch zu bleiben, Sie bekommen heraus, dass er auf dem Tisch nicht richtig vorwärts kommt, dass er irgendwie mit der Atmung Probleme hat und vor allem: Das ihm Ihre Fragen relativ schnell relativ egal werden. Diese Art, mit Menschen umzugehen, hat keinen richtigen Namen, hingegen merken Sie das Ergebnis sehr schnell. Ihnen laufen die Leute weg, oder Sie bekommen erst gar keine, Ihr Projekt scheitert.

Der andere Ansatz hat hingegen viele Namen. Ressourcenorientiert. Herzblutgetrieben. Begeisterungsverursacht. Wertegetrieben.

Fragen Sie ihre Leute, warum sie etwas Bestimmtes machen wollen, warum Sie gerade bei Ihnen arbeiten wollen oder warum potentielle Mitarbeiter denken, für Ihr Projekt ein Gewinn zu sein. Versuchen Sie nicht, Ihre Mitarbeiter zu überrumpeln gemäß „Jetzt habe ich was gefunden, was Du nicht weiß – got you!“ Stress ist OK, aber er muss die Ausnahme sein. Im Projekt, und im Gespräch. Die Meinung, dass Stress normal wäre und über Monate vorkommen dürfe, führt direkt ins Verderben. Permanenter Stress ist kein Zeichen guter Arbeitsorganisation, er ist ein sicheres Indiz für schlechte und unbewegliche Projektleitung und inadäquaten Prozesse. Und Ausdruck einer Haltung, die mit „respektlos“ nur unzureichend beschrieben wäre.

Mit einem Wort: Entspannen Sie sich und Ihre Mitarbeiter. Vergessen Sie nie, dass die Art und Weise, wie Sie Fragen stellen, sehr viel über Sie selber aussagt. Und wer will schon bei einem Projektleiter arbeiten, dessen emotionaler Fingerabdruck dem eines Kampfpanzers gleicht?

Nein. Es ist sein Vermögen, sich fast jeder Situation sehr, sehr schnell anpassen zu können. Dieses Anpassungsvermögen hat ihn, zusammen mit seiner Sprachfähigkeit – schon klar, auch das gilt nicht für alle Exemplare – zum beherrschenden Wesen auf diesem Planeten gemacht.

Hingegen die Zukunft vorhersagen, das konnte er noch nie. Diejenigen, die das dennoch versuchen,  finden wir in den hinteren Winkeln der Jahrmärkte und Esoterikmessen, gebeugt von und über einer Kristallkugel, welcher sie die Zukunft zu entreißen versuchen. Das kann schon mal gut gehen, muss aber nicht.

Kristallprojekte kennen wir alle. Sie funkeln, sind rund und kühl, verführen zum tiefen Blick, den wir nur allzu gern als eine Zukunftsschau  interpretieren. Fällt die Kugel allerdings einmal etwas unsafter auf den Boden, zerspringt sie in tausende Splitter, an denen sich schon sehr viele die Finger aufgeschnitten haben.

Hingegen sind die anderen Projekte, die eher explorativer Natur sind, gänzlich ungefährlich. Das sei eine Übertreibung? Ist es nicht. Was verursacht Angst? Das Unbekannte, das erwartete Gefährliche.  Angst bekommen Sie also weg, wenn Sie Überraschungen der schlechten Art vermeiden. Kommunizieren Sie offen, face to the facts. Alle wissen alles. Alle kennen die Probleme, die Sorgen, die Chancen, die Risiken. Alle wissen immer, wo das Projekt steht. Das klingt nach Kommunismus? Nun, warum nicht. Wenn es dem Projekt und Ihnen hilft, führen Sie ihn ein, den Projektkommunismus, wo alles allen gehört. Insbesondere die Informationen.

Versuchen Sie nicht heraus zu finden, was morgen sein wird. Lassen Sie sich positiv überraschen, freuen Sie sich auf die nächste Ecke, hinter der eine neue Überraschung lauert. Und dann: Adaptieren Sie sich und machen Sie munter weiter. So gewinnen Sie die Menschen, und so gewinnen Sie die Projekte. Oder glauben Sie wirklich, dass sich die Evolution geirrt hat?

Nun, was scrum denn ist und was nicht, darüber wird noch zu reden sein. Aber was er bewirkt, darüber kann trefflich gesprochen werden: Scrum vertreibt den Schrecken aus Projekten, er ist ein Schreckensminimierer.  Welche genau? Also:

• Den Schrecken des Blindfluges:  Jeder Beteiligte weiß genau, wo das Projekt steht. Wenige einfache und übersichtliche Diagramme gestatten jederzeit, tatsächlich jederzeit, eine Aussage über den Projektfortschritt. Features sind entweder fertig oder nicht.  99% fertig ist auch „nicht fertig“. Die Welt wird wieder einfach; das ist wunderbar, weil die Projekte ja oft schwierig genug sind.
• Den Schrecken der Nichtsteuerbarkeit:  Durch kurze Feedbackzeiten und regelmäßige Rückkopplung mit den Entwicklern und den Kunden werden keine Features gebaut,
  die „niemand braucht“. Es kann schnell und effizient auf Änderungen der Anforderungslage reagiert werden.  Die Anforderungen leben, genau wie der Kunde und dessen Geschäft es auch tun.
• Den Schrecken des Ziegelsteins: Was passiert, wenn Meier morgen ein Ziegelstein auf den Kopf fällt? Scrum setzt Techniken aus dem XP ein, was z.B. dazu führt, dass sich alle Entwickler in jedem Code, zumindest prinzipiell, auskennen. Das macht Spaß, man kann viel voneinander lernen und auch viel entspannter in den Urlaub fahren.
• Den Schrecken der Frameworks: Ein Framework ist oft der erste Hinweis darauf, dass die Entwicklung nicht weiß, was sie machen soll. Mit scrum implementiert man Features, sonst nichts. In jeder Etappe einen Durchstich, ein Mehr an Funktionalität.
• Den Schrecken des Big Bang: Das Team verfügt zu jedem beliebigen Zeitpunkt der Entwicklung über ein auslieferbares Produkt. In der ersten Zeit hat dieses Produkt vielleicht nur 2 oder 3 oder 5% der geplanten Features. Aber diese Wenigen lassen sich bauen, laufen fehlerfrei, lassen sich verpacken und beim Kunden installieren. Der Kunde kann das Wachsen der Software hautnah verfolgen, kann frühzeitig reagieren. Schön für den Kunden, noch schöner für das Team.
• Den Schrecken der Verantwortungsdiffusion (ein netter Begriff aus der Verhaltensforschung): Teams vergessen die Schuldfrage. Sie fragen vielmehr nach Gründen für bestimmte Dinge, und wie man diese Abstellen kann. Sie übernehmen Verantwortung für Planung und Durchführung der Arbeiten.

Wenn also mal wieder jemand fragt, warum denn ausgerechnet scrum und warum jetzt und warum wir: Menschen, Dinge oder Prozesse, die den Schrecken verkleinern, sind zumindest nützlich. Wir sollte sie beachten. Denn: Man kann sich das Leben erleichtern. Aber man muss natürlich nicht.