1. Entwickler:innen sind Techniker, sie sollten technische Aufgaben haben

Der Alltag vieler Entwickler:innen sieht leider vollkommen anders aus. Sie müssen an Meetings teilnehmen, bei denen Erkenntnisgewinn und Zeitaufwand häufig in keinem akzeptablen Verhältnis stehen. Zudem sind oftmals Reports zu erstellen oder es soll minutiös protokolliert werden, wofür sie ihre Zeit aufwenden – unter Umständen gar in mehreren unterschiedlichen Erfassungssystemen. Hin und wieder werden erfahrene Entwickler:innen auch gebeten, in Einstellungsgesprächen dabei zu sein. All diese Aufgaben mögen einzeln betrachtet sicherlich ihre Berechtigung haben. Unterm Strich bedeuten sie jedoch einen erheblichen Zeitaufwand, der im Umkehrschluss zu Zeitmangel und Drucksituationen bei der Entwicklungsarbeit führt. Solche Tätigkeiten sollten daher nur einen geringen Teil der Arbeitswoche ausmachen, der überwiegende Anteil der Arbeitszeit jedoch für technische Aufgaben zur Verfügung stehen, nicht umgekehrt.

DIE DIGITALE TRANSFORMATION STARTEN

Mehr Talks zu Agile, People & Culture

Agile werden

2. Entwickler:innen möchten nicht ständig mit veralteter Technologie arbeiten

Entwickler:innen gehen auf Konferenzen, tauschen sich aus und sie lesen Magazine. Dort erfahren sie, welche tolle neue Technologien es gibt und woran andere Entwickler:innen arbeiten. Um Frust zu vermeiden, ist es wichtig, allen Entwickler:innen zu ermöglichen, zumindest punktuell auch neue Technologien einzusetzen. Es gibt unterschiedliche Strategien, wie das erreicht werden kann. Bei der Entwicklung von Microservices-Architekturen oder der Aufspaltung von Monolithen ist es beispielsweise möglich, einzelne Services oder Module in neuen Technologien zu implementieren. Unabhängig davon ist es ohnehin wichtig, keine zu großen technischen Schulden aufkommen zu lassen und auch in Wartung befindliche Anwendungssysteme regelmäßig zu modernisieren.

3. Entwickler:innen sollten auch Neues entwickeln, nicht bloß bestehende Systeme warten

Eine noch immer recht verbreitete Unternehmensstrategie besteht darin, neue Systeme von externen Mitarbeitern oder Dienstleistern entwickeln zu lassen, weil diese vermeintlich das nötige Know-how mitbringen. Die Wartung bestehender Systeme geschieht dagegen durch angestellte Entwickler. Das führt früher oder später zu Unzufriedenheit, da es verständlicherweise nur wenig Freude bereitet, immer nur erweitern und reparieren zu dürfen, was andere hinterlassen haben. Der kreative Aspekt der Softwareentwicklung, das Erschaffen neuer Architekturen und Lösungen, geht für diese Entwickler:innen somit fast vollständig verloren. Im Grunde offenbart ein solches Vorgehen bloß, dass in der Vergangenheit versäumt wurde, die eigenen Mitarbeiter fortzubilden. Ein deutlich besserer Ansatz besteht darin, neue Systeme von gemischten Teams entwickeln zu lassen. Idealerweise bestehen diese Teams sogar überwiegend aus eigenen Entwickler:innen, die nur punktuell durch externes Know-how unterstützt werden. Somit sind angestellte Entwickler:innen von Beginn an in die Entwicklung derjenigen Systeme eingebunden, die sie anschließend über längere Zeit warten müssen. Es entsteht zudem ein bestmöglicher Know-how-Transfer.

4. Entwickler:innen sollten ihre Tools selbst wählen dürfen

Das gilt insbesondere für die IDE. Wenn Tools wie Maven oder Gradle für Builds verwendet werden, ist es letztlich gleichgültig, welche IDE die einzelnen Entwickler:innen einsetzen. Der verbreitete Einwand, dass für gewisse IDEs Lizenzierungskosten anfallen, während andere kostenlos einsetzbar sind, ist zu kurz gedacht. Zum einen sollte es Grund zur Sorge sein, wenn die üblicherweise dreistelligen Lizenzkosten für IDEs vom Arbeitgeber nicht aufgebracht werden können. Noch viel wichtiger aber ist das Argument, dass die Effizienz, mit der Entwickler:innen arbeiten, deutlich höher zu bewerten ist. Berücksichtigt man die Lohnkosten von Entwickler:innen, ergeben sich erhebliche Einsparungen, falls diese mit der von ihnen bevorzugten IDE auch nur fünf bis zehn Prozent schneller arbeiten können als mit einem Konkurrenzprodukt. Es ergibt daher wirtschaftlich wenig Sinn, an eventuellen Lizenzierungskosten zu sparen.

