Über Johann-Peter Hartmann

Johann bezeichnet sich als "Chief Tailwind Officer" und sieht Rückenwind für Kollegen, Teams und das Unternehmen als seine oberste Aufgabe. Er mag tatsächlich seine Arbeit mit den Kollegen sehr und ist dankbar dafür, mit ihnen zusammenarbeiten zu dürfen.

Agile Missverständnisse: Akzeptanzkriterien und andere Details

„Das stand nicht in den Akzeptanzkriterien, das musste ich nicht machen.“ „Es stand doch in den Akzeptanzkriterien, dass der Styleguide gilt. Und der sagt ganz klar auf Seite 12, dass Buttons linksbündig floaten müssen.“ „So kann ich nicht anfangen, da fehlen ja noch alle Details.“ „Da versucht das Product Management uns mal wieder zu erklären, wie Technik geht.“

Akzeptanzkriterien und andere Details

Wir alle kennen die Schmerzen, wenn es um die Formulierung von User-Storys geht. Je nach Unternehmen, Abteilung und Person ist alles möglich: Zwischen Akzeptanzkriterien, die aus einem einzigen Wort bestehen, und seitenlangen Dokumenten mit hunderten Querverweisen, von denen ohnehin niemand davon ausgeht, dass sie wirklich gelesen oder geprüft werden können, ist alles denkbar.

Weiterlesen

Agile Missverständnisse: DoR & DoD als Vertrag

Mit der Definition of Ready vereinbart das Team mit dem Product Owner, woran man eine gute User-Story erkennt. Analog dazu die Definition of Done: Woran macht man fest, dass eine Story erledigt ist? Eigentlich praktische Werkzeuge, hat man doch endlich mal eine Größe, an der man die Eignung einer Story für die Entwicklung oder Produktion erkennen kann.

DoR & DoD als Vertrag

In der Praxis schlägt diese Orientierung jedoch oft über diese Intention hinaus. Die erste Definition of Ready wurde beschrieben als der Moment, an dem das Team sagt „Ah, ich habe es verstanden.“

Weiterlesen

Warum wir keine Titel und Positionen mehr haben

Wir kommen aus der PHP-Community und sind inzwischen in der agilen Community und der JavaScript-Community angekommen. Deshalb bekommen wir es mit, wenn gute Leute nach einer neuen Herausforderung, sprich: nach einem Arbeitgeber, der besser in ihr Leben passt als der bisherige, schauen.

Die Nachricht finden wir erst mal immer super, weil wir die Leute kennen und wissen was sie können. Bei den meisten könnte ich aus dem Stand eine halbstündige Eloge über ihre Fähigkeiten und Talente halten.

Und dann kommt die Irritation. Denn sie wollen Teamleiter, C*O, irgendwas mit Personalverantwortung, Head of *, * Lead oder Senior Architect werden. Auf gar keinen Fall einfach nur Developer. Nein, ein Titel muss her, man will ja die eigene Leistungsfähigkeit in der Karriere abgebildet sehen.

Tja, und damit können wir – und viel wichtiger wollen wir – gar nicht dienen. Weder die HR-Abteilung noch die Geschäftsführung kann Leute auf Positionen einstellen oder einen Titel vergeben.
Denn die existieren bei uns nicht mehr.
Weiterlesen

Management vs. Agile: Warum Manager agilen Methoden misstrauen

Wir haben auf dem Agile Day der WJAX einen Vortrag gehalten, der mit Hilfe von Nichtwissen, Cynefin und Komplexität zeigt, warum so viele Manager Probleme mit agilen Methoden haben.

Netterweise haben die Kollegen vom Software & Support Verlag das ganze nicht nur auf Video aufgenommen, sondern auch für alle verfügbar online gestellt. Deshalb können wir das hier auch verlinken.

Viel Spaß beim Anschauen!

Leadership in der IT

Ich habe gestern einen Talk zu Leadership in der IT auf der Developer Week gehalten. Es ist ein Bericht zu unseren praktischen Erfahrungen mit Leadership seit 2000, mit dem Schwerpunkt auf unseren schönsten Fehlern, die alle irgendwann einmal wie ein wirklich guter Plan aussahen.

