Cunningham’s Law, Agile & Getting to the Best Possible Answer

In today’s DevOps blog, Flux7 HPC Solution Architect, Derek Magill, shares his insights on Cunningham’s Law and its relation to the Agile Delivery Model.

One of my favorite “funny” laws on the web is Cunnigham’s Law. It states that the fastest way on the internet to get the right answer is not to ask a question but to post the wrong answer.  It’s funny because it’s true. People love being right, especially on the internet. More importantly, your wrong answer gave them an anchor. It is a challenge, a puzzle to solve. It shines like a beacon to onlookers, begging for them to test their mettle against it.  

People respond to assertions in a way that they do not with questions. Questions are nuisances.  People receive dozens of questions a day, each of which is a demand on their time and a drain on mental resources.  A question is a burden placed upon you by someone else. Conversely, a statement is a curiosity that you can evaluate on your own terms. You can choose to ignore it without penalty.  Ignore a question and eventually, someone will come back to ask you again.

From Cunningham’s seemingly innocent internet witticism, I have observed a truism that reaches beyond the internet to the professional world, too. Indeed, there is an old French saying, ‘preach the falsehood to know the truth’. It also illustrates how innate this human trait is.  Let’s start with a simple example, a plaintive email asking a question.  E.g., “We need to get some downtime to deploy an upgrade. When would that work for your team?” It doesn’t matter if you send that to one person or dozens, the response will likely be crickets. Why? Because everyone is busy and now they have to evaluate when a good time for an interruption might be for this.  

Maybe someone spends a minute thinking about it. However, no one wants to respond because they don’t want to be the one who proposed a downtime that’s unpopular with the rest of the team.  So they leave the question unanswered. To get a response, a more effective message would be, “We need some downtime to deploy an upgrade so that we can take advantage of this new feature.  Our proposal is to do so on Friday at midnight. Please let us know if this is not workable.” This second email will absolutely get a response because it’s clear and actionable.

Cunningham’s Law + Agile

Now, let’s take this a step further.  Cunningham’s Law very well describes why Agile DevOps methods often yield superior results in a faster time than traditional waterfall methods.  Why? Because Agile focuses on getting something REAL into the end user’s hands quickly and getting feedback. While the Agile product may be the ‘wrong answer’, it is an answer to which the team will be compelled to respond.

Conversely, waterfall focuses on inundating stakeholders with endless questions about requirements.  Remember what I said about questions? They are a burden and people want to remove the burden as quickly as possible because they’re busy and have more important things to do.  This goes a long way towards explaining why waterfall projects often deliver what is specified, but not what is useful. The premise of requirements gathering is abstract, divorced from reality and often seen as a series of burdensome questions.  

Agile Development

On the other hand, having a product you can get your hands on is real. It’s concrete and it becomes a puzzle to solve.  And when done right, Agile development teams look past your snarky comments about their MVP and focus on delivering something that really meets your needs. Here at Flux7, we refer to this as an Agile Delivery Model; it creates frequent feedback opportunities with real working software. Thus helping elevate people move from a mindset of what they want to what they need. This is in line with the Agile Principle of “Simplicity – The Art of Maximizing the Work Not Done”.

Focusing on bite-sized blocks of work and delivering pieces of reality plays into the real human condition.  It gives people the wrong answer so that they can test it against what they really need. Thus, giving developers the right answer they wanted all along.  Maybe they didn’t even know what they needed when they told you abstractly what they thought they wanted. But by giving a wrong answer to work from, developers are sure to know now what they want now that they’ve seen what you put in front of them.

Agile enables constant evolution through a collaborative effort, producing results faster for the business. When we apply Cunningham’s Law to the Agile process and place product in the hands of developers, we not only receive higher quality feedback but receive their feedback in a much more timely manner — all while creating a collaborative environment.

For additional Agile and DevOps Reading:

• Technology’s Role in the Agile Enterprise
• White Paper: A Guide to Prepare Your IT Platform for the Agile Enterprise
• Agile Culture and the Agile Enterprise
• Agile Training and Teammate Satisfaction