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.

Ungeplante, aber validierte Investments in Qualität

Veröffentlicht am von
Antworten

In meiner liebsten deutschen Chat-community zu agilen Themen, dem Slack von Mein Scrum Ist Kaputt, hatten wir vor Kurzem wieder eine spannende Diskussion zum Thema „Schätzen“. Und neben den Klassikern wie NoEstimates, ItemCount und Flow kamen wir auch auf die Outlier – die Stories und Bugs, die jeder Schätzung und zum Teil sogar dem Sprintziel im Wege stehen, weil sie im Sprint plötzlich zu wachsen beginnen.

Es eine schöne Idee aus DevOps („Seeking SRE“ in diesem Fall), auf die mich ein Ex-Kollege gestossen hat:

Incidents are best regarded as unplanned investments in system performance.


Weiterlesen →

Retrospektive Schulden

Veröffentlicht am von
Antworten

In meinem Lieblings-Slack zu agilen Themen, dem Slack-Kanal von Mein Scrum ist kaputt, wurde wieder einmal eine spannende Frage gestellt:

Wie wirkt sich die Frequenz einer Retrospektive auf die Dynamik und die Inhalte aus? Ich habe das Gefühl, dass bei Retrospektiven, die man eher unregelmäßig macht, man einen großen Raum geben muss, um sich „auskotzen“ zu können. Ich fänd es spannend, wenn wir da ihr hierüber von euren Erfahrungen berichtet

• Wie ist dieser Zusammenhang
• Wie entwickelt sich auch eine Retro innerhalb eines Teams im Zeitverlauf

Oft ist das Problem ja nicht die richtige Antwort, sondern die richtige Frage. Und ich glaube, dass hier ist genau so eine „richtige Frage“.

Weiterlesen →

Die 10 Commandments of Egoless Leadership

Veröffentlicht am von
Antworten

In der Softwareentwicklung gibt es die 10 Commandments of egoless programming aus The Psychology of Computer Programming schon lange. 

Das Grundmotiv dieser Gebote ist die Akzeptanz der eigenen Schwächen und Fehler. Bei der Erstellung von Software spielen sie eine so große Rolle, dass wir das ganze mit Test-driven Development sogar zur Arbeitsweise erhoben haben:

Wir beginnen mit dem Test, der mangels Code einen Fehler anzeigt; unser eigentlicher Auftrag ist nur die Reparatur des Fehlers. Unser Normalnull ist also der Fehlerzustand.

Weiterlesen →

Agile Missverständnisse: Der Servant Leader als Dysfunktion

Veröffentlicht am von
Antworten

Bei agiler Arbeit ist die maßgebliche Organisationsstrategie die Selbstorganisation, weil sie einer komplexen und dynamischen Umgebung besser gerecht wird als steuernde Ansätze. Damit fallen ein paar der klassischen Führungsaufgaben weg, denn Methode und Struktur der Arbeit braucht nicht mehr extern geliefert zu werden.

Die Interaktion mit der Aussenwelt – die Abhängigkeiten zu anderen Organisationsteilen, der Zugriff auf Ressourcen und nicht zuletzt alle die Dinge, die ein Team nicht selbst lösen kann – bleiben aber als Aufgabe erhalten. Das führte dazu, dass Servant Leadership zur dominanten Führungsstruktur in agilen Umgebungen wurde, die nicht zuletzt in der Rolle des Scrum Masters operativ verkörpert wird.

Weiterlesen →

Agile Missverständnisse: Der neue agile Manager

Veröffentlicht am von
Antworten

Selbstorganisation entsteht nicht von alleine, sie braucht Ziele, Kompetenzen, Kooperationsmuster und Methoden. Jeder agile Coach weiß das und viele haben die Erfahrung gemacht, dass man diese Dinge nicht voraussetzen darf, sondern die Umgebung dafür bereitstellen muss.

Weil das Team das ganz offensichtlich nicht von sich aus kann – denn dann wäre es ja bereits selbstorganisiert – muss das woanders herkommen. Aber was mache ich jetzt als agiler Coach? Die Kollegen überreden? Mühsam, und ich kann mich nicht darauf verlassen, dass sie es dann tatsächlich machen. Workshops? Zertifikate? Offizielle Firmenstrategien? Management-Statements?

Weiterlesen →

Agile Missverständnisse: Agile Coach Tribalism

Veröffentlicht am von
Antworten

Wenn der Agile Coach nur ein Team hat um dessen Wohl er sich kümmern soll, dann hat er Glück. Es gibt einen klaren Fokus, man kann sich kümmern, man kann für „sein Team“ sorgen und es gedeihen lassen. Eigentlich das perfekte Setup, mit dem man den größten Benefit realisieren kann.

Weiterlesen →

Survey: Wie viel Kooperation haben wir denn gerade?

Veröffentlicht am von
9
Warum arbeiten wir agil in Teams, warum vermeiden wir Truck-Faktor, warum wollen wir T– π oder Paint-Drip-Shaped People haben?

Wir hoffen, dass wir von der Kooperation profitieren, dass wir keine Engpässe durch Einzelkompetenzen erzeugen und jede Aufgabe – ihrer Priorität angemessen – schnell umsetzen können.

Spannend wird das Ganze, wenn wir in ein verteiltes Setup gehen, wie es meine Kollegen Martin Ruprecht und Jens Broos in ihren Talks und Workshops besprechen.
Die Schwelle zu Kooperation ist höher, wenn ich erst die Video-Konferenz oder das Remote-Pair-Programming-Werkzeug der Wahl aktivieren muss.

Wir würden deshalb gerne von Euch wissen: Wie oft braucht ihr denn tatsächlich Kooperation, das heißt, die Zusammenarbeit und Kommunikation zwischen Kollegen?

Wie viele Aufgaben kann jeder erledigen, wie viele brauchen Kooperation oder Wissenstransfer? Welche Abhängigkeitsstrecken haben wir, wo kann ich mit mehreren Kollegen an den Tasks der gleichen Story parallel arbeiten?

Ihr findet unsere Umfrage unter https://www.surveymonkey.de/r/3TX3LSY.

Es wäre nett, wenn ihr sie auch ausfüllt – die Ergebnisse stellen wir dann hier vor.

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 →