What Abbot & Costello Can Teach Us About Requirements
When I was growing up, I used to love watching old black and white comedies, particularly Abbott & Costello. If you’ve never seen their classic “Who’s on First”, you can find it right here on Youtube. Feel free to watch it now (but be sure to come back)!
Briefly, this comedy skit is about Abbott explaining to Costello the names of the players on their baseball team. The names of the players include “Who” playing 1st base, “What” playing 2nd base and “I Don’t Know” playing 3rd base. Costello wants to know what the players’ names are, so he would ask “Who’s playing first base?” and Abbott would proudly respond “Exactly”. A frustrated Costello asks “What is the name of the person on first base” and now Costello would reply “No, he plays second”.
If you have never heard the routine, you must listen to it to appreciate it. The link above should help. But I digress.
“Who’s on First” can teach us a great deal about the pitfalls of collecting requirements:
We can have two business users reviewing the same requirements document, each thinking it says something very different. It gets worse. In the real world of requirements, this confusion isn’t limited to two individuals. It spans the entire team, including the business analysts, testing team and developers.
The obvious difference between the “Who’s on First” routine and real life requirements, is that Abbott & Costello know they are having a communication problem.
In the real world, the situation is actually much more challenging.
The “Spellchecker”
Let me share with you an actual “Who’s on First” example that happens almost every time we collect requirements. I call this the “Spellchecker” (and this is totally fiction, made up for illustrating my point).
Let’s pretend we need to add Spellchecker capability to our mobile application. We send out an RFP to various firms. In this example let’s say we send it out to Apple and Microsoft.
Apple responds and says they need two people working for two weeks.
Microsoft responds that they need four people working for six weeks.
We wonder: how does one company’s estimate result in four person-weeks while another is twenty-four person-weeks? Did Microsoft pad their estimate? Or did Apple simply not spend the right energy on estimating and they pulled a number out of the air?
So we ask Apple: “What are the two people going to do for two weeks”? They respond that they will build two screens and one engine. The two screens will include the screen that shows you replacement words and a confirmation screen. The engine is the actual “Spellchecker”.
Seems reasonable.
Then, we ask Microsoft: “What are four people going to do for six weeks”? They respond that they will be working on eleven screens and three engines and possibly some APIs.
Hmmm. We pause and ask: What are these eleven screens going to be used for? They explain the same two screens and engine that Apple discussed.
But they also have screens that allow you to add and maintain a list of “custom words” for your personal dictionary. Further, they have screens that allow you to plug in a proprietary dictionary such as a medical dictionary or a special language. That is how they got to eleven screens.
WOW! I never thought of that detail. Now I have to think of which version of the “Spellchecker” I really want.
If I want the two-screen version, I have to ask Microsoft to change their assumptions and re-estimate. If I want the eleven-screen version, I have to provide the clarity to Apple and ask for their re-estimate. Most likely, I may want something in between. Maybe a seven screen version. I want the “custom dictionary of personal words, but NOT the proprietary dictionaries”. So I clarify and ask them both to submit a re-estimate.
Unlike Abbott & Costello who knew they weren’t communicating, in the real world, we usually don’t catch our “Spellcheckers”. The BAs write up the requirements and the developers deliver the code. We all think: How difficult can it be to understand? After all, the business folks said they just want a Spellchecker! How much more straightforward can you get?
And later, when we deliver a solution that missed the point, the business will hold the BA and developer accountable! I mean it’s as simple as “Who’s on First”!
Taking the First Step
After sharing the “Spellchecker” story with the teams I work with, we actually use the word “Spellchecker” in our every day conversations to help uncover ambiguities and assumptions. It’s sort of a “keyword” around here.
Say we are discussing how we can’t put the next release of our software into production until we fix all of the defects that our top executive just finished screaming at us about. The developers estimate that this can take two to three months.
Our manager responds that we are estimating out of fear and these defects can be squashed in weeks. There is no way he is telling the executives that they have to wait another “three months”!
Then, someone pop-ups in the heat of this conversation and says:
Time-out. Do we have a “Spellchecker”? When you say fix “All the Defects”, we see there are over 50 defects in the system and we can’t imagine fixing all of those with four developers in a matter of two weeks.
Our manager responds:
50? No way! We only need the Severity 1, defects fixed. There are only four of those defects.
And the team responds:
That makes a big difference. Yes we should be able to get that done in a couple of weeks. But are you sure that the Executives agree to only work on the Severity 1 defects? It’s a Spellchecker to them too!
The Benefit of Acknowledging Spellcheckers
Not only do the teams I work with use the word Spellchecker to call out ambiguities, I have clients that have adopted this practice, calling out situations where they question whether “are we really talking about the same thing”. (In fact, the spellchecker concept is so useful, even my family has adopted using it).
There will always be areas that slip in between the cracks. You can’t catch every Spellchecker. However, the real benefit of acknowledging Spellcheckers is the fact that everyone acknowledges that unintentional Spellcheckers, not individuals, can be obstacles to a team’s effectiveness.
More important, Spellcheckers often point to a two-sided misunderstanding. Many times, when you uncover a spellchecker in requirements, the business person will say: I didn’t even think about that. I am not sure what I meant.
I’ll add one more example: When a business user identifies a defect in the software we delivered, we argue that this is an enhancement and not a defect. This is usually a Spellchecker in action and we are either both right (or wrong)!
Now, Who Did You Say Is On First?
My suggestion is to introduce the concept of Spellcheckers to your team and ask everyone to speak up when they see Spellcheckers. Share this with your business folks, management, and everyone else involved on the project. When you identify a Spellchecker, everyone can agree that no individual is at fault. It is simply a challenge in every day communication.
Don’t forget to leave your comments below.
Bob Zimmerman’s career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth. As Geneca’s CTO, Bob Zimmerman continues to build on his work as the driving force behind Getting PredictableS.M., the requirements definition and project best practices that are the foundation of Geneca’s mission to make software development predictable. He continues to extend these best practices to leverage more value for clients and new growth opportunities for Geneca.