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
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
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.
Kommentare
Kommentar veröffentlichen