Showing posts with label german. Show all posts
Showing posts with label german. Show all posts

Monday, 30 January 2017

Agilität und Effizienz

Ich habe in den letzten Wochen darüber nachgedacht, wie Agilität Effizienz fördert und sammle meine Gedanken in einem Artikel, den ich in einer der nächsten Ausgaben der agile review veröffentlichen möchte.
Ich veröffentliche den gegenwärtigen Stand hier vorab, weil ich hoffe, dass er bereits "gut genug" ist, um euch nützlich zu sein – und weil ich hoffe, durch euer Feedback die weitere Arbeit effizienter zu gestalten.


Agilität und Effizienz

von Urs Reupke

In den letzten Wochen bin ich umgezogen und renoviere jetzt die alte Wohnung. Viele Teilaufgaben führen mich durch Abende voll Beschaffung,Transport und Handwerk. Immer wieder frage ich mich abends: Hat sich das gelohnt? Habe ich effizient gearbeitet?
Daraus wuchs die Frage, was Agilität und Effizienz miteinander verbindet.

Thursday, 8 October 2015

Punkt, Punkt, Komma, Strich

Heute habe ich mich mit meiner Kollegin Anna Lorenz (@roadranna) über Daten und Punkte am Satzende unterhalten. Wieviele sind es? Und wann? Ein Ausflug in die Interpunktion.

Das Datum und der Doppel-Punkt

Auf den ersten Blick war die Frage einfach: Schreibe ich nach einem Datum am Satzende einen oder zwei Punkte?
Also:
Ich komme am 01.10..
oder doch lieber
Ich komme am 02.10.
Klare Frage, klare Antwort: Version zwei ist richtig.
Förmlich heißt das dann: "Am Ende eines Ganzsatzes setzt man nach Ordinalzahlen, die in Ziffern geschrieben sind, nur einen Punkt.." (§105 der amtlichen Rechtschreibregeln)

Abkürzungen und Ellipsen

Das aber ist natürlich nur die halbe Antwort, denn auch andere Fälle bringen Punkte vor den Punkt:

Abkürzungen zum Beispiel
Ich komme am 03. Okt.
und auch Ellipsen, etwa wenn ich laut nachdenke
Ich sollte am 04.10. kommen...
Wieder setzen wir keinen weiteren Punkt.
Förmlich: "Am Ende eines Ganzsatzes setzt man nach Abkürzungen nur einen Punkt." (§103 der amtlichen Rechtschreibregeln)
Zusammengefasst können wir also festhalten: Nach Punkten steht kein Punkt.

Satzzeichen mit und ohne Ende

Zum Glück aber ist nicht alles Punkt, was am Satzende steht, und da verhält sich die Sache anders:
Du kommst am 05.10.!
brüllt der Vater dem Sohn nach, wenn jener droht, der Mutter Geburtstag zu verpassen, und
Kommst Du am 06.10.?
fragen wir bei einer Einladung zu einem gemeinsamen Freund.

Genauso verhält es sich bei den schwächeren Satzzeichen Komma und Semikolon, beim Gedankenstrich und beim Doppelpunkt.

Wie geht's noch?

Jetzt hilft die schönste Regel nicht, wenn der Leser trotzdem darüber stolpert und sich wie wir heute fragt: "Ist das so richtig?"

Elegant und zweifelsfrei umschifft man das Problem mit ein paar Ziffern mehr
Ich komme am 07.10.2015.
oder einigen zusätzlichen Buchstaben
Ich komme am 08. Oktober.
Bei Abkürzungen stellt sich die Frage nicht mehr, wenn wir sie ausschreiben.

Tisch für zwei allein

Doch Vorsicht: Während der Vorschlag
Ich könnte am 09.10. kommen oder am 10.10.
leicht von der Hand geht, steht bei der langen Form
Ich könnte am 11. Oktober kommen oder am 12. Oktober.
sofort der innere Deutschlehrer hinter uns und mahnt die Doppelung an.
Schnell steht da
Ich könnte am 13. Oktober kommen oder am 14.
und wenn ich diese Zeile am 10. September schicken, dann wartet Anna vielleicht vergeblich auf mich.

Friday, 25 April 2014

Antifr-Agil

