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.