Archiv des Autors: Johann-Peter Hartmann

Ü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: Von Helden und Eiern

Veröffentlicht am von
5

„Wir machen uns um Onkel Henry furchtbare Sorgen. Er denkt, er sei ein Huhn.“
„Na, warum schicken Sie ihn denn nicht zum Arzt?“
„Naja, das würden wir ja. Aber wir brauchen die Eier.“
— Douglas Adams: Der lange dunkle Fünfuhrtee der Seele: Dirk Gently’s Holistische Detektei

Agile Methoden setzen auf das Team, nicht auf die Individuen. Alles soll das Team entscheiden, alles soll das Team gemeinsam machen. Von Pair über Mob Programming, die meisten Dinge lasten auf mehr als einem paar Schultern. Als Metapher hat man sogar den Bus-Faktor gefunden: Wie viele Leute aus dem Team muss ich mit dem Bus überfahren, bis die Software nicht mehr weiterentwickelt werden kann?

Weiterlesen →

Agile Missverständnisse: Was Selbstorganisation nicht ändern darf

Veröffentlicht am von
3

Wirklich agil bedeutet doch auch, dass man alles ändern kann. Da ist auch Scrum schon zu dogmatisch, deshalb haben wir das abgeschafft und sind auf Kanban gewechselt. Wir releasen ohnehin die ganze Zeit, da ergeben die Iterationen keinen Sinn. Einen Product Owner haben wir ebenfalls nicht, das hat für uns irgendwie nicht gepasst. Scrum Master sind bei uns jetzt agile Coaches, aber davon brauchen wir auch nicht für jedes Team einen, wir haben jetzt praktisch für alle drei Teams einen.

Weiterlesen →

Agile Missverständnisse: Architektur entsteht emergent

Veröffentlicht am von
2

Schon das agile Manifest hat eine klare Ansicht darüber, wo und wann Architektur entstehen sollte:

The best architectures, requirements, and designs emerge from self-organizing teams.

Also ist die Sache doch klar: Das Team entscheidet selbst über die Architektur, und die alten Mächte, die aus den Enterprise Architecture Boards die richtige Architektur aus der Ferne finden wollten, sind bezwungen. Endlich kann man selbst Hand anlegen und Architektur passiert dann, wenn sie gebraucht wird.
Weiterlesen →

Agile Missverständnisse: NoEstimates – Schätzungen schaden.

Veröffentlicht am von
4

Wer schätzt, verliert. Entweder man hat genug Puffer mit drin und es ist zu aufwändig, oder er fehlt und es klappt nicht pünktlich. Externe Abhängigkeiten werden auf rauen Annahmen geplant, von denen man sich zwar wirklich wünscht, dass sie zutreffen würden, aber in Wahrheit selbst nicht daran glaubt. Und kurz vor dem Launch kommen dann die Überraschungen, mit denen man zwar gerechnet hat, jetzt aber keine Zeit mehr hat, mit ihnen umzugehen.

NoEstimates

Also lieber nicht schätzen, sondern auf Business Value und Durchfluss optimieren. Wenn ich zu jedem Zeitpunkt das Nützlichste mache und meine Strecke auf dem Weg dazu kontinuierlich verbessere – was könnte ich mehr als Beitrag leisten?

Weiterlesen →

Agile Missverständnisse: Den Sprint abnehmen

Veröffentlicht am von
3

Alles wurde fertig entwickelt, und mit etwas abendlicher Arbeit und ein paar Kompromissen bei der Qualität konnte man tatsächlich alles liefern, was im Sprint enthalten war. Im Review stellt man die entwickelten Features vor, die Entwickler zeigen die Storys, an denen sie gearbeitet haben. Es werden die Akzeptanzkriterien durchgegangen und am Ende jeder Story wird gefragt, ob das so in Ordnung ist. Dann nimmt der Product Owner die Story ab, und damit ist bestätigt, dass sie umgesetzt wurde. Das Ganze wird formal dokumentiert – im Ticketing oder im Wiki – und am Ende gibt es ein Protokoll der Veranstaltung.

Das ist praktisch für das Team: Diese Stories sind fertig, bis auf Bugfixes und neue Features wird man von ihnen wenig hören. Endlich etwas geschafft.

Weiterlesen →

Agile Missverständnisse: Sprintabbruch durch das Team

Veröffentlicht am von
3

Es haben sich grundlegende Rahmenbedingungen geändert. Das Team stellt überraschend fest, dass das Sprintziel bei näherer Ansicht nicht mehr zu erreichen ist. Drei Tage vor Ende des Sprints ist deutlich sichtbar, dass der Forecast nicht annähernd erreicht werden kann.

Für das Team ist die Sache klar: Unter diesen Bedingungen kann man nicht mehr die Verantwortung für den Sprint übernehmen. Ähnlich sieht es der Scrum Master – so ist es nicht möglich, den Sprint weiterzuführen, er muss abgebrochen werden. Also trifft man sich in der Mitte des Sprints in einer spontan einberufenen Retro und bricht den Sprint offiziell ab, weil es ja nicht anders geht.

Weiterlesen →

Agile Missverständnisse: Druck & Stress

Veröffentlicht am von
3

Der Scrum Master muss das Team schützen! Deadlines erzeugen zu viel Druck für das Team! Und Überstunden darf es nicht geben!

Schaut man sich die Diskussionen in agilen Unternehmen an, entsteht schnell der Eindruck, dass die Entwickler-Teams sehr zart besaitet sind und es ihnen an Kraft und Resilienz fehlt, auch mit den kleinsten Störungen umzugehen.

Weiterlesen →

Agile Missverständnisse: Akzeptanzkriterien und andere Details

Veröffentlicht am von
4

„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

Veröffentlicht am von
7

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

Veröffentlicht am von
57

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 →