The Cat Dilemma
The Customer Needs a Cat Developed by Your Software Company
A Team is quickly assembled to meet the challenge. The Customer is introduced to the Customer Liaison and told this person will make sure you are a “Happy Camper’ throughout the entire Development process.
The Domain Development team rushes to define the “What” of this Cat. All the nouns for this Cat are discussed and the abstract Cat now lives. It is now time to breathe life into our Cat.
The Product Owner eagerly takes the abstract Cat and prepares it for development. The Product Owner creates the Scrum “Christmas List” of features and functionality for Cat 1.0 and delivers it to the Scrum Master.
The Scrum Master happily states his Development team will create all the “Hows”. The verbs for the Coolest Cat ever seen are meticulously defined. The Development team proceeds to create the “Baddest” Cat ever developed in the history of civilization.
The Quality Control team tests Super Cat and certifies it as “Too Cool for Color TV” and delivers it to the Product Owner: “It Alive!” all exclaim!
The Product Owner is ecstatic with “Mega Cat” as it exceeds every vision the Product Owner had for this Cat. He cannot get this “Wonder Cat” to the Customer Liaison fast enough as he is sure that the Customer will be thrilled with their “Catzilla”.
The Customer Liaison is elated as he has been telling the Customer for weeks that it will be ready any day now. A quick call to the Customer results in an immediate audience for the presentation of the “Royal Cat”.
The day has come …
…… the unveiling of the Customer’s Cat is moments away …
……… The veil is removed …
………… AND THE ROOM IS SILENT
The Cat Dilemma:
The Customer wanted a seven pound, solid black cat with blue eyes and big paws with six toes (polydactyl) and the unveiled Cat was a twenty-five pound leopard spotted Ocelot that is just this side of a Mountain Lion! It truly is the “Baddest” cat alive but it failed to meet any vision of the Customer in every way.
The Conclusion:
The Ubiquitous Language is an indispensable part for a satisfied Customer. It also gives the entire team a “Get Out of Jail Free Card” for scope creep and changes. As all changes are time stamped with an Owner attached to the request and the results, accountability is achieved through documentation.
Once again, this will not prevent Customer and Development Team misunderstandings but it will drastically reduce the negative outcome from those misunderstandings.
Another major benefit is that the Lexicon exists past initial delivery of the Application; it lives throughout the entire life cycle of the Application. As changes are needed down the road, communications to new team members and old memories are available through the Holy Grail of Development Understanding: The Ubiquitous Language Lexicon of Terms, Phrases, Concepts and Ideas.
WHICH CAT ARE YOU GOING TO DELIVER?
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services
Latest posts by Brad Huett (see all)
- DevOps: A Bridge to Your DevOps Culture - March 25, 2016
- Embracing Test Driven Development (TDD) - March 25, 2016
- DevOps: Delivering Agile Projects - March 25, 2016