Product Delivery Resources

Ambiguity vs. Rigid Process in Product Development

What’s the balance for today’s complex, integrated systems?

Derwyn Harris | June 6, 2016

productI have a conflict.

How does ambiguity influence the requirements, agile and modeling processes when building today’s complex products? According to the experts in each field, teams simply follow the “correct” process and leverage well-defined rules to reduce ambiguity to build a better product, faster.

But, do stricter controls and processes help us build better products? I don’t think so. I think some ambiguity is good. There’s a vagueness in product definition, validation and development that requires dialog, decision-making and thoughtfulness. It requires open, honest communication between humans.

But even at agile development shops, teams are introducing rigid processes. In my opinion, teams using an agile methodology embrace the ambiguity in product development.

At the No Magic conference on Monday, May 23, I saw Giancarlo Guizzardi’s keynote about ontology, and I thought it was fantastic. He described how you can put too many or too few constraints around modeling. Too many or too few constraints, he explained, can result in unrealistic scenarios when run through a simulation.

Guizzardi ended his keynote by saying models are rarely correct. He emphasized that the people creating the models need to analyze, to have dialog, and to accept feedback humbly. He paraphrased a great quote from Dijkstra’s Humble Programmer, 1972, which read:

[What] I have chosen to stress in this talk is the following. We shall do a much better conceptual modeling job in the future, provided that we approach the task with a full appreciation of its tremendous complexity… provided we respect the intrinsic limitations of the human mind and approach the task as Very Humble Conceptual Modelers.

At ReConf in Germany earlier this year, I had a similar conversation around requirements. After a talk on EARS (Easy Approach to Requirements Syntax), I discussed the concept with a customer. We agreed that while rules around syntax reduce ambiguity, it’s not foolproof. It tends to make us lazy. We assume the rules are going to protect us, so we pay less attention. But mistakes happen, and people typically react by increasing process to reduce risk.

But let’s look at a real-world example: studies show that when you remove traffic signals the streets actually become safer. It’s a great example of ambiguity working in a chaotic environment – we pay more attention and are more conscientious drivers when less reliant on rules.

All this aside: I don’t think we should remove all rules when building products. Complexity, quality, safety and compliance all drive the need for process, rules, and control measures. It’s just that person-to-person collaboration and dialog is often an afterthought – or worse – it’s feared.

Ergo, the conflict: what is the right balance between ambiguity (collaboration) and rigid process? Today’s product development ecosystem is complex. It’s mixed with legacy tools, new tools, standards, technologies, programing libraries, and a fickle, fast-moving market. To strike the right balance will require the data, people and work product have to be connected. We need better, more up-to-date information shared across teams, departments, and customers. And, product teams can’t live in isolation.

It may be a long road. I’m an optimist, and so with the past decade’s advancements and with standards such as OSLC, I think finding that balance is possible. And I’m excited about the future.