In der aktuellen Ausgabe der "agile review" sprechen Sandra und ich über Antifragilität.
Hier ist der erste Teil, dem im vollen Artikel eine Diskussion aus Sicht der Berater und weitere Gespräche folgen.
Interessiert er euch? Schreibt mir, ich schicke euch gern ein Exemplar der Zeitschrift!



Antifr-agil
Ein Dialog in 3 Teilen von Urs Reupke und Sandra Reupke-Sieroux

Erstes Gespräch: Antifragilität

Die Schildkröte hat es sich im Schatten eines Baumes bequem gemacht, den Achill unruhig umschreitet.

Achill: “Welch Trick! Um der Schmach der Niederlage zu entgehen, greifst Du zu Mitteln, Panzertier, die Deiner unwürdig sind! Doch höre: Die Götter sollen den Gleichstand entscheiden. Heb Deine Fäuste, Reptil!”

Schildkröte: “Kampf, Kampf, stets höre ich Kampf. Eines Tages wird Deine Zeit vergehen, mein Freund, wenn einer kommt, Dich zu besiegen.”

Achill, aufgebracht: “Hektor schlug ich, Trojas größten Helden! ‘Unbesiegbarer Achill’ haben sie gerufen! Keinen Kampf habe ich je verloren, und schwach reden wirst Du mich nicht.”

Schildkröte: “‘Unbesiegt’ jubelten sie, nicht ‘unbesiegbar’. Früher oder später kommt eine Zeit, in dem Dein Alter Dir das Kriegshandwerk verbietet. Was dann?”

Achill darauf: “Dann musiziere ich! Cheiron lehrte mich die Laute!”

Tönt es aus dem Schnabel der Schildkröte: “Nein, dann stirbst Du. Der Feind kennt keine Gnade! Ein größerer Verlust ist undenkbar, und wie begrenzt der Gewinn: Eine Stadt, ein Königreich, und wenn sie ein Juwel ist wie das vielbesungene Troja - ein Fehltritt, und anstelle ihrer Schätze erblickst Du die elysischen Felder. Nimm allein Deine Ferse…” ﹣ “Sprechen wir nicht darüber!” ﹣ “Deine Verse! Dein Lautenspiel! Harmonielos wie es auch sein mag, birgt es doch ungleich weniger Gefahr. Wer weiß, wes gönnerhaftes Herz Du regst, wenn Du den rechten Ton anschlägst! Alles, was Du wagst, ist ein Abend mit knurrendem Magen, doch der Lohn, süßer Lohn! Welch Reichtümer könnten Dich erwarten, welch Ehre könnte Dein sein.

Jeder Abend, jede Nacht bietet Dir eine neue Gelegenheit, einen neuen Wurf, Unsterblichkeit zu erlangen!”

Kommentar: Was ist antifragil?

“Antifragilität” charakterisiert Systeme, die von zufälligen Ereignissen profitieren, anstatt wie “fragile” Systeme darunter zu leiden oder ihnen indifferent gegenüber zu stehen, wie es “robuste” Systeme tun.

Nassim Nicholas Taleb, Spekulant und Philosoph, beschrieb das Konzept 2012 in seinem gleichnamigen Buch [3]. Er zeigt darin auch eine Reihe weiterer Eigenschaften, die solche Systeme ausmachen - Eigenschaften, zu denen die Schildkröte Achills Leben verhelfen möchte.
Ihr Rat beherzigt den Grundsatz antifragiler Systeme: [Weiter gehts in agile review 01/2014]
Schreib mir und ich schick Dir!

Tuesday, 25 March 2014

Der Agile Entdecker

Gemeinsamer Post mit Sandra Reupke-Sieroux und Olaf Lewitz:

Cover Image: The People's Scrum
Bei der play4agile 2014 hat Olaf mir erzählt, dass er schon eine Weile daran sitzt, Tobias Mayers Buch "The People's Scrum" ins Deutsche zu übertragen. Im Gespräch am Abend hat er mich und Sandra eingeladen mitzumachen. Alan Cyment, der an der spanischen Version arbeitet, gab uns drei einen Haufen Tips, und seitdem arbeiten wir daran.

