Time orientation: Fitting language and Organizational Hygiene
This is our 7th article in an 8-part series on "Patterns of Time-Oriented Software Development" in practice
Our latest BetaCodex Network research paper gathers 18 patterns of Time-Oriented Software Development – none of which bolts onto older structures in software industries, like Waterfall, or Agile-as-we-know-it. If flow and rhythm, punctuality and reliability, agreements and mastery are to become common and consistently dominant, then older patterns, practices and structures must go on the garbage heap of history. Patterns 17 and 18 of our new research paper are about that: what has to go, and the language that holds a time-oriented system together.
Most organizational “transformations” fail for a simple reason: they add something without subtracting anything. A new framework gets introduced. A new layer of roles is tacked on. A new ceremony goes on the calendar. Whatever was already there stays — maybe annotated, maybe relabeled, but still present. The system grows and becomes thicker. Nothing really changes.
Time-Oriented Software Development (TOSD) does the opposite. Before it adds anything, it asks: What must go? We call this Organizational Hygiene. Removing practices, methods, roles, processes, and rituals that don’t fit a time-oriented system is necessary in all BetaCodex work. Our research paper names the obsolete practices and patterns explicitly. An abbreviated list:
Agile Coaches. Agile Scaling. Approvals and production-readiness reviews. Architects as a title. Backlogs. Business Analysts. Committees. Dailies and stand-ups. Development teams. Estimates. Individual targets. Kanban boards. OKRs. Phases. Prioritizations. Product Managers. Product Owners. Project Managers. Requirements. Resource pools. Retrospectives. Scrum Masters. Sprints. Sprint goals. Sprint planning. Story points. Testers (as a title). Tickets and ticket systems. User Stories.
Some of these patterns and practices will look broken or useless to you already. Others may still feel necessary. Of course we need a Product Owner and Product Managers. Of course estimates matter. Of course there’s a backlog. Those reflexes are artifacts of decades of capacity-oriented thinking. TOSD is a different system: a time-oriented one. In such a system, each of those items above is either unnecessary or actively in the way.
How to change people’s patterns of thinking without being intrusive or obnoxious
Removing patterns, tools, titles and practices alone is not enough. Which leads us to pattern 18 of our research paper: Adopt the language of time orientation from the start.
Language stabilizes systems. Words shape beliefs; beliefs shape practice. The vocabulary of software development today is the lingo of capacity- and volume orientation – Sprints, iterations, scaling, backlog, story points, batches, estimation, development teams, throughput, capacity utilization, optimum production size, economies of scale, utilization, target fulfillment, scheduling, meetings, forecasting, prioritization.
The vocabulary of time orientation is different – Daily Portion, OK Point, time slots, fixed Realization time, flow, rhythm, drumbeat, groove, fit, “the day’s work is done”, White Space, speed, desired date, anticipatory coordination, punctuality, queues, waiting, agreed handovers, handshake, TTEO, now.
The words change the thinking. Talk about “the next Daily Portion” long enough and the instinct to write User Stories fades. Replace “Sprint planning” with “what’s on the Lists that we’ll likely get to next week” and the planning ritual collapses into a conversation. This language isn’t decor. It is what holds the system together and what turbo-charges daily practice.
Practicing the new may feel uncomfortable at first. The anti-patterns on the Organizational Hygiene list above aren’t just habits — they are the job titles, cornerstones of status, and professional identities of people who have built careers on them. TOSD doesn’t pretend that it’s easy to change those things. It does insist that it is necessary. Time-oriented pattern language needs to be adopted and practiced in the weeks before the Go-Live, and for months or years after it.
Remove obstructive practices, change the language — learn more about these and more TOSD patterns in BetaCodex Network research paper No. 27.
Download the paper free of charge: betacodex.org/white-papers/paper/patterns-of-time-oriented-software-development-27. You can also purchase a high-quality print edition of the paper from Red42.
Read the 1st BetaCodex Network research paper on TOSD, Introducing Time-Oriented Software Development
 | A guest post by
|
 | A guest post by
|