A Software Standard is not software, ...it is talking about software!

A Software Standard is negotiation dressed as technical writing. That makes it very different from writing code and brings its own dilemmas. And your agile teams may be painfully aware of them. What are these problems then on a big picture? And what makes them so unique in standardization?

Why your agile team hates standards (and why they could be right)

If you've worked in Software Standardization, chances are you've perceived it likely this way

• "dry as a dessert"
• ineffective in practical terms
• highly dependent on individual know-how
• prone to persuation and group consent

Discussion in Software Standardization; Figure: Copilot with help from the Author

And truth telling, Software Standardization feels all that at times. Yet, there are (!) many software standards out there. 

 Just take the automotive industry, e.g. (alphabetical order):

•     ASAM (Association for Standardization of Automation and Measuring Systems)
•     AUTOSAR (Automotive Open System Architecture),
•     CiA (CAN in Automation),
•     COVESA (Connected Vehicle Systems Alliance),
•     OPEN ALLIANCE (One-Pair Ether-Net Alliance),
•     SOAFEE (Scalable Open Architecture for Embedded Edge),
•     aso.  

Definition

So what's the purpose of software standardization? 

To keep it simple

Think of [Software Standards] as a formula that describes the best way of doing something./1/ 

Therefore, Software Standardization at it's core is about a shared formula for describing how systems should behave for different parties to interoperate. 

Standardization is a continous collaborative technical negotiation where competitors trade constraints and concessions for mutual benefit. 

So in theory intentions are noble...

Agile vs. Standard 

Commonalities

Now, agile software development and Software Standards both

• use issue-tracking tools like JIRA (incl. terminology, e.g. 'Bug' or 'Change')
• use the same base technologies (e.g. bus systems, protocols, etc.)
• may even on loose basis follow frameworks, such as Kanban or SCRUM   
• are organized in different teams / work groups / work packages

These commonalities at times make them look alike. Especially inside a smaller Working Group the daily business can feel similar to the tasks of a srum master - ...except: it is not. 

Differences

An agile software development department or team is usually a stakeholder of the used Software Standard and sends only one coworker (per department) as the company's representative into the standardization body. So their company is only one of many and they need to coordinate with the other departments within their company.

In direct consequence agile development optimizes for local delivery and rapid feedback, while standards optimize for group consent across several companies, many of them competitors in the market. 

That difference, the perspective that what "your neighbour does" is equally important as "your own product line" is what changes incentives, timelines, and collaborative interest at all levels.

Dilemma in Software Standardization

Surprisingly these differences create several dilemmas that are somewhat unique to standardization.

Paradox of Scale

Paradoxically, a solution that is technically optimal for one team becomes politically fragile as the scope widens. Or put in a different way, the more companies and product lines join the conversation, decisions depend less on pure engineering and more on persuasion and consensus.

Housekeeping of Bug Fixes 

A clear bug fix that benefits everyone can become low priority in a standards forum because there is little to debate. Conversely, large strategic topics invite more deep technical discussion but also attract politics and dominance by better-resourced parties which can lead to bug fixes being delayed.

Demands of the Masses

Compared to local product line adaptations standardization is slow. Very slow. Backward compability and "doing it right once" play a major role to avoid unnecessary manual code adaptations by all companies participating in standard.

Consequences for Contributors

For technically proficient contributors the process can be frustrating 

• tickets pile up and technical debate is flattened into administrative work 

  minor issues are processed like any other ticket, which kills nuanced technical discussion and drains motivation 

  major topics may welcome debate but are often swamped by background politics or dominated by a few voices, which slows progress

The net effect is intentionally future oriented standard organizations that oscillate between tedious ticket handling and high-stakes political negotiation. 

Conclusion 

A good standard is not the most elegant code; it is the clearest, most widely accepted agreement that lets many teams build reliable code together. It requires negotiation and patience as much as careful technical discussion.

In the end, a Software Standard is not software. It is talking about software.  

Author's note: 
In my next blog post, I will focus more on practical fixes and recommendations for this topic.    

 

 Richard Huber is a wholehearted technical coordinator who opts for fair, collaborative solutions — no matter how vivid the circumstances. He is a software orchestrator and software‑standardization expert, steering clear‑headed and cool under pressure through multinational virtual and on‑site discussions. At home he’s a husband and father who recharges with fitness, chess and a good audiobook. Find out more about him on LinkedIn. 

 

Sources

• /1/  www.iso.org/standards