5. Entwickler:innen brauchen schnelle Hardware

Das bedeutet: schnelle Entwicklungsrechner mit ausreichend RAM und schneller Festplatte. Equipment, das bremst, etwa durch langsam laufende Builds oder Tests, ist letztlich deutlich teurer. Doch auch die Performance der Services, die Entwickler:innen täglich nutzen, ist von großer Wichtigkeit. Hierzu zählen etwa Git, Maven oder Docker Repositories, Build-Server, Datenbanken und das Netzwerk. Sind diese langsam oder weisen sie mangelnde Stabilität auf, werden Entwickler:innen unnötig ausgebremst. Erneut gilt: Multipliziert man die Anzahl der Entwickler:innen mit Arbeitstagen und Wartezeiten, können erhebliche Kosten zusammenkommen. Diese sollten eher in die Verbesserung der Infrastruktur investiert werden.

The post Developer Experience (DX): Der Weg zu glücklichen Entwicklern appeared first on JAX.

Daniel has been thinking about this for a long time, especially since he poked a stick at the SOLID principles for fun a few years ago and people came after him with pitchforks. Now he has codified his thoughts into his own pithy five-letter acronym, CUPID: Composable, Unix philosophy, Predictable, Idiomatic, Domain-based. Why these characteristics, what do they mean, and why should you care? Can they improve your coding experience or is this just more programmer navel-gazing?

The post CUPID ‒ for joyful coding! appeared first on JAX.

Artur Margonari berichtet in seiner Keynote aus seinem reichen Erfahrungsschatz als Agile Coach, Trainer und Moderator von Unternehmenstransformationen. In seiner Session untersucht er Erfolge, Fallstricke und Fehlschläge, teilt seine prägenden Schlüsselerfahrungen mit uns und verrät originelle Ideen zur Transformation von Teams und Unternehmen. Er zeigt auch, welche Auswirkungen guter Kaffee auf die Kultur einer Organisation haben kann. Wohl bekomm’s!

The post Die Unternehmenskultur transformieren – mit gutem Kaffee? appeared first on JAX.

Redaktion: In der Agilen Software-Entwicklung ist Kommunikation ein zentraler Bestandteil. Was nun aber, wenn man von der Persönlichkeit her eher nicht wirklich der Mitteilsambedürftigste ist? Oder anders gefragt: Ist Agile nur was für Schwätzer?

Mir ist wichtig, dass alle, die etwas beitragen wollen, den nötigen Raum dazu finden.

 

Katrin Rabow: Ich glaube, ein gutes Team entsteht gerade durch die Mischung der „Schwätzer“ (im positivsten Sinne!) und der ruhigeren Mitglieder. Während die einen schnell viele Ideen in den Raum werfen – und viele auch wieder VERwerfen – lassen die anderen sich Zeit, denken in Ruhe nach und bringen dann oft nochmal ganz andere Aspekte in die Diskussion ein. Mir ist wichtig, dass alle, die etwas beitragen wollen, den nötigen Raum dazu finden und in ihrem eigenen Tempo agieren können.

Redaktion: Du greifst in deiner Session ja ein wichtiges Thema auf, nämlich, wie sich Introvertiertheit und Agilität miteinander vereinen lassen. Ist es aus deiner Sicht schlicht ein Vorurteil, dass Agilität und Introvertiertheit Gegensätze sind? Oder gar: Sind Introvertierte nicht vielleicht sogar die besseren Agilisten?

Katrin Rabow: Die Beschäftigung mit dem Thema begann für mich tatsächlich mit der Frage, wie die klassischen Nerds (große Vorurteilsschublade auf!), die sich vermeintlich mit einer Pizza an einem Rechner im Keller verschanzen, damit umgehen, dass sie nun immer mit ihrem Team zusammensitzen und auch noch kommunizieren sollen. Ich habe aber schnell gemerkt, dass starre Definitionen und der Versuch, Menschen irgendwo einzuordnen, nicht zielführend sind. Am Ende geht es nicht darum, introvertierte und extravertierte Menschen miteinander zu vergleichen oder gar zu entscheiden, wer der bessere Agilist ist. Das Ziel sollte vielmehr sein, ein Arbeitsumfeld zu entwickeln, das allen gerecht wird.

Lesen Sie auch: IT-Forensik: „Software kann Tatort oder Tatmitttel sein”

