[{"data":1,"prerenderedAt":133},["ShallowReactive",2],{"docs-\u002Fdocs\u002Fphilosophy":3},{"id":4,"title":5,"body":6,"description":125,"extension":126,"meta":127,"navigation":128,"path":129,"seo":130,"stem":131,"__hash__":132},"docs\u002Fdocs\u002Fphilosophy.md","Core philosophy",{"type":7,"value":8,"toc":118},"minimark",[9,14,18,21,32,35,39,42,50,53,57,63,69,82,85,89,92,112],[10,11,13],"h2",{"id":12},"the-state-machine-framing","The state-machine framing",[15,16,17],"p",{},"Most project management frameworks model software development as a sequence of calendar events - sprints, planning sessions, retrospectives, demos. The calendar becomes the source of truth, which means the calendar becomes the bottleneck.",[15,19,20],{},"FFF rejects this entirely. A ticket is a unit of work with a well-defined lifecycle of discrete states:",[22,23,28],"pre",{"className":24,"code":26,"language":27},[25],"language-text","Inbox → Staged → In Progress → Validating → Done\n","text",[29,30,26],"code",{"__ignoreMap":31},"",[15,33,34],{},"Movement between states is triggered by explicit commands, not by the passage of time. Nothing moves forward on a schedule. Everything moves forward on intent.",[10,36,38],{"id":37},"pull-based-not-push-based","Pull-based, not push-based",[15,40,41],{},"In a push-based system, a manager or scrum master assigns work and expects output by a deadline. Agents (human or AI) are constantly in \"push\" mode - producing at a rate dictated externally.",[15,43,44,45,49],{},"In FFF, work is ",[46,47,48],"strong",{},"pull-based",". The system sits idle until you trigger a ticket. When you trigger it, agents pull the work into their queue and execute until the ticket reaches the next gate. They do not start speculative work. They do not multitask across tickets unless you configure parallelism explicitly.",[15,51,52],{},"This has a profound effect on quality. An agent focused on a single ticket with clear acceptance criteria will outperform an agent juggling five tickets with fuzzy requirements every time.",[10,54,56],{"id":55},"cycle-time-replaces-velocity","Cycle Time replaces velocity",[15,58,59,62],{},[46,60,61],{},"Velocity"," is a Scrum metric that counts story points completed per sprint. It is a measure of output relative to an arbitrary time box. It incentivises inflating estimates to protect the team, and it creates a perverse pressure to close tickets rather than close them correctly.",[15,64,65,68],{},[46,66,67],{},"Cycle Time"," measures elapsed time from the moment a ticket is triggered to the moment it is confirmed as delivered. It is:",[70,71,72,76,79],"ul",{},[73,74,75],"li",{},"Objective - clock time is not negotiable",[73,77,78],{},"Actionable - if Cycle Time is rising, the bottleneck is identifiable",[73,80,81],{},"Honest - a ticket that took eight hours took eight hours",[15,83,84],{},"When you accumulate Cycle Time data across ticket types, you build a genuine probability distribution you can use for forecasting. \"What is the 85th-percentile delivery time for a medium API change?\" is a question Cycle Time data can answer. Velocity cannot.",[10,86,88],{"id":87},"no-sprints-no-planning-sessions","No sprints, no planning sessions",[15,90,91],{},"FFF has no sprint ceremony. There are no planning sessions, no sprint reviews, no retrospectives on a fixed cadence. Instead:",[70,93,94,100,106],{},[73,95,96,99],{},[46,97,98],{},"Refinement"," is continuous and asynchronous - the AI PM and Analytic agents refine the backlog in the background.",[73,101,102,105],{},[46,103,104],{},"Feedback"," is immediate - you see a Validation Package within hours of triggering a ticket, not at the end of a two-week sprint.",[73,107,108,111],{},[46,109,110],{},"Retrospectives"," are replaced by prompt refinement - when an agent makes a poor decision, you improve its instructions, not its \"morale\".",[113,114,115],"blockquote",{},[15,116,117],{},"The goal is a system that delivers continuously and predictably, with the human in the role of strategic director, not operational manager.",{"title":31,"searchDepth":119,"depth":119,"links":120},2,[121,122,123,124],{"id":12,"depth":119,"text":13},{"id":37,"depth":119,"text":38},{"id":55,"depth":119,"text":56},{"id":87,"depth":119,"text":88},"Why FFF treats software delivery as a state machine, not a calendar.","md",{},true,"\u002Fdocs\u002Fphilosophy",{"title":5,"description":125},"docs\u002Fphilosophy","d5_Eshnc7yGoB4vrEC_l99BjLYq25pnQltq4BxeRcWE",1778559261706]