Wir wollen in den nächsten Wochen einige der Essays vorab veröffentlichen - das Buch ist ja aus einem Blog entstanden. Auch für die deutsche Version sind wir gespannt auf euer Feedback!

"Der Agile Entdecker" haben wir als ersten gemeinsamen Post ausgewählt, weil es der Essay im Buch war, bei dem wir unsere gemeinsame Sprache gefunden haben. Wie viele seiner Essays vereint er Kritik an einem bekannten und verbreiteten Konzept mit einer neue Idee - gerade ausreichend skizziert, um sich inspirieren zu lassen. Tobias sagt uns nicht, was wir tun sollen. Er öffnet unser Herz und unseren Verstand für Neues, manchmal Radikales.

Viel Spaß beim Lesen! Habt ihr Agile Entdecker im Unternehmen? Habt ihr so was schon mal gemacht?

Der Agile Entdecker

Während eines Projekts in Indianapolis unterhielt ich mich mit einem Entwickler.
“Was weißt Du über Atomkraft?” fragte er mich, und erzählte dann, dass er in einem Atomkraftwerk gearbeitet habe. Dort erfuhren alle Arbeiter regelmäßige Schulungen über die Sicherheitsbestimmungen, sogar noch nach langjähriger Anstellung.

Die beste Absicherung gegen eine Kernschmelze sei, sagte er, die Köpfe der Kollegen stets durch aktuelle Erkenntnisse und häufige Erinnerungen an gutes Vorgehen wach zu halten.

Er fragte mich, warum agile Ausbildungen nach einem Durchgang vorüber wären. Er habe in verschiedenen Organisationen während der agilen Transition beobachtet, dass die Leute nach dem Training gut voran kamen und voller Wissen und Begeisterung steckten, diese Energie jedoch schnell verebbte und das gewohnte Verhalten zurückkehrte.

“Auch Softwarefirmen schmelzen”, stellte er fest.

Daraufhin hab ich mich damit beschäftigt, wie Firmen Scrum einführen und verwalten. Die meisten heuern für eine kurze Zeit Berater oder Trainer an.

Die Engagierteren unter ihnen besorgen sich einen Scrum Master, der von einem der zahllosen Verbände zertifiziert ist - im festen Glauben, das Zertifikat gewähre Qualität. Beide Ansätze erreichen dieses Ziel selten.

Hin und wieder habe ich den Gedanken, dass der Begriff des “Scrum Masters” die Agile Bewegung aufhält, dass diese Position die Selbstorganisation behindert. Zwar ist die Absicht gut, doch in der Praxis wird die Rolle viel zu oft herabgewürdigt zum Metriksammler, zum Prozesswachhund, im schlimmsten Fall sogar zur Scrumpolizei oder zum agilen Projektmanager.

Dadurch entreißt man dem Team Verantwortung, und die Menschen unterwerfen sich dem Prozess, der ihnen aufgebürdet wird.
Tobias Mayer

In den letzten zwei Jahren ist die Rolle des Scrum Masters in meinen Kursen immer mehr in den Hintergrund getreten. Ich beschreibe Scrum als die Beziehung zwischen Product Owner und Team und erforsche diese Beziehung in Hinblick auf Teamkultur, Fokus, gemeinsame Ausrichtung und Zusammenarbeit.

Scrum verspricht engagierte Teams und glückliche Kunden, aber dieses Versprechen löst das Problem der Kernschmelze nicht. Die Organisation muss nach wie vor einen nachhaltigen Weg finden, um kontinuierliche Verbesserung rund um die Grundprinzipien des Scrum-Frameworks zu etablieren.

Scrum Master sind dieser Weg nicht, denn Scrum Master sind stets auf den untersten Rängen des hierarchischen Totempfahls angesiedelt. Häufig müssen sie einer Projektmanagementabteilung Rede und Antwort stehen oder einem Entwicklungsleiter. Sie haben wenig Autonomie und werden oft zu Helfershelfern des Status Quo.

Auch agiles Coaching ist nicht der Weg. Coaching hilft Einzelnen und Teams sich selbst zu verwirklichen, doch wie bei einer Therapie kommt der Moment, an dem der Coachee die Beziehung beenden muss. Tut er es nicht, läuft er Gefahr, sich mit seinem Coach im Kreis zu drehen und gemeinsam eine ungesunde Beziehung gegenseitiger Abhängigkeit zu schaffen.