Von klassischem autoritären Management über naive Agilität zur Überforderung der Führungskräfte durch transformationales Management von heute.

Richtig gut lesen läßt der sich leider nur in Fullscreen.

Vortrag Performante Softwareentwicklung auf der Webtech Conference

Jeder, der schon mal ein performantes Entwicklerteam erlebt hat, weiss, welche Wunder es vollbringen kann. Features werden im Wochentakt produziert, die Fehlerquote in der Produktion ist nahe Null. Und wenn ein Fehler auftritt, wird er in kürzester Zeit behoben.

Gleichzeitig erlebt man immer wieder auch Teams, bei denen zwar erfahrene Senior-Entwickler mitwirken, aber die trotzdem nicht funktionieren. Deadlines werden immer wieder verschoben, der Fehlerstrom ist unvorhersehbar, aber kontinuierlich vorhanden.

Und auch wenn wir es eigentlich besser wissen tun wir immer noch so, als ob Entwicklerstunden austauschbares, standardisiertes Normprodukt wären. Da werden Teams spontan zusammengestellt, andere vor der Deadline mit neuen Gesichtern ergänzt, im dritten finden sich zwei Kollegen, die schon vor 3 Jahren nicht miteinander konnten.

Wir bei Mayflower durften das mit Schmerzen durchleben, und kennen die frustrierten Teams, die gewagten Releases und das Gefühl, weit unter den eigenen Möglichkeiten zu arbeiten.

Aber wir haben unsere Lehren daraus gezogen und arbeiten heute als stabile, gut kooperierende Teams. Einige dieser Lehren finden sich in dem Vortrag von der WebTech Conference.

Wer sich den Vortrag gerne angucken möchte – es gibt Fliesstext zu jeder Slide.

Testing: how to get reliability and efficiency

We have been talking with Toby of qafoo fame about testing strategies:
How we need to craft architecture and design in order to significantly reduce the cost for tests. How to escape from the trap of the inner-platform antipattern, where we need to provide all infrastructure and business models with an ugly, mocked twin. Simply: How to efficiently write tests? And how to avoid that everyone hates them within 10 months, so that they would rather deactivate them instead of fixing them.
Please click here to read „Testing: the sweet spot“

Software Architecture Decisions – how to do it wrong the hard and the easy way

When it comes to software architecture, stuff gets funny. 

First we learn everything about it at university. We learn to use it as a part of our main project plan. We learn how to do risk evaluation. And, as a matter of fact, we learn how to create a lot of different UML diagrams: 

  • component diagrams
  • data flow diagrams 
  • package diagrams
  • deployment diagrams
  • sequence diagrams
  • state charts 
  • etc … 

Since we didn’t have a lot of experience with software back then, the resulting architecture is a badly done, but well documented. This style of software architecture is called "Enterprise Architecture" and usually done by consultants.

Weiterlesen

Warum PHP sich rechnet

Vor drei Wochen waren die Drupal Dev Days, eine wirklich gute Konferenz mit guten Leuten, Vorträgen und Spassfaktor (Vielen Dank noch mal an die Veranstalter, die Konferenz war wirklich erfrischend gut und Community-getrieben). Netterweise haben die gut organisierten Jungs und Mädels uns nach der Keynote gefragt, und das haben wir natürlich gerne gemacht – schliesslich setzen wir Drupal ein, und ausserdem sind das einfach nette Leute. Thema der Keynote war "Warum PHP sich rechnet". Das hört sich auf den ersten Blick trivial an, löst aber den gar nicht so einfachen Widerspruch zwischen dem schlechten Image von PHP als Programmiersprache und dem grossen kommerziellen Erfolg auf.

Die Erklärung gleicht der betriebswirtschaftlichen Herleitung von Agilität: es geht um die Fähigkeit, Real-Optionen zu nutzen und, im Falle von PHP, diese effizient anbieten zu können.

Wen es interessiert: Hier findet sich die Aufzeichnung der Keynote.