How to get going with a TOSD system
In the eighth and final part in our series of articles about "Patterns of Time-Oriented Software Development", we look at steps to prepare the Go Live with TOSD
The 18 patterns in our latest BetaCodex Network research paper describe a whole system of time orientation in software development — and that may sound like a lot. It is a lot, in fact. But jump-starting a TOSD system merely calls for an honest starting-point, rather than a big bang: It means preparing the stage for a minimum setup from which everything else can grow.
The question that most often follows any introduction to the concept of TOSD is practical: “Where does this actually begin?” Fair question. Time-Oriented Software Development is a system, not a menu — a socio-technical philosophy and practice, not a technical framework. So “gradual rollout” or “pick a few practices” does not apply. But starting it is a modest undertaking, not a large one.
The minimum viable TOSD setup consists of a few specific pieces.
One List. Pick a real problem. Not a speculative roadmap item, not a quarter’s worth of ambiguous themes — a specific, bounded problem that a small group of developers can work on and finish. Name it. Define what “exhausted” looks like. That will become the first TOSD List.
One List Owner. Choose a person who cares about the problem. Not assigned by a spreadsheet — someone who would work on the List’s problem even without being asked. It’s about a role, not about position. List Owners shape scope, size items to a day, comb the list every day and stay in love with the problem. Until it’s exhausted.
Identify the Cs and Rs. Assign Conceptualizers and Realizers for this List. Two or three of each may be enough at the start, but there may be more. Some developers may be both C and R. Anyways, these Cs and Rs don’t form a “team” — they work individually and in pairs doing Conceptualization or Realization as the work demands, with handshakes at the OK Point.
On the day of the Go Live, meet at the OK Point at 9:00 am. It will take fifteen to thirty minutes. You must have conceptualized items that are ready for Realizers to be picked up on the day. Realizers will pick items from Conceptualizers, clarify questions about the concepts, shake hands on it, walk away with something they can finish that day. No status update. No going round the room. Item, clarification, handshake, go.
No estimations. No backlog. No Sprint. From day one. Requests for estimates get politely ignored. If someone asks for a “roadmap commitment,” the answer is: That’s what’s currently on the List. That is the level of forecasting available. It is also all that is needed.
They say they want a revolution
During the first week with the TOSD system, watch out for three signals.
Do Realizers find it easy enough to finish their Daily Portions? If not, items are too big, dependencies aren’t clear, masteries are lacking, or Conceptualization ran short. All solvable — but the signal matters, every day.
Is there any good White Space? Realizers finishing early should have visible, respected slack at the end of the day. They can learn, help a colleague, do client work — but they don’t pull the next item until the next day’s OK Point. No White Space means items are oversized or people are overwhelmed. Both are problems.
Does TTEO happen without meetings? People should be talking to each other throughout the day, informally, at low friction. If they default to Slack threads and scheduled syncs, then social density is too low. Remove the barriers; design spaces for encounters; consider travel and meeting in person if they are remote.
Start with one or several Lists, one or several List Owners, the OK Point, and Daily Portions. Drop estimation and backlog on day one. Watch the three signals.
That is day one. Perfecting the eighteen patterns from our latest paper will help you master the TOSD system, over the next three to six months.
Download BetaCodex Network research paper No. 27 here, free of charge: betacodex.org/white-papers/paper/patterns-of-time-oriented-software-development-27. Alternatively, you can buy the paper’s high-quality print edition from Red42.#
Read the 1st BetaCodex Network research paper on TOSD, Introducing Time-Oriented Software Development, free of charge.
 | A guest post by
|
 | A guest post by
|