Der blinde Fleck: Zeitqualität

Super Kantine, aber keine Erlaubnis, auf slack.com zuzugreifen. Modernste Konferenzräume, aber keine Erlaubnis für Homeoffice. Hardware-Spitzenprodukte, aber keine Erlaubnis zum Refactoring von Code. So oder ähnlich ist die Realität nicht nur in einem Unternehmen, aus dem Teilnehmer in Clean Code Trainings der CCD School sitzen. Wie kann es zu solch einer „Schizophrenie“ kommen? Darüber grüble […]

weiterlesen

Das Produkt der Softwareentwicklung ist Fokus

Es scheint so klar, was das Produkt der Softwareentwicklung ist: Software, Code. Doch ich glaube, das ist ein Missverständnis. Und durch dieses Missverständnis entstehen viele Konflikte, die viel Geld verbrennen. Aber erstmal: Was ist ein Produkt? Ein Produkt ist, wofür ein Kunde bereit ist, Geld zu bezahlen. (Oder allgemeiner: dafür etwas dem Anbieter Wertvolles im […]

weiterlesen

Vorsicht vor dem grobmotorischen Kunden

Die meisten Kunden in Softwareprojekten sind Grobmotoriker. Kunden bzw. ihre Stellvertreter – PO, PM, Business Analyst, Projektleiter oder wie auch immer – haben ein Feingefühl, das man mit Vorschlaghammer, Abrissbirne oder Dampfwalze assoziieren kann. Damit meine ich nicht, dass Kunden unhöflich wären. Nein, um persönliche Eigenschaften geht es nicht. Ich meine ihr Verhalten gegenüber der […]

weiterlesen

Die Geburt von Clean Code aus der Produktivität

Wenn es beim Clean Code Development nicht offensichtlich um Geld geht, wird es keinen Einzug in die Softwareentwicklung halten. Nicht, dass ich das nicht schon gewusst hätte, aber ich habe das nicht gut genug umgesetzt in dem, wie ich über Clean Code Development spreche und wie ich es in Trainings und Beratungen vermittle. Ich werde […]

weiterlesen

Der Prä-/Trans-Trugschluss

Die Entwicklung von Können und Bewusstsein durchläuft Phasen. Ein inzwischen recht bekanntest solches Phasenmodell ist Shuhari. Oder auch die Ausbildungsstufen Lehrling, Geselle, Meister spiegeln das wider. Wenig bekannt hingegen ist der Prä-/Trans-Trugschluss von Ken Wilber (engl. pre/trans fallacy). Auf den komme ich jedoch immer wieder, wenn ich mir Diskussionen im Web und anderswo anschaue oder […]

weiterlesen

Scrum Commitments dürfen nicht erfüllt werden

Ziele sind NICHT zum Erreichen da, schreibt Conny Dethloff. Und Elon Musk will bis 2025 Menschen auf den Mars bringen. Beides gefällt mir. Ob und wann 1.000.000 Menschen auf dem Mars leben werden, ist nicht so wichtig. Es geht darum, welchen Sog diese Vision ausübt. Wenn wir uns darauf einlassen, kann Kohärenz entstehen. Kräfte werden […]

weiterlesen

Agile Gesundheit – Nur Mut!

Wer an den Nutzen von Agilität glaubt, der beschränkt sich mit ihr nicht nur auf die Softwareentwicklung. Dann durchdringt sie vielmehr das ganze Leben. Einfach ist das aber nicht immer. Das habe ich heute gemerkt. Da stand ich vor der Frage, ob ich auch eine agile Gesundheit mutig anzugehen bereit bin. Vor einiger Zeit war […]

weiterlesen

Die Highlander-Anforderung

Irgendetwas ist faul mit der Priorisierung von Anforderungen. Der Gedanke beschleicht mich mit jedem (agilen) Team mehr, das ich sehe. Denn die allerwenigsten agieren in der wunderbaren Welt der Vorstellung, dass es einen echt kompetenten, entscheidungswilligen und -befugten und auch noch präsenten Kunden (bzw. Stellvertreter) gibt. So ein Kunde mag wünschenswert sein. Ja, sehr sogar. […]

weiterlesen

Raus aus dem Geschwindigkeitsrausch

Wäre dieses agile Velocity Diagramm eines Scrum-Teams würdig? Mein Gefühl ist, dass nicht viele Teams (oder Manager von Teams) damit zufrieden wären. Die Velocity sinkt von Iteration zu Iteration. Das schaut nicht gut aus, oder? Was ist da nur los? Die Fortschrittsgeschwindigkeit sollte von Iteration zu Iteration doch am besten steigen oder zumindest um einen […]

weiterlesen

Der dunkle Bruder des Feedback

Feedback in der Softwareentwicklung ist nötig. Umso mehr, je unsicherer ist, was eigentlich geleistet werden soll und ob man das schon geleistet hat. Deshalb sind in der Agilität zwei Feedbackschleifen explizit institutionalisiert: Durch automatisierte Tests bekommen Entwickler innerhalb von Sekunden oder Minuten Feedback, ob Veränderungen zu Regressionen geführt haben. Durch Reviews des Implementierten mit Stakeholdern […]

weiterlesen