Redaktion: Wie schafft man es, in einer gemischten Gruppe mit gemischten Persönlichkeiten ein solches Arbeitsumfeld zu erzeugen?

Diese Vielfalt ist auch eine große Herausforderung an die Unternehmen.

 

Katrin Rabow: Leider ist es in der Realität oft schwierig, all das umzusetzen, was ich mir wünschen würde. Und natürlich gibt es auch nicht DIE perfekte Umgebung, sondern immer nur eine mögliche Welt, die einem bestimmten Team gut tut. In meiner Session werden wir gemeinsam so eine Welt entwerfen – in der nächsten Session mit anderen Teilnehmern kann sie schon wieder ganz anders aussehen. Und genau diese Vielfalt ist natürlich auch eine große Herausforderung an die Unternehmen.

Redaktion: Welcher Trend oder welche Praktik im Bereich der Agilität findest du momentan besonders spannend? Hast du da vielleicht einen Tipp, womit man sich einmal etwas genauer beschäftigen könnte?

Katrin Rabow: Leider finde ich jede Woche ein neues spannendes Thema und würde mich gerne mit sehr vielen Ideen viel intensiver beschäftigen. Momentan steht aber vor allem die Beschäftigung mit dem “Domain Storytelling” ganz oben auf meiner Liste.

Redaktion: Was ist die Kernbotschaft deiner Session, die jeder Teilnehmer mit nach Hause nehmen sollte?

Katrin Rabow: Teams leben von ihrer Vielfalt. Wir sollten nicht versuchen, die einzelnen Mitglieder in Schubladen zu stecken, aber Verständnis für unterschiedliche Bedürfnisse entwickeln, damit jeder entsprechend seiner Persönlichkeit zum Teamerfolg beitragen kann.

Redaktion: Vielen Dank für dieses Interview!

The post Passt Agilität zu introvertierten Menschen? appeared first on JAX.

Gebrauchsanweisung für das Gehirn

JAX: Du gibst auf der JAX – eine Konferenz für Software-Entwickler – eine Gebrauchsanweisung für das Gehirn. Eine Provokation! Weshalb brauchen gerade Software-Entwickler eine Gebrauchsanweisung fürs Hirn?

Kreative Ideen kommen selten am Schreibtisch.

Jens Bendisposto: Wie in jedem Beruf sollten wir die Werkzeuge kennen, mit denen wir arbeiten ;-). Nur, weil wir alle unser Hirn täglich benutzen, heißt es noch lange nicht, dass wir das auch effizient machen!

Versuch’ dich mal daran zu erinnern, wo du das letzte Mal einen kreativen Gedanken hattest. Ich vermute, die Antwort ist sowas wie “beim Joggen”, “unter der Dusche”, “im Auto auf dem Weg ins Büro” oder vielleicht sogar “nachts im Traum”. Es ist verhältnismäßig selten der Fall, dass kreative Ideen am Schreibtisch kommen und schon mal gar nicht, wenn wir am Rechner arbeiten.

Dafür gibt es einen Grund: Kreative Ideen entstehen nicht beim bewußten, analytischen Denken. So komisch es klingt: Um ein schwieriges Problem zu lösen, müssen wir es zuerst verstehen und dann loslassen und unserem Gehirn Zeit geben. Wenn wir uns bei unserer Arbeit nicht die Zeit nehmen (oder einfordern), um ein Problem auch mal sacken zu lassen, dann vergeuden wir einiges an Potential.

JAX: Du stellst in deiner JAX-Session gehirngerechte Methoden und Techniken vor, mit deren Hilfe wir uns unseren Entwickleralltag vereinfachen können. Kannst du einmal ein Beispiel geben?

Jens Bendisposto: Ich möchte nicht meinen Vortrag spoilern, aber ich glaube, eine Technik kann ich dir schon mal verraten. Es gibt die Redensart “Wer schreibt, der bleibt”. Und es ist wirklich faszinierend, wie sehr uns das Aufschreiben helfen kann.

Du kannst das sehr einfach ausprobieren. Schreib’ einfach für ein paar Wochen “Morning Pages”. Dazu schreibst du jeden Morgen direkt nach dem Aufwachen noch vor dem Morgenkaffee drei Seiten handschriftlich auf. Denk nicht zu sehr darüber nach, ob das, was du schreibst, gut oder schlecht ist. Lass einfach den Stift gleiten und schreib auf, was dir durch den Kopf geht. Die Morning Pages sind nur für dich, du brauchst nicht zu filtern, was du schreibst. Wenn du das zwei oder drei Wochen lang konsequent machst, wirst du feststellen, dass kreative Ideen auftauchen.

