Fuzzy Versus Hard is a mechanism used to encourage feedback. Early on when feedback is to be encourage, concepts should be presented with fuzzy edges and rounded corners and later on as the concept matures the edges should be harder with square corners. This is a practice used in a number of fields, but not in software development. It is a concept that I have been practicing on my current project.
I normally present the results of analysis in word documents using diagrams created with Visio or Powerpoint. Feedback from the business and other members of the development team is poor, often limited to the pointing out of typos or speeling mistakes. I applied fuzzy versus hard to presenting workflow diagrams with dramatic improvement in feedback. Exactly the kind of feedback I was after.
Instead of creating a word document with visio diagrams, I presented a set new workflows by drawing them by hand on a blank sheet of paper. The business commented on them as I was drawing them out suggesting alterations. After we had been through them a couple of times, we created the word document and visio. We had seen that one of them had scribbled all over a copy of the document with red pen. When we held a review session to discuss the workflows, they turned up with a pristine copy of the document minus the scribbles. We asked to see the scribbles and told them that the document was written in pencil as far as we were concerned. This got the feedback going, they pointed out all the errors in what we had done.
This blog was inspired by a discussion with Allistair Cockburn following a talk by Kevin Tate at the Agile Development Conference 2003. Fuzzy Vs Hard is a phrase that Kevin used during his talk.
Posted by chrismatts at February 15, 2004 8:18 PMHi Chris,
"Fuzzy vs Hard" is a really useful concept - especially now that it's got a name!
I found a similiar situation with prototyping: when our prototypes are built with real software, or even in visio, then everyone focused on the nitty gritty detail ("what if we called that field blah, rather than blah2?" or "I supose it's to hard to add another column to that table?") rather than the big picture, but now that I've switched to scribling on paper the old creative juices have started to flow again.
Here's a useful article on paper prototyping:
http://www-106.ibm.com/developerworks/library/us-paper/?dwzone=usability - the author has also written a book (but why would you need it?)
cheers,
Clarke