Reduktion braucht Mut. Und Methode. Denn nicht jedes Feature ist es wert, im System zu bleiben – auch wenn es mal teuer war.
Wenn wir mit Teams arbeiten, die ihre Systeme entschlacken wollen, hören wir oft dieselbe Frage:
„Woran erkennen wir denn, was wirklich raus kann?“
WeiterlesenTeil 2: Der Messie in deinem System – Warum du dich nicht von alten Features trennst
Wenn Systeme vollgestopft sind mit Funktionen, die keiner mehr braucht – ist das selten ein technisches Problem. Es ist ein menschliches.
In unseren Coachings und Trainings fragen wir oft provokant:
„Welche drei Funktionen eures Systems könnten heute gelöscht werden – ohne dass es jemand merkt?“
Die Reaktionen sind fast immer gleich: Lächeln. Schulterzucken. Dann Schweigen. Und irgendwann der Satz:
„Naja … eigentlich einige. Aber das darf ich gar nicht laut sagen.“
Warum fällt uns das Weglassen so schwer?
WeiterlesenWarum mehr Funktion deinem Produkt schadet – und was wir aus der Praxis empfehlen
Systeme, die immer größer, langsamer und schwerer wartbar werden – das ist kein Naturgesetz. Es ist ein Muster. Und es ist änderbar.
In unserer Arbeit als Coaches und Trainer im Requirements und Systems Engineering begegnen wir einem Phänomen, das sich durch fast alle Branchen zieht: überfrachtete Systeme, die längst unter ihrer eigenen Komplexität leiden.
Wir erleben Teams, die sich durch unklare Anforderungen und historisch gewachsene Feature-Wüsten kämpfen. Entwickler:innen, die sich fragen, warum sie eigentlich noch Code pflegen, den niemand nutzt. Und Produktverantwortliche, die sich mit Stakeholdern über Funktionen streiten, von denen nie jemand überprüft hat, ob sie überhaupt genutzt werden.
Kommt dir das bekannt vor?
Dann ist dieser Beitrag für dich.
WeiterlesenUse-Cases, Anforderungen, Programmcode, Testfälle.
Das sind nur ein paar Beispiele der typischen Artefakte, die im Laufe einer strukturierten Produktentwicklung erzeugt werden, mit dem Ziel ein stabiles, wartbares und performantes Produkt zu entwickeln. Im Vordergrund steht dabei kontinuierlich die Frage, ob ein neues oder existierendes Artefakt einen Wert für das Produkt liefert.
Hier kommt ein urmenschliches Problem zum Tragen. Es fällt uns schwer etwas loszulassen oder wegzuwerfen, dies trifft oft auch auf Entwicklungsartefakte zu und führt dazu, dass neben wertorientierten Artefakten auch solche erhalten bleiben, die sich irgendwann als obsolet erweisen werden. Zu diesem Punkt wird wahrscheinlich jede Produktentwicklung unweigerlich gelangen.
Weiterlesen
Kurze Releasezyklen oder Releases-on-Demand? Der Usus in der technischen Entwicklung (Systems Engineering) geht eher in Richtung ein oder maximal zwei Releases pro Jahr. Ein häufiger Grund dafür, den wir in unseren Kundenprojekten beobachten, ist, dass die Dokumentation nicht auf dem aktuellen Stand ist und damit – zumindest in Bereichen, in denen die Dokumentation regulatorisch für ein Release erforderlich ist – kein Release stattfinden kann. Den ersten wichtigen Schritt, um dem entgegenzuwirken haben wir bereits im letzten Blogbeitrag unserer Serie zum agilen Systems Engineering beschrieben. Nämlich die systemische, gesamtheitliche Betrachtung dessen, was dazu erforderlich ist, um das Produkt auf den Markt zu bringen, z.B. eben die Dokumentation. Ein konkreter Ansatz, dem das Verständnis der Dokumentation als Teil des Produktes zu Grunde liegt, ist Continuous Documentation. Das Ziel: Die Dokumentation zu jedem Zeitpunkt der Entwicklung in einem potenziell releasebaren Stand zu halten, um dadurch den Gedanken des auslieferbaren Inkrements der agilen Softwareentwicklung auch im technischen Umfeld zu erfüllen.
Weiterlesen