Mittel gegen die Aufschieberitis

JAX: Du sprichst auch das Thema Prokrastination an. Sind Software-Entwickler hier besonders anfällig?

Prokrastination führt dazu, dass wir nicht mehr genug Zeit haben, kreative Lösungen zu finden.

Jens Bendisposto: Ich weiß nicht, ob wir als Softwareentwickler besonders anfällig sind, aber ich bin es auf jeden Fall. Und ich kenne wahnsinnig viele andere, die auch von Aufschieberitis geplagt werden. Prokrastination ist ganz besonders dann ein Problem, wenn der verursachte Zeitdruck dazu führt, dass wir tatsächlich nicht mehr genug Zeit haben, kreative Lösungen für Probleme zu finden.

Ich beobachte das an der Uni: Studierende setzen sich häufig nicht rechtzeitig mit ihren Aufgaben auseinander. Das führt dann zu durchgearbeiteten Nächten kurz vor der Deadline und viel Frustration. Auch die Ergebnisse sind dann oft nicht so toll, weil die Kreativität dabei zu kurz kommt.

JAX: Welche Mittel gibt es dagegen?

Jens Bendisposto: Ultimativ müssen wir uns überwinden, es gibt aber ein paar Techniken, die es leichter machen. Ein Grund für Prokrastination ist das Gefühl der Überforderung mit einer Aufgabe. Wir haben diesen Riesenberg Arbeit vor uns und wissen gar nicht, wie wir den überwinden sollen. Hier kann die Pomodoro-Technik helfen.

Ein Grund für Prokrastination ist das Gefühl der Überforderung mit einer Aufgabe.

Die Technik ist super einfach: Alle Ablenkungen (Mail, Handy, Social Networks) ausstellen und 25 Minuten am Stück konzentriert und ablenkungsfrei an einer Sache arbeiten. Nach ein paar Minuten konzentrierter Arbeit an einem Thema stellt man fest, dass es gar nicht so schlimm ist.

JAX: Du hältst deinen Talk ja im Rahmen des Agile Day. Was hat agile Softwareentwicklung mit dem Thema zu tun?

Jens Bendisposto: Bei agiler Softwareentwicklung geht es meiner Ansicht nach darum, Lernen als Teil des Entwicklungsprozesses zu akzeptieren. Insofern glaube ich, dass es ziemlich nützlich ist, wenn wir uns ein wenig mit effizientem Lernen auseinandersetzen.

JAX: Was ist die Kernbotschaft deiner Session, die jeder mit nach Hause nehmen sollte?

Jens Bendisposto: Gebt Eurem Gehirn auch einmal die Zeit, ein Problem kreativ anzugehen und schreibt mehr auf!

JAX: Vielen Dank für dieses Interview!

Die Fragen stellte Hartmut Schlosser.

The post Das Gehirn – eine Gebrauchsanweisung (nicht nur) für Software-Entwickler appeared first on JAX.

Eine Vorlage für die E-Mail an Ihren Chef

The post Mit einem Besuch Probleme lösen! appeared first on JAX.

Eine Vorlage für die E-Mail an Ihren Chef

The post Hey Chef! Warum ich auf die W-JAX soll? appeared first on JAX.

Eine Vorlage für die E-Mail an Ihren Chef

The post Überzeugen Sie Ihren Chef – Warum sich die Teilnahme an der JAX für Unternehmen lohnt appeared first on JAX.

THESE 1

Bernhard Löwenstein: Die meisten Unternehmen machen nicht Scrum, sondern verwenden lediglich einen Scrum-ähnlichen Prozess. So werden beispielsweise immer wieder die Daily Stand-ups oder die Retrospektiven nicht gemacht. Dadurch geht aber manch großer Vorteil verloren, dessen sich die Unternehmen aber gar nicht bewusst sind.

Oliver Kraeft: Da stimme ich zu. Oft habe ich die Variante erlebt, dass nur das Daily Scrum stattfindet oder einzelne Teile des Scrum-Prozesses nicht vorkommen. Bei der Scrum-Master-Zertifizierung lernt man, dass man zwar etwas aus dem Prozess weglassen kann, es dann aber kein Scrum mehr ist. Aber auch die Variante, dass zwar Scrum verwendet wird, es aber nicht so genannt wird, habe ich kennengelernt.

Den Scrum-Prozess zu verwenden, ist eine große Umstellung für das Team. Die eigenen Tätigkeiten sind für alle sichtbar und sie ändern sich mitunter gegenüber dem klassischen Vorgehen. Das ist nicht jedermanns Sache.

