Thursday, February 19, 2009

Tolerance

This post is about using tolerances as a way to reduce costs and add value using Agile Development practices.

I recently attended a session at Agile Open Northwest called “Up Front Design - how much is too much?” I think the original intent was to focus on “technical design” for how to code, but it quickly diverged into a broader discussion about how other disciplines such as Product Management, Usability Engineering, and Web Designers influence software design by the way they specify their requirements.

One design influence is how Product Owners (aka Product Management) are asked to break larger features into smaller, more digestible chunks, (aka story) that can be implemented and delivered in running software by the end of each sprint iteration cycle. The agile advice is that as much as possible about a story should be “negotiable”. This is good advice as far as it goes, but what are the boundaries? Clearly there is some point to the story that is not as negotiable, otherwise why not just let a developer make it up. Giving a tolerance is a way to be clearer about what is negotiable and what is truly needed.

There were several Web Designers and User Interface Design people in the session who described how precisely they did page or screen designs. Their usual tools allowed them to specify size and position to the pixel, along with font sizes that fit just the right text string in a given space. This seems to be a common practice for a complete and detailed UI or Web page designs to get handed off for development. The UI and Web Designers in the session asked, "Why wouldn’t you want us to tell exactly how we want the screens to appear? Doesn’t it make your job easier if we have already figured this out for you?" The agile response was, “You will get better value if it’s more negotiable, and that it’s better to iteratively work with developers to figure out what is really needed.”

This conversation went back and forth. Agile YAGNI (You Aren’t Going to Need It) countered with, “but it’s our job to determine what users need.” A related agile principle, “defer design decisions to the last responsible moment”, countered with, “why should we wait when we already know it’s important.” This wasn’t an argument about the right and wrong way to do things but a conversation about the best way to work together. Several suggestions were given about the value of reducing the fidelity or precision of the UI spec by using paper sketches. A UI design tool that was intentionally “cartoonish” was also mentioned (I hope someone will comment on the name of this since I didn’t get it in my notes)

This was where the concept of tolerance came in. In manufacturing tolerances are used to specify where you need ultra-precise dimensions for a bearing fit or where you only clearance so it doesn’t rub. It is much more expensive to machine a +/-0.0001 inch bearing fit than to stamp out a +/- 1/32 inch clearance. In Lean Manufacturing over specifying tighter tolerances than are actually needed is considered “waste” because it drives up cost and manufacturing time, without adding any value.

Tolerances were common ground that that both agile developers and UI/Web designers could relate to. The agile developers related a simple case, if you only care that a button is on the right or the left of a screen, it’s faster to implement than if you ask for it to be located within 1 pixel. The UI and Web designers also related that tolerances would allow them to be clear about the critical aspects of their UI design while giving some leeway for what is more negotiable during implementation.

1 comment:

  1. Hi Bruce,
    The UI mockup tool you reference from that session is Balsamiq (http://www.balsamiq.com/). They have a standalone version as well as versions for Confluence, Jira and XWiki. The free trial version is fully functional but includes a watermark on the document. We have been experimenting with it and found it very valuable in our environment. One of the more wasteful practices we eliminated was the "fully specified UI" that would always end up getting significantly scaled back or modified when it came time to build. We seemed to always end up with the engineer going back to the designer with questions like "Wow, this is going to take two weeks to make it look like that...if I can make this minor tweak I can finish it in 15 minutes. Is that OK?" The answer is almost always a resounding "YES!"....and then "geez, i wish I had known that *before* I spent 40 hours tweaking this UI". Balsamiq allows the UX designer to get the important concepts across to the engineer without spending an inordinate amount of time laying out the page since they will inevitably end up laying out the page with the engineer later.

    ReplyDelete