I’ve had a number of private conversations about my lightweight development process blog post. Most of these have revolved around what I termed “jargon, unusual diagrams or fancy methodologies”. In fact, some developers and architects took offense and felt I was dissing their favourite development tools, methodologies, and techniques. “How can you think to recommend not using UML? Use cases? <Insert favourite management tool/meth/tech here>?”
Let’s be clear: I wasn’t suggesting not using these things, I was advising keeping them out of customer-facing documents. The value of this advice depends of course on the process maturity of your development organization, your sales organization, and the customer’s procurement or acceptance organization.
The point about jargon, et al, is to keep specialized terminology or diagrams that are unfamiliar to a non-technical audience out of documents intended for that audience. For example, “actors” and “agents” have specific meanings in various contexts, and while developers and architects know which context is which, most customers are going to think Angelina Jolie and Swifty Lazar.
Educating your customers on your terminology may well be counter-productive. Depending on your organization, it may also annoy Sales.
The same thing applies to swim lanes, fish tails, entity-relationship diagrams, etc. They all have their place, absolutely. And in a relatively larger organization with relatively more mature processes, architects and designers would use these, and someone else (marketing? project management? product management?) would translate these to language and format suitable for customers.
(As an aside, which will become quite relevant momentarily, one role of these specialized tools and jargons is to convey meaning accurately and precisely to others who lack context, for reasons of time or space or both.)
My general inclination is that if you have a smaller organization and are just starting on implementing processes, it’s best to just work with the customer presentables – you don’t have the cycles or resources to do both, and you need the customer-facing stuff. The danger is that a lack of precision in your designs may lead to implementation errors.
Or worse, to customer acceptance problems. Hence the “checkpoint and repeat” development cycle (involving the customer if it makes sense). If your organization is relatively small, you gain the benefit of context and conversation: You are not capturing design for later use by people who may not even have been hired yet, but for immediate use by a team of people who are likely all living this project (and possibly nothing else).
One of the big tricks of management is figuring out which organization you are, noticing when you are changing from one to the other, and adding process maturity at the right time (read: Just early enough, and never too late).
That’s a big trick. If you can pull that off repeatedly, you have a solid future ahead of you.
