“A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.” — Ralph Waldo Emerson
Let me ask you a question: As a product manager or scrum master, do you feel there is a tipping point where consistency devolves into tyranny?
I posed this question to some poor unsuspecting peeps at some recent product and Agile Meetups here in the Raleigh area. My reward was numerous affirmations that such foolish hobgoblins exist.
More recently, after posting my question on a variety of social media channels, I’m convinced that we in the software delivery business sometimes do indeed enslaved ourselves in the name of consistency.
So let’s unpack this a bit and see if we can’t agree on what such a tipping point might look like …. by first examining what it isn’t.
Wise Consistency
One example of beneficial consistency for product managers is in how we craft our user stories. For example, I like to follow the INVEST principle — NOT as a boilerplate prescription — but rather guide to ensure I’m not asking my teams to eat the elephant whole in a single user story.
Another example of good consistency comes out of the world of UX, specifically the 6th chapter of Don Norman’s seminal “The Design of Everyday Things.” There, Norman asserts that those of us with driving experience can manage a make and model we’ve never operated before because of the consistent placement of features such as the gas pedal and side view mirrors.
Steve Krug runs with this example in the ‘Billboards Design 101’ chapter of his delightful book “Don’t Make Me Think.” Krug making effective arguments on behalf of recognition over recall, especially when it comes to treatments of visual hierarchies, hyperlinks, and content layout.
However, Krug also argues that what we ultimately want to strive for clarity, with the wise use of consistency as an effective means to get there. He also offers this warning in the same chapter:
And finally, a word about consistency.
You often hear consistency cited as an absolute good. People win a lot of design arguments just by saying “We can’t do that. It wouldn’t be consistent.”
Consistency is always a good thing to strive for within your site or app. If your navigation is always in the same place, for instance, I don’t have to think about it or waste time looking for it. But there will be cases where things will be clearer if you make them slightly inconsistent.
Tyrannical Consistency
My opening quote came from Emerson’s “Self-Reliance,” an essay that makes a compelling argument for people to think for oneself, rather than accept a fate often associated with cliffsides and lemmings.
As I mentioned earlier, I asked my opening question in a variety of social channels and Meetups. Below are examples I harvested that I believe demonstrate a foolish, if not tyrannical consistency:
- A scrum master pitching a fit if a developer doesn’t create a JIRA story to fix a typo in a README.md artifact.
- An editor of a news organization who insists the native mobile app support the exact same 150 sections as their desktop browser-based solution so as not to confuse the users.
- A project manager who maintains that capacity planning as the one and only true way to ensure a customer is getting what they paid for because more modern approaches to software delivery have too much uncertainty involved.
- Someone from the field asks “Isn’t there a way we can get all the development teams to align on how they size stories?”
- An architect arguing for Big Design Up-Front of everything for every scenario because they insist it is the only way they can know what to build to support a feature set.
- A customer demanding that results provided by a new Lucene-based full-text search infrastructure are 100% identical with those returned from the outgoing NoSQL database implementation.
- A product manager who refuses to accept user stories from others unless they are flawlessly formatted and comprehensively completed using a TPS boilerplate and its accompanying cover sheet.
The result of such scenarios is grinding frustration that our development teams endure as a slavish devotion to consistency … a well-intended but misguided prioritization that greatly impedes their ability to rapidly and continuously discover and deliver of the right features of value.
Additional Wisdom
Others smarter than me have also warned about a foolish subservience to consistency; below are some useful URLs I visited in prep for this post.
https://medium.com/@jmspool/consistency-in-design-is-the-wrong-approach-3cfbc87a327
https://medium.com/@jmspool/consistency-in-design-is-the-wrong-approach-3cfbc87a327
https://medium.com/@jmspool/consistency-in-design-is-the-wrong-approach-3cfbc87a327
https://medium.com/@jmspool/consistency-in-design-is-the-wrong-approach-3cfbc87a327
How about you? I’m sure you also have some examples of #TyrannicalConsistency? Why not share them as a comment? After all, #SharingIsCaring.
YMMV