Lassen Sie mich Ihnen eine Frage stellen: Haben Sie als Produktmanager oder Scrum Master das Gefühl, dass es einen Kipppunkt gibt, an dem Konsistenz zur Tyrannei wird?

Ich habe diese Frage einigen armen, ahnungslosen Leuten bei einigen kürzlichen Produkt- und Agile Meetups hier in der Gegend von Raleigh gestellt. Meine Belohnung waren zahlreiche Bestätigungen, dass es solche dummen Kobolde gibt.

Neulich, nachdem ich meine Frage auf verschiedenen Social-Media-Kanälen gepostet habe, bin ich davon überzeugt, dass wir im Software-Delivery-Business uns manchmal tatsächlich im Namen der Konsistenz versklaven.

Lassen Sie uns also ein wenig auspacken und sehen, ob wir uns nicht darauf einigen können, wie ein solcher Wendepunkt aussehen könnte …., indem wir zuerst untersuchen, was er nicht ist.

Weise Konsistenz

Ein Beispiel für nützliche Konsistenz für Produktmanager ist die Art und Weise, wie wir unsere User Stories erstellen. Ich folge zum Beispiel gerne dem INVEST-Prinzip – NICHT als Kesselrezept, sondern als Leitfaden, um sicherzustellen, dass ich meine Teams nicht auffordere, den Elefanten in einer einzigen User Story ganz zu fressen.

Ein weiteres Beispiel für gute Konsistenz kommt aus der Welt der UX, speziell aus dem 6. Kapitel von Don Normans bahnbrechendem „The Design of Everyday Things“. Dort behauptet Norman, dass diejenigen von uns, die Erfahrung im Autofahren haben, mit einer Marke und einem Modell zurechtkommen, das wir noch nie zuvor bedient haben, weil Funktionen wie das Gaspedal und die Seitenspiegel konsistent platziert sind.

Steve Krug führt dieses Beispiel im Kapitel „Billboards Design 101“ seines herrlichen Buchs „Don’t Make Me Think“ an. Krug bringt wirksame Argumente zugunsten der Wiedererkennung gegenüber der Erinnerung vor, besonders wenn es um die Behandlung von visuellen Hierarchien, Hyperlinks und das Layout von Inhalten geht.

Allerdings argumentiert Krug auch, dass wir letztlich nach Klarheit streben wollen, wobei der kluge Einsatz von Konsistenz ein wirksames Mittel ist, um dieses Ziel zu erreichen. Im gleichen Kapitel gibt er auch diese Warnung ab:

Und zum Schluss noch ein Wort zur Konsistenz.

Man hört oft, dass Konsistenz ein absolutes Gut ist. Man gewinnt viele Design-Argumente, indem man einfach sagt: „Das können wir nicht machen. Das wäre nicht konsistent.“

Konsistenz ist immer eine gute Sache, die man innerhalb seiner Website oder App anstreben sollte. Wenn Ihre Navigation zum Beispiel immer an der gleichen Stelle ist, muss ich nicht darüber nachdenken oder Zeit damit verschwenden, sie zu suchen. Aber es wird Fälle geben, in denen die Dinge klarer sind, wenn Sie sie etwas inkonsistent machen.

Tyrannische Konsistenz

Mein Eingangszitat stammt aus Emersons „Self-Reliance“,“, einem Essay, der ein überzeugendes Argument dafür liefert, selbst zu denken, anstatt ein Schicksal zu akzeptieren, das oft mit Klippen und Lemmingen assoziiert wird.

Wie bereits erwähnt, habe ich meine Eingangsfrage in einer Vielzahl von sozialen Kanälen und Meetups gestellt. Im Folgenden sind Beispiele aufgeführt, die ich geerntet habe und die meiner Meinung nach eine törichte, wenn nicht gar tyrannische Konsequenz demonstrieren:

• Ein Scrum Master, der einen Anfall bekommt, wenn ein Entwickler keine JIRA-Story erstellt, um einen Tippfehler in einem README.md-Artefakt zu beheben.
• Ein Redakteur einer Nachrichtenorganisation, der darauf besteht, dass die native mobile App genau die gleichen 150 Abschnitte unterstützt wie ihre browserbasierte Desktop-Lösung, um die Benutzer nicht zu verwirren.
• Ein Projektmanager, der behauptet, dass die Kapazitätsplanung der einzig wahre Weg ist, um sicherzustellen, dass ein Kunde das bekommt, wofür er bezahlt hat, weil modernere Ansätze zur Softwarebereitstellung mit zu viel Unsicherheit behaftet sind.
• Jemand aus der Praxis fragt: „Gibt es keine Möglichkeit, alle Entwicklungsteams dazu zu bringen, sich bei der Größenbestimmung von Stories anzugleichen?“
• Ein Architekt, der für Big Design Up-Front von allem für jedes Szenario plädiert, weil er darauf besteht, dass dies der einzige Weg ist, um zu wissen, was zur Unterstützung eines Feature-Sets gebaut werden muss.
• Ein Kunde, der verlangt, dass die Ergebnisse einer neuen Lucene-basierten Volltext-Suchinfrastruktur zu 100 % identisch sind mit denen, die von der bisherigen NoSQL-Datenbank-Implementierung zurückgegeben werden.
• Ein Produktmanager, der sich weigert, User Stories von anderen zu akzeptieren, wenn sie nicht fehlerfrei formatiert und umfassend mit einem TPS-Boilerplate und dem dazugehörigen Deckblatt ausgefüllt sind.

Das Ergebnis solcher Szenarien ist zermürbende Frustration, die unsere Entwicklungsteams als sklavische Hingabe an die Konsistenz ertragen … eine gut gemeinte, aber fehlgeleitete Priorisierung, die ihre Fähigkeit, schnell und kontinuierlich die richtigen Funktionen von Wert zu entdecken und zu liefern, stark behindert.

Zusätzliche Weisheiten

Auch andere, die klüger sind als ich, haben vor einer törichten Unterwerfung unter die Konsistenz gewarnt; im Folgenden finden Sie einige nützliche URLs, die ich in Vorbereitung auf diesen Beitrag besucht habe.