Der Weg scheint mir zu sein, Agilität in die DNS der Organisation zu injizieren. Wir wissen, dass Viren die DNS von Organismen verändern können, wenn sie nur stark genug sind, die Antikörper des Wirts abzuwehren. Um die Kultur der Organisation zu verändern, brauchen wir genau so ein Virus.

Daher möchte ich eine neue Rolle vorschlagen, um das Virus zu verbreiten: Den Agilen Entdecker. Diese Rolle ist anders als die des “Paten der Agilität”. Der Pate ist jemand - häufig ein Geschäftsführer oder der Chef der Entwicklungsabteilung - der sagt: “Jetzt aber agil!”, aber der weder versteht, welcher Änderungen in der Organisation dieser Schritt bedarf, noch die Zeit hat, sich auf wirkliche Veränderung einzulassen.

Der Agile Entdecker ist jemand, der auf der Suche nach Wissen in unerforschtes Land reist. Er oder sie ist ein Visionär und ein furchtloser Abenteurer, der durch seine Handlungen andere inspiriert selbst aufzubrechen.

Agiler Entdecker ist ein Vollzeitjob. Am besten ist es, wenn er niemandem unterstellt ist, doch wenn es sein muss, dann sollte er der Geschäftsführung berichten, und zwar in einer autonome Position, deren Leistung nicht gemessen wird.

Es ist nicht die Aufgabe des Entdeckers, Teams zu coachen oder anderen zu helfen, besser mit Scrum umzugehen.

Er oder sie soll zuhören, denken, inspirieren, konfrontieren, anheizen, herausfordern und die kollektiven Augen der Organisation öffnen, damit sie neue Möglichkeiten erblicken können. So sät er die Saat eines neuen Seins.

Ein guter Agiler Entdecker bringt sich in die agile Gemeinschaft außerhalb seiner Firma ein, nimmt an Veranstaltungen teil, diskutiert online, liest ausgiebig, lernt Neues und fördert den Dialog mit anderen Organisationen und Individuen. Er sorgt für den Austausch im Haus, begründet Gesprächsrunden und Workshops und fördert Ideen rund um experimentelle Verbesserung.

Insbesondere aber ermutigt er andere, es ihm gleich zu tun.

Der Agile Entdecker webt aus Silos und Hierarchien faszinierende Werke kinetischer Kunst, die Ehrfurcht und Erstaunen erwecken. Diese Umgebungen lassen Selbstorganisation gedeihen; gegenseitiges Coaching floriert und ersetzt teure Hilfsarbeiter, die sich nicht ums Ergebnis scheren. Das Engagement wird stärker, die Freude wächst - und die Kernschmelze bleibt aus, Tag um inspirierten Tag.

Tobias Mayer, 19. April 2012

Sunday, 23 March 2014

Respite and Trust in Timeboxes

Looking for a proper translation for the concept of a "time-box" in the context of Scrum, I looked up the German word "Frist". The word describes a period of time in which a certain action may (or may not) be taken, it's mostly used in a judicial context.

Inspired by a note on the words roots in Old High German, I consulted Wiktionary, and discovered that the word has siblings in several Germanic languages and is known even in English (albeit obsolete).

I was delighted by the connotations on offer: Throughout the languages, the concept denotes not only an allowance of time, but also signals a respite or truce as well as trust - all of which are on display when mutually agreeing on a time-box in Scrum.

I couldn't wish for a better match.

Monday, 11 November 2013

Varoufakis on Valve: Hire and Fire

Yanis Varoufakis, ein griechischer Wirtschaftswissenschaftler, hat vor einiger Zeit mit econtalk gesprochen - es ging vor allem um seine Arbeit mit Valve.
Im zweiten Anlauf, euch zu erzählen, was ich gehört habe, verwerfe ich die Idee, ein blow-by-blow zu schreiben und sortiere meine Gedanken lieber thematisch in mehrere Artikel.
In diesem ersten dreht es sich um Anstellungsverhältnisse und Vergütung, in einem weiteren wird es um die managerlose Organisation gehen.

Den ganzen Podcast (60+ Minuten) gibt es hier.

