If your technical staff is asking questions about "correct" system behavior, and waiting hours or days to get an answer, then you have the same problem. The lean software solution is to get the person who can answer the question in the room--either by embedding the customer directly in the team room, or, for a technical question, pairing new programmers with more experienced staff so they dont get stuck.

The most obvious example of this is reducing the amount of defects that escape to production--and, if possible, preventing them even from getting to a tester. After all, if testers find a defect, they have to stop, reproduce the problem, document it, pass it back to a developer to fix, wait and then retest. Preventing the defect eliminates handoffs, dead time and rework.

While these tasks can't always be eliminated, they can often be streamlined. The tester might mention in passing the defect and work directly with the developer to get it fixed, instead of a more formal (read: slow) document/triage/handoff/retest process.

"Continuous improvement is the basic hygiene of knowledge work" Tom DeMarco and Tim Lister wrote in the landmark book . The heart of continuous improvement is change and differentiation, which is exactly what standardization is designed to prevent.

If continuous improvement is to be a core value in lean--and it is--then teams need the freedom to adapt the process over time in order to improve outcomes. This repaints standards not as a rule, but, rather, as a sort of guideline that's defined by the team itself, once technical staff believe the benefits of standards exceed their limitations; these standards can also be removed at any time. (The same concept applies for inter-team communication and services, which are continually improved through collaboration with management.)