Durch die Retrospektive verbessert sich der Prozess mit jedem Sprint.                                                                                                                                                                                    .

THESE 2

Bernhard Löwenstein: Bei den früher klassischen Vorgehensmodellen gab es immer einen großen Aufschrei der Entwickler, wenn Codeteile im Nachhinein geändert werden mussten. Bei Scrum sind in den meisten Projekten die zwischendurch durchgeführten Codeadaptierungen noch wesentlich umfangreicher, allerdings wird dies nicht bewusst wahrgenommen. Um es mit einer Metapher auszudrücken: Am Ende steht zwar ein fertiges Haus, aber auf dem Weg dahin hat man oft in Summe auch ein ganzes Haus wieder eingerissen.

Oliver Kraeft: Ich denke, die Softwareentwicklung hat sich im Laufe der Jahre stark verändert, beispielsweise durch Bücher wie „Design Patterns“, „Clean Code“ oder „Refactoring“ und auch durch die testgetriebene Softwareentwicklung. Dadurch hat sich der Fokus in Richtung bessere Codequalität bzw. laufende Codeverbesserung bewegt. Heute ist Refactoring Stand der Dinge, zumindest wenn es eine gute Testabdeckung gibt. Die gängigen IDEs unterstützen einen dabei. Durch das iterative Vorgehen kommt es zwangsläufig dazu, dass schon vorhandener Code verändert werden muss und deswegen Wert auf die Wart- und Veränderbarkeit gelegt wird.

Der Agile & Culture Track auf der W-JAX 2018

THESE 3

Bernhard Löwenstein: Es wird bei Scrum vorab kaum mehr etwas spezifiziert, sondern die Produktivität wird vorrangig daran gemessen, wie schnell die Entwickler loslegen und etwas Herzeigbares liefern. Das endet oftmals in Code, der deutlich eleganter geschrieben hätte werden können, oder in Architekturen, die sich später als suboptimal herausstellen.

Oliver Kraeft: Das kann zwar passieren, hat meiner Meinung aber nichts mit Scrum zu tun. Wenn es in einem Scrum-Prozess passiert, würde es auch ohne Scrum passieren. Man kann durchaus mehrere Sprints für Architekturüberlegungen und Prototypen verwenden. Um zu erreichen, dass die Codequalität hoch genug ist, benötigt man Codereviews, das sollte zur Definition of Done gehören. Es sei denn, alle Entwickler sind so brillant, dass das nicht nötig ist. Das ist aber meist nicht der Fall. Ich halte Codereviews jedenfalls für sehr wichtig.

Bei der Scrum-Master-Zertifizierung lernt man, dass man zwar etwas aus dem Prozess weglassen kann, es dann aber kein Scrum mehr ist.

THESE 4

Bernhard Löwenstein: Entwickler lieben Scrum vor allem deshalb, da die lästige Arbeit des Dokumentierens auf ein Minimum reduziert wird und das Programmieren im Vordergrund steht. Das erzeugt den Eindruck, dass man stets produktiv ist, auch wenn dies gesamtheitlich betrachtet nicht so der Fall ist.

Oliver Kraeft: Dieser These stimme ich nicht zu. Ob das Dokumentieren Teil der Arbeiten eines Softwareentwicklers ist, hat nichts mit Scrum zu tun. Die Dokumentation muss gewünscht sein, und dann ist sie ein Teil des Sprint Backlogs. Dokumentation muss ebenfalls Bestandteil der Definition of Done sein. In meinem aktuellen Projekt erfolgt ein Teil der Dokumentation durch die Tests, wodurch diese automatisch immer aktuell ist.

THESE 5

Bernhard Löwenstein: Wer Scrum mit den früher klassischen Vorgehensmodellen vergleicht, macht oft den Fehler, dass er Scrum inklusive der heute bereitstehenden Werkzeuge und Techniken mit dem früher klassischen Prozess exklusive dieser Werkzeuge und Techniken vergleicht (da es diese eben damals noch nicht gab). Klarerweise scheint Scrum dann den „alten“ Vorgehensmodellen deutlich überlegen zu sein.

Oliver Kraeft: Aus meiner Sicht ist Scrum den klassischen Vorgehensmodellen aus drei Gründen überlegen:

• Scrum beachtet eine der wichtigen Eigenschaften der Softwareentwicklung, nämlich dass sie ein iterativer (sich in kleinen Schritten wiederholender) Prozess ist.
• In regelmäßigen Abständen erhält der Kunde eine lauffähige Software, sodass Fehlentwicklungen schnell erkannt werden.
• Durch die Retrospektive verbessert sich der Prozess mit jedem Sprint.