Laat me je een vraag stellen: Als product manager of scrum master, voel je dat er een kantelpunt is waar consistentie overgaat in tirannie?

Ik stelde deze vraag aan een aantal arme nietsvermoedende mensen op een aantal recente product en Agile Meetups hier in het Raleigh gebied.

Nog recenter, na het posten van mijn vraag op diverse social media-kanalen, ben ik ervan overtuigd dat wij in de software delivery business ons soms inderdaad tot slaaf maken in de naam van consistentie.

Dus laten we dit eens uitpakken en kijken of we het niet eens kunnen worden over hoe zo’n omslagpunt eruit zou kunnen zien …. door eerst te onderzoeken wat het niet is.

Wise consistentie

Een voorbeeld van nuttige consistentie voor productmanagers is de manier waarop we onze user stories opstellen. Ik volg bijvoorbeeld graag het INVEST-principe – NIET als een standaardvoorschrift – maar als een leidraad om ervoor te zorgen dat ik mijn teams niet vraag om de olifant in zijn geheel op te eten in één user story.

Een ander voorbeeld van goede consistentie komt uit de wereld van UX, met name uit het 6e hoofdstuk van Don Norman’s baanbrekende “The Design of Everyday Things.” Daarin beweert Norman dat degenen onder ons met rij-ervaring kunnen omgaan met een merk en model dat we nog nooit eerder hebben bediend als gevolg van de consistente plaatsing van functies, zoals het gaspedaal en zijspiegels.

Steve Krug loopt met dit voorbeeld in de ‘Billboards Design 101′ hoofdstuk van zijn prachtige boek “Don’t Make Me Think.” Krug maakt effectieve argumenten ten gunste van herkenning boven herinnering, vooral als het gaat om de behandeling van visuele hiërarchieën, hyperlinks, en de lay-out van de inhoud.

Hoewel, Krug ook betoogt dat wat we uiteindelijk willen streven naar duidelijkheid, met het verstandig gebruik van consistentie als een effectief middel om daar te komen. Hij geeft ook deze waarschuwing in hetzelfde hoofdstuk:

En tot slot een woord over consistentie.

Je hoort consistentie vaak aanhalen als een absoluut goed. Mensen winnen veel ontwerpargumenten door alleen maar te zeggen: “Dat kunnen we niet doen. Dat zou niet consistent zijn.”

Consistentie is altijd een goed ding om na te streven binnen je site of app. Als je navigatie bijvoorbeeld altijd op dezelfde plek staat, hoef ik er niet over na te denken of tijd te verspillen aan het zoeken ernaar. Maar er zullen gevallen zijn waarin dingen duidelijker zijn als je ze een beetje inconsistent maakt.

Tirannieke consistentie

Mijn openingscitaat kwam uit Emerson’s “Self-Reliance,”een essay dat mensen overtuigt om zelf na te denken, in plaats van een lot te accepteren dat vaak wordt geassocieerd met klippen en lemmingen.

Zoals ik al zei, stelde ik mijn openingsvraag op diverse sociale kanalen en Meetups. Hieronder staan voorbeelden die ik heb geoogst en die volgens mij een dwaze, zo niet tirannieke consistentie laten zien:

• Een scrummaster die een woedeaanval krijgt als een ontwikkelaar geen JIRA story maakt om een typfout in een README.md artefact te herstellen.
• Een redacteur van een nieuwsorganisatie die erop staat dat de native mobiele app exact dezelfde 150 secties ondersteunt als hun desktop browsergebaseerde oplossing om de gebruikers niet in verwarring te brengen.
• Een projectmanager die volhoudt dat capaciteitsplanning de enige echte manier is om ervoor te zorgen dat een klant krijgt waar hij voor heeft betaald, omdat modernere benaderingen van softwarelevering met te veel onzekerheid gepaard gaan.
• Iemand uit het veld vraagt: “Is er geen manier waarop we alle ontwikkelteams op één lijn kunnen krijgen over hoe ze de omvang van stories bepalen?”
• Een architect die pleit voor Big Design Up-Front van alles voor elk scenario, omdat ze volhouden dat dit de enige manier is waarop ze kunnen weten wat ze moeten bouwen om een feature set te ondersteunen.
• Een klant die eist dat de resultaten van een nieuwe full-text zoekinfrastructuur op basis van Lucene 100% identiek zijn aan die van de oude NoSQL database-implementatie.
• Een productmanager die weigert user stories van anderen te accepteren tenzij ze foutloos zijn geformatteerd en uitgebreid zijn ingevuld met behulp van een TPS boilerplate en het bijbehorende voorblad.

Het resultaat van dit soort scenario’s is een slepende frustratie die onze ontwikkelteams doorstaan als een slaafse toewijding aan consistentie … een goedbedoelde maar misplaatste prioritering die hun vermogen om snel en voortdurend de juiste functies van waarde te ontdekken en op te leveren sterk belemmert.

Aanvullende wijsheid

Anderen die slimmer zijn dan ik hebben ook gewaarschuwd voor een dwaze onderwerping aan consistentie; hieronder staan enkele nuttige URL’s die ik heb bezocht ter voorbereiding van dit bericht.