Hire and Fire

Das erste Thema nach der Vorstellung aller Akteure war der Anstellungsprozess und das Gehalt. Wie stellt ein anarchosyndikalistischer Laden ohne willige Manager neue Leute ein?

Anstellungen, erzählt Varoufakis, finden statt, wenn Mitarbeiter in einem Projekt Bedarf nach einer Fähigkeit haben, aber niemanden in der Firma finden, der mit ihnen zusammenarbeiten will.
Sie treffen sich mit interessanten Leuten, das ganze dauert durchaus einen Tag pro Person - und währenddessen diskutiert und entscheidet die ganze Firma online mit, so dass jeder Einfluss auf die Entscheidung nehmen kann.

Das Gehalt entsteht genauso: Das Gehalt, dass man bei der Einstellung vereinbart, sei nur ein kleiner Teil, sagt er - viel entscheidender der Bonus, der ohne feste Obergrenze von den Mitarbeitern untereinander in einem "complicated peer review process" festgelegt wird. Weit später fügt er noch ein interessantes Detail hinzu: Bei der Bonus-Bestimmung darf niemand für sich selbst stimmen:

"Das ist das einzig Gute, was uns der Eurovision Song Contest gelehrt hat."

Das Resultat ist, dass jeder bekommt, was die anderen für fair erachten - und das ist in Ordnung, denn die Mitarbeiter respektieren sich untereinander

5-6fache des Grundgehalts sei nicht unerhört, sagt Varoufakis dazu, und später merkt er an, dass aus seiner Sicht die Einkommensverteilung beinahe sozialistisch sei - er meint, dass niemand nur aufgrund seiner Position bezahlt werde, sondern das Geld vom Verdienst abhängt. 

Und was, wenn jemand gehen soll?

Varoufakis konzentriert sich in seiner Antwort auf den Umstand, dass Kollegen nicht mit der führerlosen Umgebung klarkommen - und das kommt wohl immer wieder vor.
Dann folgt eine Reihe von Gesprächen, mit dem Ziel, eine Übereinkunft zu finden - mein Verständnis war, dass sich Valve dabei bemüht, den Mitarbeiter zu behalten, aber das hat er so klar nicht gesagt.
Wenn sonst keine andere Option bleibt, will man wenigstens Freunde bleiben und schnürt ein attraktives Abfindungspaket.

Und ungenügende Leistung, gar Drückebergertum? Erlaubt die Organisation, dass ich mich verstecke und zum Beispiel in keinem der Teams richtig mitmache?
Nein, sagt er, das kommt nicht vor. Wer durch das System fällt, fällt auf.

Allerdings sei das selten ein Problem, denn jeder Mitarbeiter sei "hand-picked to be an asset."
Das find ich toll - bist Du das auch, ein "asset" für Deine Firma? Was braucht es, um das zu sein?

Überrascht Dich irgendetwas von dem, was er erzählt? Was, und warum?
Was kann Deine Firma daraus lernen und für sich adaptieren?

Ich freue mich auf Deinen Kommentar!

Retrospektiven über Distanz

Kürzlich habe ich für einen Kunden eine Retrospektive für ein verteiltes Team moderiert.
Ich habe ein paar Dinge gesehen, die ich vorher nicht erwartet habe - das habe ich gelernt:
  • Hope for the best, expect the worst
    Nur weil Dir eine Videokonferenz versprochen wird, heißt das noch lange nicht, dass auch eine Videokonferenz stattfindet.
    Sei darauf vorbereitet, dass Du zeitweise mit einem Telefon als einzigem Kanal auskommen musst.
  • Such Dir einen Partner auf der anderen Seite
    Für den Fall, dass die Verbindung zusammenbricht oder falls eine Erklärung schwierig ist; für den Umgang mit der Technik im Allgemeinen: Wähle Dir einen Partner auf der anderen Seite, der mit Dir zusammenarbeitet. Er muss nicht alles selbst können; aber er muss wissen, wen er Fragen kann.
    Er ersetzt Deine Augen und zum Teil auch Deine Ohren auf der anderen Seite und kann Dir klar sagen, wenn die andere Seite etwas braucht, was Du über das Telefon nicht mitbekommen hast.
  • Prüfe, dass Dein Werkzeug läuft (Vielen Dank an meinen Kollegen Stefan Roock!)
    Kein Video heißt: Kleine Klebezettel. Es muss Ersatz her.
    Es gibt einige Tools, die dabei helfen können – CardMeeting, GroupMind und PadLet und habe ich mir angesehen – aber das ist alles nutzlos, wenn Regeln oder Infrastruktur Dir verbieten, diese Werkzeuge auch einzusetzen.
    Bitte Deinen Partner, Dein Werkzeug vorher zu prüfen.
    Wenn es nicht geht, such Dir eine Desktop-Sharing-Lösung und lass z.B. PowerPoint darin laufen, das ist besser als nichts.
  • Zuhören ist anstrengend
    Es ist sehr anstrengend, die ganze Zeit dem Telefon zuzuhören, und alle Beteiligten sind froh, wenn Sie für einen Moment “normal” reden können.
    Das heißt:
  • Verlass Dich auf (mehr) Gruppenarbeit
    Visuelles Arbeiten ist durch den schmalen Kanal schwer, auch wenn Du ein gutes Werkzeug hast. Jede Seite kann es aber doch – für sich, in Gruppen.
    Trag die Ergebnisse hinterher in Deinem Werkzeug zusammen, und sei darauf vorbereitet, dass ihr mehr als üblich darüber sprechen müsst:
  • Es dauert länger, als Du glaubst
    Die schmale Verbindung hindert Dich und die Teilnehmer daran, während der Gruppenarbeit etwas von der anderen Seite mitzubekommen. Osmotische Kommunikation ist damit abgesagt, und einzelne Punkte werden mehr Fragen und Kommentare mit sich bringen, als Du es erwartest.
    Sprecht ihr nicht in eurer Muttersprache, erwarte noch mal mehr.
    Das bringt zwei weitere Punkte mit sich:
  • Erklären, Erklären, Erklären
    Normalerweise kriegst Du leicht mit, wenn jemand etwas nicht versteht und noch nicht bereit für eine Aktivität ist – hier nicht.
    Dummerweise wirst Du auch weniger Fragen vorab kriegen – und vermutlich erst recht keine währenddessen.
    Sei in Deiner Erklärung ausschweifend bis es Dir Kopfschmerzen bereitet.
  • Erwarte andere Kultur
    Anders als bei einer Retro in einem Raum hast Du wenig Einfluss auf einen Teil Deiner Teilnehmer. Rechne damit, dass Du eine Pause nicht mit Deinem Gong beenden kannst, erwarte, dass Pünktlichkeit zum Abschluss der Übungen nicht so hoch geschätzt, wie Du es gewohnt bist.
    Wenn es am anderen Ende länger dauert, dauert es (einen Moment) länger.
Was sind eure Erfahrungen mit verteilten Retros?

Tuesday, 8 May 2012

Ein Test ohne Assert

Daniel Minigshofer von it-agile schreibt über Test-Antipatterns und macht Vorschläge zum besseren Umgang mit Exceptions. Dabei schreibt er:
Es wäre auch möglich ohne eine Assert-Anweisung diesen Test zu schreiben. Jedoch einen Test ohne Assert ist kein wirklicher Test. Außerdem ist es für andere Entwickler nicht ersichtlich was hier eigentlich getestet wird.
Leider geht er nicht weiter darauf ein, und lässt mich allein mit dem Sesamstraßen-Dreiklang: "Wieso? Weshalb? Warum?"

Science to the rescue!

Thursday, 27 October 2011

Reviewed 'Agile Entwicklungspraktiken mit Scrum'

Another review, this time for Stefan Roock's and Roman Pichler's new book on amazon.de. Once more, both book and review are in German.

I really liked the book. It helped think about things I had long taken for granted. 4/5.

Once again, if you want my copy, just tell me and it is yours.

Wednesday, 5 October 2011

Reviewed 'Agile Developer Skills'

I published a review of Christoph Mathis' and Andreas Wintersteiger's new book 'Agile Developer Skills' on amazon.de. Both the book and the review are in german.

Bottom line: It's a good - if somewhat flawed - introduction to all things agile. 3/5

If you want my copy (and maybe write a review yourself?) leave me a message.