[{"data":1,"prerenderedAt":2337},["ShallowReactive",2],{"resources-list":3},[4,147,250,337,448,562,649,746,828,915,1143,1348,1993,2125],{"id":5,"title":6,"author":7,"body":8,"date":137,"description":138,"extension":139,"meta":140,"navigation":141,"order":142,"path":143,"seo":144,"stem":145,"__hash__":146},"resources\u002Fresources\u002Fwhat-ai-is-great-at-what-people-are-great-at.md","What AI is great at, what people are great at, and how to make them work together","DevStride",{"type":9,"value":10,"toc":129},"minimark",[11,15,18,23,26,55,58,62,65,91,94,98,101,104,107,110,114,117,120],[12,13,14],"p",{},"Most of the noise about AI in delivery is stuck on the wrong question: will it replace the people. The more useful question is quieter and more practical. AI and people are good at almost opposite things, so what does each do best, and how do you combine them without the seams showing?",[12,16,17],{},"Get that division of labor right and you do not have to choose. You get a team that moves at the speed of the machine and decides with the judgment of a person. Get it wrong, in either direction, and you get the worst of both: either people drowning in work a machine should do, or a machine making calls a person should own. Here is the honest breakdown.",[19,20,22],"h2",{"id":21},"what-ai-is-genuinely-great-at","What AI is genuinely great at",[12,24,25],{},"Not everything, and not the things the hype claims. But a specific and valuable set of things, all of which delivery is full of.",[27,28,29,37,43,49],"ul",{},[30,31,32,36],"li",{},[33,34,35],"strong",{},"Tireless legwork."," Breaking an initiative into tasks, sequencing dependencies, drafting estimates, writing the detail back in. Work that is not hard so much as endless, and that people do worse as they get tired. AI does it at a steady quality no human sustains across a long afternoon.",[30,38,39,42],{},[33,40,41],{},"Speed at scale."," Reasoning over hundreds of items, rolling a portfolio up, recomputing every downstream date the moment one thing moves. The mechanical propagation that a person can do for three items and not for three hundred.",[30,44,45,48],{},[33,46,47],{},"Consistency."," Applying the same rule the same way every time, without the drift that creeps into human work under deadline. No shortcuts on item 200 because it is late in the day.",[30,50,51,54],{},[33,52,53],{},"Thoroughness."," Checking every change from several angles without getting bored. Review that stays sharp on the hundredth pass, which is exactly where human attention fades.",[12,56,57],{},"Notice what these have in common. They are all volume, speed, and repetition. None of them is judgment.",[19,59,61],{"id":60},"what-people-are-genuinely-great-at","What people are genuinely great at",[12,63,64],{},"The other half, and it is the half that decides whether the work was any good.",[27,66,67,73,79,85],{},[30,68,69,72],{},[33,70,71],{},"Judgment under ambiguity."," Knowing which tradeoff is right when the data supports two answers. Deciding that a dip in throughput is a team paying down real complexity, not a problem to fix. AI can surface the question. A person answers it.",[30,74,75,78],{},[33,76,77],{},"Context the model cannot see."," The client who is quietly unhappy, the vendor about to slip, the politics behind a deadline, the thing everyone knows and no one wrote down. Delivery runs on this, and almost none of it is in the system for an agent to read.",[30,80,81,84],{},[33,82,83],{},"Accountability."," A person can be responsible for an outcome in a way software cannot. When a call matters, someone has to own it, and ownership is a human property. A model does not answer for a decision. A person does.",[30,86,87,90],{},[33,88,89],{},"Taste and relationships."," Knowing what \"good\" feels like to this client, how to have the hard conversation, when to push and when to absorb. The parts of delivery that are really about people.",[12,92,93],{},"Every one of these is judgment, context, and ownership. None of them is volume.",[19,95,97],{"id":96},"how-they-actually-work-together","How they actually work together",[12,99,100],{},"The two lists are near mirror images, which is the whole point. The combination that works is not a compromise between them. It is a handoff that plays each to its strength.",[12,102,103],{},"Let AI carry the volume: the planning legwork, the propagation, the consistent application of rules, the thorough review. Let people carry the judgment: what to commit to, which tradeoff to make, what ships, who is accountable. Then connect the two with a workflow that makes the handoff explicit, so the agent does its part and stops at the edge where judgment begins, and the person spends their attention only where it is actually required.",[12,105,106],{},"In practice that looks like a loop. An agent drafts the plan and prepares the changes. A person reviews the reasoning and approves the plan. The agent does the build work. The work lands in staging, gets reviewed from several angles, and reaches production only when a person signs off. Volume flows to the machine. The two or three real decisions flow to the human. Neither is doing the other's job.",[12,108,109],{},"The result is a small team that delivers like a much larger one, without the tradeoff people assume they have to make. The speed is real because the agent is genuinely fast at the volume. The quality is real because the judgment never left the building.",[19,111,113],{"id":112},"the-honest-edge","The honest edge",[12,115,116],{},"The division is clean in principle and messy in practice, and it is worth saying so. The boundary between \"legwork\" and \"judgment\" is not always obvious, and drawing it is itself a judgment call you will get wrong sometimes and adjust. An agent will occasionally need a person for something you thought was routine, and a person will sometimes rubber-stamp something they should have caught.",[12,118,119],{},"The point is not a perfect line. It is that there is a line at all, that it is drawn deliberately, and that the workflow enforces it instead of leaving it to whoever is least tired. Get that much right and the question of AI versus people stops mattering, because you are no longer choosing. You are combining.",[12,121,122,123,128],{},"Consider this the front door to ",[124,125,127],"a",{"href":126},"\u002Fresources\u002Fthe-ai-era-delivery-playbook","the AI-era delivery playbook",", which turns the division of labor into an operating model you can run.",{"title":130,"searchDepth":131,"depth":131,"links":132},"",2,[133,134,135,136],{"id":21,"depth":131,"text":22},{"id":60,"depth":131,"text":61},{"id":96,"depth":131,"text":97},{"id":112,"depth":131,"text":113},"2026-07-29","The argument about whether AI will replace project managers is the wrong argument. AI and people are good at almost opposite things. The teams winning right now are not choosing between them, they are combining them on purpose. Here is the division of labor that actually works in delivery.","md",{},true,1,"\u002Fresources\u002Fwhat-ai-is-great-at-what-people-are-great-at",{"title":6,"description":138},"resources\u002Fwhat-ai-is-great-at-what-people-are-great-at","4B8d2-RhAg1feRBSSLj0dlUrfrrPeSMduwT2it8qw8c",{"id":148,"title":149,"author":7,"body":150,"date":137,"description":245,"extension":139,"meta":246,"navigation":141,"order":131,"path":126,"seo":247,"stem":248,"__hash__":249},"resources\u002Fresources\u002Fthe-ai-era-delivery-playbook.md","The AI-era delivery playbook: move at agent speed without losing control",{"type":9,"value":151,"toc":238},[152,155,158,161,165,168,171,175,178,181,188,192,195,198,205,209,212,220,224,227,230],[12,153,154],{},"Project management spent a decade getting more instrumented and no faster. More boards, more fields, more status meetings, and delivery dates that still slipped. AI changes the equation, because for the first time the tooling can do the work of planning and not just record it. An agent can read your live plan, reason over real delivery metrics, break down an initiative, and propose the next moves. That is a real step-change in speed.",[12,156,157],{},"It is also a real new way to lose control. An agent that can touch the plan can touch it wrongly, at scale, faster than a human can notice. The teams getting a genuine lift from AI are not the ones who handed it the keys. They are the ones who built an operating model where AI does the legwork and people keep the judgment, with the handoff written into the workflow rather than left to good intentions.",[12,159,160],{},"This playbook is that operating model, in four principles. Each links to a guide that shows the mechanics. None of it is theory: it is how the DevStride team runs its own delivery, and it is what we built the product to make repeatable.",[19,162,164],{"id":163},"principle-1-the-plan-and-the-work-share-one-model","Principle 1: the plan and the work share one model",[12,166,167],{},"Most stalls trace back to a copy. The plan lives in one tool, the work in another, the status report in a third, and reconciling them is a weekly tax that AI makes worse, not better, because now three disconnected systems can each be wrong at machine speed.",[12,169,170],{},"The fix is structural. When the plan and the work are one model, a status change shows up everywhere at once, and the number an agent reports is the number on the board, because there is one source and not a copy. That single property is what makes it safe to let an agent read your delivery health at all. Everything else in this playbook depends on it.",[19,172,174],{"id":173},"principle-2-guardrails-are-a-workflow-not-a-promise","Principle 2: guardrails are a workflow, not a promise",[12,176,177],{},"The weakest form of AI oversight is a sentence in the docs asking you to review before you accept. Under deadline pressure, that sentence loses every time.",[12,179,180],{},"The strong form is a loop the work actually runs through: the agent prepares a change as a proposal, a person approves it, and the system records who did what and in what order. Nothing is applied on the agent's say-so. We call it propose, approve, record, and it is the difference between oversight you hope for and oversight you get.",[12,182,183,187],{},[124,184,186],{"href":185},"\u002Fresources\u002Fguardrails-for-ai-in-delivery","Guardrails for AI in delivery: the propose, approve, record pattern"," shows how the pattern works and how to set the gate up so it cannot be skipped.",[19,189,191],{"id":190},"principle-3-keep-judgment-where-speed-would-take-it","Principle 3: keep judgment where speed would take it",[12,193,194],{},"\"Human in the loop\" has become a slogan people say and do not build. A loop where the human rubber-stamps whatever the agent produced is not oversight, it is theater with an extra step.",[12,196,197],{},"Real oversight means the person in the loop is making a decision, not confirming one. That requires the agent to surface the tradeoff, not bury it, and it requires the moments of judgment to be named in advance: what always needs a human, and what an agent can carry on its own. Get that boundary right and speed goes up without the decisions leaving the building.",[12,199,200,204],{},[124,201,203],{"href":202},"\u002Fresources\u002Fa-human-in-the-loop-that-actually-holds","A human-in-the-loop that actually holds"," is about drawing that boundary honestly.",[19,206,208],{"id":207},"principle-4-let-the-agent-plan-then-let-it-build-on-a-loop","Principle 4: let the agent plan, then let it build on a loop",[12,210,211],{},"The payoff of the first three principles is the fourth. Once the model is connected, the guardrail is real, and the judgment is placed, you can point an agent at an initiative and have it do the heavy lifting: draft the plan, sequence the dependencies, break the work down, and prepare the changes for a human to approve. Then the same discipline runs the build: work lands in staging, gets reviewed, and reaches production only when a person signs off.",[12,213,214,215,219],{},"The plan-and-build loop is the engine behind the speed. ",[124,216,218],{"href":217},"\u002Fresources\u002Fplan-with-an-agent-without-losing-the-thread","Plan with an agent without losing the thread"," walks through it as a method you can run.",[19,221,223],{"id":222},"the-honest-version-of-the-pitch","The honest version of the pitch",[12,225,226],{},"AI in delivery is not magic and it is not a mascot. It is a very fast, very literal contributor that will do exactly what the system lets it do. If the system lets it apply changes unsupervised, it will. If the system routes every change through a person and a record, you get the speed without the exposure.",[12,228,229],{},"The teams pulling ahead right now are not the ones with the boldest AI. They are the ones with the clearest guardrails. That is the whole playbook.",[12,231,232,233,237],{},"Want to see this operating model running on a real roadmap? ",[124,234,236],{"href":235},"\u002F#cta","Get a guided walkthrough"," and we will point an agent at a plan with you on the call.",{"title":130,"searchDepth":131,"depth":131,"links":239},[240,241,242,243,244],{"id":163,"depth":131,"text":164},{"id":173,"depth":131,"text":174},{"id":190,"depth":131,"text":191},{"id":207,"depth":131,"text":208},{"id":222,"depth":131,"text":223},"AI can now read your plan, reason over your delivery metrics, and propose real changes to the work. That is a genuine step-change in speed, and a genuine new way to lose the plot. Here is the operating model that keeps both the speed and the judgment, drawn from how the DevStride team runs its own delivery.",{},{"title":149,"description":245},"resources\u002Fthe-ai-era-delivery-playbook","l12TGqNMrFA5du3aL7rfFjDBdNG5WaB0m5MmhfV2ozQ",{"id":251,"title":252,"author":7,"body":253,"date":137,"description":330,"extension":139,"meta":331,"navigation":141,"order":332,"path":333,"seo":334,"stem":335,"__hash__":336},"resources\u002Fresources\u002Fthe-green-board-that-lied.md","The green board that lied: why status looks fine until it slips",{"type":9,"value":254,"toc":323},[255,258,261,265,268,271,275,278,281,285,288,291,294,298,301,304,306,309,312],[12,256,257],{},"You have seen this board. Every card is moving. Standups are calm. The status column is a wall of green. Then a delivery date slips, a client is surprised, and everyone asks the same question: how did we not see this coming?",[12,259,260],{},"The board did not lie to you by accident. It lied because of how it was built. A conventional board tracks whether cards are moving, not whether the commitment behind them is still real. Those are different questions, and the gap between them is where every unpleasant surprise lives.",[19,262,264],{"id":263},"green-means-a-card-moved-not-we-will-make-it","Green means \"a card moved,\" not \"we will make it\"",[12,266,267],{},"On most boards, green is a status someone set. A card is in progress, so it is green. The card has been in progress for three weeks, the dependency it is waiting on has not landed, and the date it feeds into is now impossible, but the card is still green, because green only ever meant \"someone is working on this.\"",[12,269,270],{},"The design flaw sits right there. Status is a label on a card. Delivery is a property of the whole system: the work, its dependencies, the sequence, the dates downstream. A board that shows you the labels and hides the system will always look calmer than the truth.",[19,272,274],{"id":273},"the-lie-compounds-when-work-speeds-up","The lie compounds when work speeds up",[12,276,277],{},"Add AI to the picture and the gap widens. More work in flight means more cards moving, more green, more apparent health. If the tool measures motion, an agent generating activity makes the board look better precisely as the risk of an unseen slip goes up. You get a faster, greener board and no more warning than before.",[12,279,280],{},"The problem was never a lack of updates. It was that the updates measured the wrong thing. Speeding up a broken signal does not fix it. It just makes it wrong faster.",[19,282,284],{"id":283},"the-fix-is-structural-not-a-better-status-field","The fix is structural, not a better status field",[12,286,287],{},"You cannot solve this by adding a \"really on track\" checkbox, because that is just another label someone sets by hand and forgets to update. The fix is to connect the plan and the work so status is derived, not declared.",[12,289,290],{},"When the plan and the work share one model, a card is not green because someone said so. It is on track because the system can see that its dependencies are met, its dates still hold, and the work downstream still fits. Move a dependency and every date that relies on it moves with it, visibly, before the slip instead of after. The board stops reporting motion and starts reporting truth, because the truth is computed from the actual state of the plan.",[12,292,293],{},"That single property, one connected model instead of a plan here and the work there, is what turns a status board into an early-warning system. The slip shows up as a change in the dates the moment the cause appears, not in a retro three weeks later.",[19,295,297],{"id":296},"what-seeing-it-coming-actually-looks-like","What \"seeing it coming\" actually looks like",[12,299,300],{},"On a connected model, the surprise gets replaced by a signal. A dependency slips on Tuesday and the dates it feeds shift on Tuesday, not at the deadline. A team falls behind its cycle and the downstream commitments recompute, so the conversation happens while there is still room to act. Nobody had to notice and raise a hand. The system carried the consequence forward automatically.",[12,302,303],{},"A board you check and a board that warns you are not the same instrument. One requires a human to catch every downstream implication in their head. The other does the propagation for you and shows you the result.",[19,305,113],{"id":112},[12,307,308],{},"A connected model tells you the truth about the plan you gave it. It cannot know about the risk you never captured, the vendor who is about to be late, the scope your client has not admitted to yet. Garbage in still gets you garbage out, faster.",[12,310,311],{},"What it removes is a specific and very common failure: the slip that was knowable from the plan itself and simply was not surfaced, because the plan and the work lived in different places and nobody reconciled them in time. That failure is the green board that lied, and a connected model is how you stop living it.",[12,313,314,315,317,318,322],{},"One principle in ",[124,316,127],{"href":126},". For the metrics that read this health honestly, see ",[124,319,321],{"href":320},"\u002Fresources\u002Fdelivery-metrics-that-dont-lie","delivery metrics that don't lie",".",{"title":130,"searchDepth":131,"depth":131,"links":324},[325,326,327,328,329],{"id":263,"depth":131,"text":264},{"id":273,"depth":131,"text":274},{"id":283,"depth":131,"text":284},{"id":296,"depth":131,"text":297},{"id":112,"depth":131,"text":113},"Every team has lived it: the board is green, the standups are calm, and then a date slips and no one saw it coming. The board did not fail you by accident. It failed you by design, because it tracked motion instead of meaning. Here is why, and what a connected model does about it.",{},3,"\u002Fresources\u002Fthe-green-board-that-lied",{"title":252,"description":330},"resources\u002Fthe-green-board-that-lied","e53c97Rx6dOXzh065hX9cq__VqaQ5T1hQ5OKCwJQ97U",{"id":338,"title":339,"author":7,"body":340,"date":137,"description":442,"extension":139,"meta":443,"navigation":141,"order":444,"path":320,"seo":445,"stem":446,"__hash__":447},"resources\u002Fresources\u002Fdelivery-metrics-that-dont-lie.md","Delivery metrics that don't lie: reading throughput, velocity, and cycle time in the AI age",{"type":9,"value":341,"toc":434},[342,345,348,352,355,363,366,370,377,380,384,391,394,398,405,408,412,415,418,420,423,426],[12,343,344],{},"Every delivery metric can be gamed, and AI makes gaming easier. When an agent can spin up items, close them, and move cards at speed, a dashboard can look busier than ever while the thing customers wait for arrives no sooner. The risk in the AI age is not too little activity. It is mistaking activity for progress at a scale no human ever could.",[12,346,347],{},"The metrics worth watching are the ones that resist that. Read them right and they tell you whether value is actually being delivered. Read them lazily and they tell you whether people, or agents, are moving. Here are the four that matter and how to keep them honest.",[19,349,351],{"id":350},"throughput-completed-work-per-period-with-the-reopens-removed","Throughput: completed work per period, with the reopens removed",[12,353,354],{},"Throughput is how much work actually finished in a period. It is the closest thing to a delivery heartbeat, and it has one common failure: counting work as done that later came back.",[12,356,357,358,362],{},"An item marked complete, then reopened because it was not really finished, should not inflate your throughput. If it does, the number rewards the appearance of finishing over the fact of it, which is exactly the behavior a fast contributor will exploit. The fix is to net out reopened items so the total reflects work that stayed done. In DevStride, ",[359,360,361],"code",{},"get_throughput"," does this by default, and it reports a trailing average so a single good or bad week does not read as a trend.",[12,364,365],{},"Watch the direction more than the absolute. Throughput climbing steadily quarter over quarter is a healthy signal. Throughput that spikes and then gives it back is usually rework wearing the costume of output.",[19,367,369],{"id":368},"velocity-what-a-team-completes-per-cycle","Velocity: what a team completes per cycle",[12,371,372,373,376],{},"Velocity is throughput scoped to a team and a cycle. It is useful for planning, because it tells you what a given team has actually been able to complete, not what they hoped to. ",[359,374,375],{},"get_velocity"," gives you that per team.",[12,378,379],{},"The honest use of velocity is forecasting, not comparison. Comparing one team's velocity to another's is how the number goes bad, because two teams estimating differently are not on the same scale. Use it to answer \"what can this team realistically take on next cycle,\" and it stays trustworthy. Use it to rank teams and it becomes a target, and targets get gamed.",[19,381,383],{"id":382},"cycle-time-how-long-work-actually-takes","Cycle time: how long work actually takes",[12,385,386,387,390],{},"Cycle time measures how long work takes from start to finish. It is the metric your customers feel, because it is the wait. Throughput can look fine while cycle time quietly stretches, which means work is starting and finishing but taking longer to get through, often because too much is in progress at once. ",[359,388,389],{},"get_cycle_metrics"," surfaces that.",[12,392,393],{},"Cycle time is the one to watch when you add AI to a team. If an agent helps you start more work but nothing finishes faster, cycle time will say so plainly while throughput hides it. Falling cycle time is the signal that the speed is real and reaching the customer.",[19,395,397],{"id":396},"current-progress-done-versus-in-progress-versus-not-started","Current progress: done versus in progress versus not started",[12,399,400,401,404],{},"The last one is a snapshot, not a rate. ",[359,402,403],{},"get_current_progress"," shows done versus in progress versus not started at any level, from a single team to the whole portfolio. It answers \"where are we right now,\" and it is the antidote to the status meeting, because anyone can see the real picture without someone assembling it by hand.",[12,406,407],{},"The reason it can be trusted is structural. When the plan and the work share one model, current progress is not a report someone compiled, it is the state of the system. The number an agent reads is the number on the board.",[19,409,411],{"id":410},"why-this-matters-more-with-ai-in-the-loop","Why this matters more with AI in the loop",[12,413,414],{},"A human team games metrics slowly and visibly. A team with an agent can game them fast and quietly, not out of malice but because the agent optimizes for whatever you measure. Point it at \"close more items\" and it will, whether or not the work was real. Point it at delivered value, measured by throughput that nets out reopens, velocity used for forecasting, and cycle time the customer feels, and the incentive points the right way.",[12,416,417],{},"The goal is not more numbers. It is fewer numbers you can actually believe.",[19,419,113],{"id":112},[12,421,422],{},"Two caveats worth stating plainly. First, every one of these metrics needs history behind it. A two-week-old workspace has no trend to read, and asking an agent to reason over one will get you confident nonsense. Give it a few cycles before you lean on the numbers.",[12,424,425],{},"Second, no metric replaces judgment. These tell you where to look, not what to do. A dip in throughput might be a problem or might be a team paying down real complexity that pays off next quarter. The metric raises the question. A person still answers it.",[12,427,314,428,430,431,322],{},[124,429,127],{"href":126},". For why a connected model is what makes any of these numbers trustworthy, see ",[124,432,433],{"href":333},"the green board that lied",{"title":130,"searchDepth":131,"depth":131,"links":435},[436,437,438,439,440,441],{"id":350,"depth":131,"text":351},{"id":368,"depth":131,"text":369},{"id":382,"depth":131,"text":383},{"id":396,"depth":131,"text":397},{"id":410,"depth":131,"text":411},{"id":112,"depth":131,"text":113},"When an agent can generate work faster, vanity metrics get easier to hit and harder to trust. Here is how to read throughput, velocity, and cycle time so the numbers reflect delivered value, not motion, including the one adjustment most tools skip: netting out reopened work.",{},4,{"title":339,"description":442},"resources\u002Fdelivery-metrics-that-dont-lie","_dMxWb5EDuyixMVGGNMbHUfPjptwL6tav_Okh9jcZjk",{"id":449,"title":186,"author":7,"body":450,"date":137,"description":556,"extension":139,"meta":557,"navigation":141,"order":558,"path":185,"seo":559,"stem":560,"__hash__":561},"resources\u002Fresources\u002Fguardrails-for-ai-in-delivery.md",{"type":9,"value":451,"toc":549},[452,455,463,466,470,473,482,489,493,496,499,503,506,509,513,516,519,522,524,527,534,537,540],[12,453,454],{},"There are two kinds of AI guardrail, and only one of them works.",[12,456,457,458,462],{},"The first kind is a promise. It lives in a policy doc or an onboarding slide: ",[459,460,461],"em",{},"always review the agent's changes before accepting them."," It sounds responsible. It survives right up until the sprint is behind, the change looks fine at a glance, and someone clicks accept without really reading. A guardrail that depends on human discipline under pressure is not a guardrail. It is a good intention with a paper trail.",[12,464,465],{},"The second kind is a workflow. The oversight is not something you are asked to do, it is something the system does to every change, whether anyone remembers to or not. That is the pattern worth building, and it has three moves.",[19,467,469],{"id":468},"propose","Propose",[12,471,472],{},"The agent never applies a change directly. It prepares one. Point it at an initiative and ask it to pull the next two items into the cycle, and it does not move them. It drafts the move and hands it back:",[474,475,480],"pre",{"className":476,"code":478,"language":479},[477],"language-text","> Pull the next two Checkout items into this cycle.\n# drafting proposal · nothing applied yet\nProposed: move 2 items (I6825, I6746) into the current cycle,\nupdate affected dates. Waiting on your go-ahead.\n","text",[359,481,478],{"__ignoreMap":130},[12,483,484,485,488],{},"The important word is ",[459,486,487],{},"proposed",". Nothing has changed on the board. The agent has done the legwork, the reasoning, and the mechanical preparation, and then it has stopped at the exact point where judgment begins.",[19,490,492],{"id":491},"approve","Approve",[12,494,495],{},"A person makes the call. Not a rubber stamp, an actual decision, because the proposal gives them what they need to make one: what will change, what it affects, and what it costs downstream. Approve it and the change is applied through the real tools. Decline it and nothing happened.",[12,497,498],{},"Approval is the step most \"AI in your PM tool\" pitches quietly skip. They demo the agent doing something impressive and imply a human was watching. Watching is not approving. The gate only counts if the change genuinely cannot proceed without it.",[19,500,502],{"id":501},"record","Record",[12,504,505],{},"Every action, the agent's and the human's, lands on one shared record with a name on it. The proposal is attributed to the agent that made it. The approval is attributed to the person who gave it. The applied change shows both, in order. Six weeks later, when someone asks why a date moved, the answer is not a shrug. It is a record.",[12,507,508],{},"Recording is what turns oversight into accountability. A change you approved but cannot trace is only half-governed. The record closes the loop.",[19,510,512],{"id":511},"why-the-pattern-has-to-be-structural","Why the pattern has to be structural",[12,514,515],{},"You could try to run propose, approve, record by convention: agree as a team that no one applies an AI change without review, and hope it holds. It will hold on a calm week and break on a hard one, which is precisely when you needed it.",[12,517,518],{},"Building it into the workflow removes the discipline requirement. The agent cannot apply a change because the system does not let it. The human cannot skip the record because the system writes it. The guardrail does not rely on anyone being careful, which means it is still there on the day everyone is rushing.",[12,520,521],{},"The same logic extends to code. In the DevStride delivery loop, work an agent produces lands in staging and reaches production only when a person signs off. The gate is a state the work has to pass through, not a reminder someone has to honor.",[19,523,113],{"id":112},[12,525,526],{},"Two things worth saying plainly, because a careful reader will test both.",[12,528,529,530,533],{},"First, propose, approve, record governs ",[459,531,532],{},"how changes are applied",", not whether the underlying system is a sandbox. When you approve a write, it is real and immediate. There is no undo waiting behind it. Read first, approve deliberately.",[12,535,536],{},"Second, the pattern is only as strong as its enforcement. A \"propose then approve\" flow that a user can toggle off is back to being a promise. The value is entirely in the change not being able to happen any other way.",[12,538,539],{},"Get that right and you have the thing every AI-in-delivery vendor gestures at and few actually build: speed you can trust, because the trust is in the workflow and not in the pitch.",[12,541,542,543,545,546,322],{},"One of four principles in ",[124,544,127],{"href":126},". To see the gate running on a real plan, ",[124,547,548],{"href":235},"get a guided walkthrough",{"title":130,"searchDepth":131,"depth":131,"links":550},[551,552,553,554,555],{"id":468,"depth":131,"text":469},{"id":491,"depth":131,"text":492},{"id":501,"depth":131,"text":502},{"id":511,"depth":131,"text":512},{"id":112,"depth":131,"text":113},"Most AI oversight is a sentence in the docs asking you to review before you accept. Under deadline pressure that sentence loses. Here is the alternative: a guardrail built into the workflow, where the agent proposes, a human approves, and the system records, so the oversight is something you get, not something you hope for.",{},5,{"title":186,"description":556},"resources\u002Fguardrails-for-ai-in-delivery","FFY3C-l35PCJcjRO8tGVqc5Bt1eZCe4bZSRTgMYVuhw",{"id":563,"title":203,"author":7,"body":564,"date":137,"description":643,"extension":139,"meta":644,"navigation":141,"order":645,"path":202,"seo":646,"stem":647,"__hash__":648},"resources\u002Fresources\u002Fa-human-in-the-loop-that-actually-holds.md",{"type":9,"value":565,"toc":636},[566,569,572,575,579,582,585,588,592,595,598,602,605,608,612,615,618,622,625,628],[12,567,568],{},"Every AI-in-delivery vendor now says the same three words: human in the loop. It has become the reassurance you reach for when someone worries about handing judgment to a machine. Say it and the worry is supposed to go away.",[12,570,571],{},"It should not go away that easily, because most human-in-the-loop setups do not survive contact with a busy week. A loop where the person confirms whatever the agent already decided is not oversight. It is a slower way of doing what the agent wanted, with a human name attached for comfort. The rubber stamp is worse than no human at all, because it manufactures the appearance of judgment where none happened.",[12,573,574],{},"A loop that actually holds has three properties. None of them are about adding a human. They are about making the human's presence mean something.",[19,576,578],{"id":577},"the-human-is-deciding-not-confirming","The human is deciding, not confirming",[12,580,581],{},"The test is simple. In your current setup, could the person in the loop realistically say no?",[12,583,584],{},"If the only information they get is \"the agent did X, approve?\" then no is not a real option, because they have nothing to weigh it against. They approve because refusing would mean redoing the analysis themselves, which is the whole thing they were trying to avoid. That is confirmation wearing the costume of a decision.",[12,586,587],{},"A real decision needs the tradeoff on the table: what changes, what it affects, what it costs, and what the alternative was. When the agent surfaces the reasoning instead of burying it in a result, the human can actually exercise judgment. They can approve, adjust, or reject, and any of the three is a live outcome.",[19,589,591],{"id":590},"the-moments-of-judgment-are-named-in-advance","The moments of judgment are named in advance",[12,593,594],{},"Not every action needs a person. If you route all of them through a human, you have not built oversight, you have built a bottleneck, and bottlenecks get bypassed. The skill is deciding ahead of time which moments genuinely require judgment and which an agent can carry on its own.",[12,596,597],{},"A useful default: an agent can move freely inside a boundary and must stop at the edges of it. Reading the plan, drafting a breakdown, sequencing dependencies, preparing a change, these are inside the boundary. Applying a change to shared work, shipping to production, altering scope or commitments, these are edges. Name the edges explicitly and the loop stops being a vague promise to \"stay involved\" and becomes a specific contract about where humans decide.",[19,599,601],{"id":600},"the-record-makes-the-judgment-inspectable","The record makes the judgment inspectable",[12,603,604],{},"A decision no one can trace is only half a decision. When the human's approval and the agent's proposal both land on one shared record, with names and an order, the loop becomes auditable after the fact. You can answer why something happened, who approved it, and what it was weighed against.",[12,606,607],{},"The trail matters more with AI in the mix, not less. The faster the contributor, the more important it is that its work leaves a record a person actually signed. Attribution is not bureaucracy here. It is the thing that lets you trust speed.",[19,609,611],{"id":610},"what-this-looks-like-in-practice","What this looks like in practice",[12,613,614],{},"The DevStride delivery loop draws the boundary this way. An agent does the legwork of planning and building: it drafts the plan, breaks down the work, and prepares changes. Every change is a proposal until a person approves it. Code an agent writes lands in staging and reaches production only on a human sign-off. And every action, human or agent, is recorded with a name.",[12,616,617],{},"The result is not less AI. It is more, used harder, because the boundary is clear enough to trust. When people know exactly where their judgment is required, they stop hovering over the parts that do not need them, and the speed shows up.",[19,619,621],{"id":620},"the-honest-version","The honest version",[12,623,624],{},"You cannot buy a human-in-the-loop. You design one. It holds when the person can say no, when the moments that need them are named, and when the whole thing is on the record. It fails when \"human in the loop\" is a line on a slide and the human is a formality.",[12,626,627],{},"Speed and judgment are not a tradeoff you have to make. They are a boundary you have to draw, and then enforce in the workflow so it holds on the hard weeks too.",[12,629,542,630,632,633,322],{},[124,631,127],{"href":126},". The enforcement mechanism behind it is ",[124,634,635],{"href":185},"propose, approve, record",{"title":130,"searchDepth":131,"depth":131,"links":637},[638,639,640,641,642],{"id":577,"depth":131,"text":578},{"id":590,"depth":131,"text":591},{"id":600,"depth":131,"text":601},{"id":610,"depth":131,"text":611},{"id":620,"depth":131,"text":621},"\"Human in the loop\" has become a slogan people say and do not build. A loop where the person rubber-stamps whatever the agent produced is theater with an extra step. Real oversight means the human is making a decision, not confirming one. Here is how to draw that line honestly.",{},6,{"title":203,"description":643},"resources\u002Fa-human-in-the-loop-that-actually-holds","OlK_mnU5CD5_4pbf39TJLVa4VoPiat6oEkVkQzCpz8w",{"id":650,"title":218,"author":7,"body":651,"date":137,"description":740,"extension":139,"meta":741,"navigation":141,"order":742,"path":217,"seo":743,"stem":744,"__hash__":745},"resources\u002Fresources\u002Fplan-with-an-agent-without-losing-the-thread.md",{"type":9,"value":652,"toc":732},[653,656,659,663,666,669,673,676,679,683,686,689,693,696,699,703,706,709,711,714,717],[12,654,655],{},"Ask an agent to \"plan this project\" and you usually get one of two failures. Either a wall of plausible-looking tasks that no one trusts enough to act on, or a plan that reads well and has quietly drifted from what you meant, so you spend more time correcting it than you would have spent planning yourself. Both come from the same mistake: treating planning as a single prompt instead of a loop.",[12,657,658],{},"The teams getting real leverage from AI planning run it as a loop with checkpoints, where the agent does the heavy lifting and a human keeps the thread at the points that matter. Here is the method, the way the DevStride team runs it on its own work.",[19,660,662],{"id":661},"start-from-the-real-plan-not-a-blank-slate","Start from the real plan, not a blank slate",[12,664,665],{},"An agent planning from nothing invents context, and invented context is where drift starts. Point it at the live plan instead: the initiative, the existing work, the dependencies, the delivery history. Because the plan and the work share one model, the agent is reasoning over the actual state of the project, not a description of it. The breakdown it proposes is anchored to real items, not imagined ones.",[12,667,668],{},"A connected model is the quiet prerequisite for everything else. An agent working from it can be checked against reality at every step. An agent working from a paste of your project can only be checked against your patience.",[19,670,672],{"id":671},"let-it-draft-then-read-the-reasoning-not-just-the-result","Let it draft, then read the reasoning, not just the result",[12,674,675],{},"The agent's first job is the legwork: break the initiative into work, sequence the dependencies, estimate, and surface the risks. That is genuinely faster than doing it by hand, and it is where most of the time savings live.",[12,677,678],{},"The checkpoint is not \"is the output plausible.\" It is \"is the reasoning right.\" Read why the agent sequenced the work the way it did, which dependencies it flagged, and what it assumed. A plan you accept because it looks tidy is how drift gets in. A plan you accept because the reasoning holds is one you can build on. This is the first place a human keeps the thread.",[19,680,682],{"id":681},"approve-the-plan-before-anything-is-built","Approve the plan before anything is built",[12,684,685],{},"The plan is a proposal until a person signs off on it. That single gate is what keeps agent planning from becoming agent doing. Approving the plan is the highest-leverage decision in the loop, because everything downstream inherits it. Spend judgment here, generously.",[12,687,688],{},"Once approved, the plan is not a document that rots in a wiki. It is the live model the build runs against, so the thing you signed off on is the thing the work is measured against.",[19,690,692],{"id":691},"build-on-the-same-loop","Build on the same loop",[12,694,695],{},"Planning and building are the same discipline at different altitudes. With the plan approved, an agent can take on the build work, and the same guardrail applies: changes are proposals until approved, code lands in staging, and it reaches production only when a person signs off. A review step sits in between, so nothing ships on a single unchecked pass.",[12,697,698],{},"The effect is a loop that runs fast without running away. The agent carries the volume. The human carries the judgment at the two points that matter most: approving the plan, and approving what ships. Between those points, the speed is real, because the checkpoints are real.",[19,700,702],{"id":701},"where-the-thread-actually-lives","Where the thread actually lives",[12,704,705],{},"Notice what the human is not doing. They are not writing every task. They are not sequencing every dependency by hand. They are not watching the agent work. They are holding two decisions, the plan and the release, and letting the agent do the rest.",[12,707,708],{},"Holding those two decisions, and no more, is the whole trick to planning with an agent without losing the thread. You do not stay involved in everything. You stay involved in the few decisions that set the direction, and you make the workflow enforce that boundary so it holds even when the week is fast.",[19,710,113],{"id":112},[12,712,713],{},"The loop is a method, not a guarantee. Its output is only as good as the model it plans from, so a workspace with no delivery history behind it will give an agent thin ground to reason on. And the approval gates only protect you if they are real gates, not optional ones. The value is in the plan genuinely not proceeding until a person has read the reasoning and signed off.",[12,715,716],{},"Run it that way and agent planning stops being a gamble and becomes a routine: fast because the agent does the work, safe because the judgment stays placed.",[12,718,719,720,722,723,725,726,729,730,322],{},"The fourth principle in ",[124,721,127],{"href":126},". It rests on ",[124,724,635],{"href":185}," and ",[124,727,728],{"href":202},"a human-in-the-loop that actually holds",". To run the loop against a real roadmap, ",[124,731,548],{"href":235},{"title":130,"searchDepth":131,"depth":131,"links":733},[734,735,736,737,738,739],{"id":661,"depth":131,"text":662},{"id":671,"depth":131,"text":672},{"id":681,"depth":131,"text":682},{"id":691,"depth":131,"text":692},{"id":701,"depth":131,"text":702},{"id":112,"depth":131,"text":113},"Handing planning to an agent usually goes one of two ways: it produces a wall of tasks nobody trusts, or it quietly drifts from what you actually meant. The plan-and-build loop is the method that avoids both. Here is how it runs, drawn from how the DevStride team plans and ships its own work.",{},7,{"title":218,"description":740},"resources\u002Fplan-with-an-agent-without-losing-the-thread","XRaQX6Oq9jiiKIJG1bPWYY62u508YFvUGpqMHIWvXME",{"id":747,"title":748,"author":7,"body":749,"date":137,"description":821,"extension":139,"meta":822,"navigation":141,"order":823,"path":824,"seo":825,"stem":826,"__hash__":827},"resources\u002Fresources\u002Fadversarial-review-as-a-team-habit.md","Adversarial review as a team habit: why one AI pass is not enough",{"type":9,"value":750,"toc":814},[751,754,757,761,764,767,771,774,777,781,784,787,791,794,797,799,802,805],[12,752,753],{},"The fastest way to get burned by AI in delivery is to trust the first answer because it sounds sure. A single agent reviewing its own work, or one model checking a change, produces a confident opinion. Confident is not the same as correct, and the gap between them is where defects ship.",[12,755,756],{},"The teams getting real quality out of AI have stopped treating review as one pass. They treat it as scrutiny the work has to survive, from more than one reviewer, before a person makes the final call. It is a habit, not a step, and it is worth building deliberately.",[19,758,760],{"id":759},"one-reviewer-has-one-set-of-blind-spots","One reviewer has one set of blind spots",[12,762,763],{},"Any single reviewer, human or AI, has a characteristic way of missing things. A model trained one way will reliably overlook a certain class of problem, approve a certain kind of shortcut, and be blind to a certain category of edge case. Run everything past that one reviewer and its blind spots become your blind spots, quietly, on every change.",[12,765,766],{},"The point of more than one reviewer is not redundancy for its own sake. It is that different reviewers fail differently. What one waves through, another catches, because they do not share the same blind spots. The overlap of two or three independent passes is far smaller than any one of them alone, which is the entire value.",[19,768,770],{"id":769},"make-the-reviewers-actually-independent","Make the reviewers actually independent",[12,772,773],{},"Adversarial review only works if the reviews are genuinely separate. Two passes that share the same context, the same prompt, and the same assumptions are not two reviews, they are one review run twice, and they will agree on their shared mistakes.",[12,775,776],{},"Independence means each reviewer comes at the work from its own angle: one checking correctness, another probing for the failure case, another asking whether the change even does what was asked. The DevStride delivery loop runs review this way on purpose, with more than one engine examining a change before it moves, so a single model's confidence is never the last word. The goal is disagreement where it matters, because disagreement is the signal that something needs a human's attention.",[19,778,780],{"id":779},"let-the-machines-argue-then-let-a-human-decide","Let the machines argue, then let a human decide",[12,782,783],{},"The output of good adversarial review is not a verdict. It is a sharper question. When two reviewers disagree about a change, that disagreement is exactly what you want in front of the person who signs off, because it points them at the decision that actually needs judgment instead of burying it under a wall of green checkmarks.",[12,785,786],{},"Divide the labor that way and it works. The reviewers do the tireless, thorough, unglamorous work of examining every change from several angles. The human spends their judgment on the few places the machines flagged as contested. You get the coverage of many passes and the discernment of a person, applied where it counts.",[19,788,790],{"id":789},"why-this-scales-where-manual-review-does-not","Why this scales where manual review does not",[12,792,793],{},"Human code review does not scale with AI-speed output. If agents are producing changes faster than people can read them, asking humans to carefully review every one is asking them to become the bottleneck, and bottlenecks get skipped under pressure. Skipped review is how the speed turns into risk.",[12,795,796],{},"Adversarial AI review is what keeps the throughput honest. The machines can review at the rate the machines produce, which means every change gets real scrutiny, and the human is pulled in for the contested calls rather than drowning in all of them. The habit is what lets you ship fast without shipping blind.",[19,798,113],{"id":112},[12,800,801],{},"More reviewers reduce the odds of a miss. They do not eliminate them. Several models can share a blind spot, agree confidently, and all be wrong together, which is precisely why the human sign-off is not optional and the work still lands in staging before production. Adversarial review is a way to make the human's judgment better targeted, not a way to remove it.",[12,803,804],{},"Treat it as insurance, not a guarantee, and it earns its place: fewer defects reach the person, and the ones that do arrive with a reason to look closely.",[12,806,314,807,809,810,322],{},[124,808,127],{"href":126},". For where the final human gate sits, see ",[124,811,813],{"href":812},"\u002Fresources\u002Fstaging-is-the-safety-net","staging is the safety net",{"title":130,"searchDepth":131,"depth":131,"links":815},[816,817,818,819,820],{"id":759,"depth":131,"text":760},{"id":769,"depth":131,"text":770},{"id":779,"depth":131,"text":780},{"id":789,"depth":131,"text":790},{"id":112,"depth":131,"text":113},"A single AI review is a confident opinion, and confident opinions miss things. The teams getting real quality from AI do not trust one pass. They make the work survive scrutiny from more than one reviewer before a human signs off. Here is how to build that into how you ship.",{},8,"\u002Fresources\u002Fadversarial-review-as-a-team-habit",{"title":748,"description":821},"resources\u002Fadversarial-review-as-a-team-habit","MXoj9EuW0hPo2212UQF6nWOg3_djZtHhofZPWmkRr9E",{"id":829,"title":830,"author":7,"body":831,"date":137,"description":909,"extension":139,"meta":910,"navigation":141,"order":911,"path":812,"seo":912,"stem":913,"__hash__":914},"resources\u002Fresources\u002Fstaging-is-the-safety-net.md","Staging is the safety net: why nothing an agent builds ships without a human sign-off",{"type":9,"value":832,"toc":902},[833,836,839,843,846,849,852,856,859,862,866,869,872,876,879,882,884,887,890],[12,834,835],{},"Ask what makes it safe to let an agent build real work, and the honest answer is not a clever model or a careful prompt. It is a boring piece of plumbing: the work lands in staging, and a person signs off before it reaches production. No sign-off, no production. The gate is a state the work has to pass through, not a reminder someone is supposed to honor.",[12,837,838],{},"That one arrangement does more for trust than any amount of model tuning, because it changes what a mistake costs. Get this gate right and an agent can move fast, because the worst case is caught before it reaches anyone. Get it wrong and every gain in speed is borrowed against the day something ships that should not have.",[19,840,842],{"id":841},"the-gate-has-to-be-a-state-not-a-suggestion","The gate has to be a state, not a suggestion",[12,844,845],{},"The weak version of this is a norm: we agree that AI-built changes get reviewed before they go live. Norms hold on calm weeks and break on the week you needed them, which is the week the release is late and the change looks fine at a glance.",[12,847,848],{},"The strong version removes the choice. The work cannot reach production without passing through staging and a human sign-off, because the workflow does not offer a path around it. The agent produces the change, it lands in staging, a person reviews it in a real environment, and only their sign-off promotes it. Nobody has to remember to be careful. The careful part is built into where the work can go.",[12,850,851],{},"In the DevStride delivery loop, this is exactly how it runs. Code an agent writes lands in staging. Production is reached only on a human sign-off. The gate is not a message in the docs. It is a stage the work is in until a person moves it.",[19,853,855],{"id":854},"staging-is-where-speed-becomes-safe","Staging is where speed becomes safe",[12,857,858],{},"The instinct is to see the gate as a brake on the agent. It is closer to the opposite. The reason you can let an agent work quickly is that a fast mistake lands somewhere recoverable. Staging is that somewhere. A change that is wrong in staging costs a review comment. The same change in production costs an incident.",[12,860,861],{},"So the gate is what makes the speed usable. Without it, every agent-built change carries production risk, and you end up slowing the agent down out of fear, which gives back the whole advantage. With it, the agent can move at its natural pace, because the blast radius of being wrong is a staging environment and a person who has not clicked approve yet.",[19,863,865],{"id":864},"the-sign-off-is-a-decision-not-a-formality","The sign-off is a decision, not a formality",[12,867,868],{},"A gate only works if the person at it is actually deciding. A sign-off that everyone clicks without looking is theater, and it fails exactly like a norm does. The point of staging is that the reviewer can see the change in a real environment, with the context to judge it, and can genuinely say no.",[12,870,871],{},"That means the sign-off should give them something to decide with: what changed, what it affects, and a place to see it running before it is live. Give the reviewer a real look and a real veto, and the gate carries weight. Reduce it to a rubber stamp and you have the appearance of a safety net with none of the catch.",[19,873,875],{"id":874},"why-this-is-the-keystone-of-the-whole-playbook","Why this is the keystone of the whole playbook",[12,877,878],{},"Every other principle leans on this one. Propose, approve, record governs how changes get applied. A human in the loop places judgment where it belongs. Adversarial review sharpens what the human looks at. Staging is where all of that resolves into a single, unbypassable moment: the work is real, it is reviewable, and it does not go live until a person says so.",[12,880,881],{},"Remove this gate and the rest becomes decoration, because a system that can ship to production on its own is not overseen no matter how many review steps precede it. Keep it, and the speed of everything upstream is safe to use, because the last word is always human and always enforced.",[19,883,113],{"id":112},[12,885,886],{},"Two things worth saying straight. First, the gate is only as strong as its enforcement. A staging step a user can toggle off, or a sign-off that can be auto-approved, is back to being a suggestion. The entire value is that the path to production genuinely does not exist without a person on it.",[12,888,889],{},"Second, a human gate is not a promise of perfection. People approve bad changes sometimes. What the gate guarantees is not that every release is flawless, but that every release was a human decision, on the record, with a chance to catch it in a safe environment first. In the AI age, that guarantee, speed you can trace back to a person who chose it, is the one worth building your delivery around.",[12,891,892,893,895,896,898,899,322],{},"The keystone principle of ",[124,894,127],{"href":126},". It is enforced by ",[124,897,635],{"href":185}," and sharpened by ",[124,900,901],{"href":824},"adversarial review",{"title":130,"searchDepth":131,"depth":131,"links":903},[904,905,906,907,908],{"id":841,"depth":131,"text":842},{"id":854,"depth":131,"text":855},{"id":864,"depth":131,"text":865},{"id":874,"depth":131,"text":875},{"id":112,"depth":131,"text":113},"The single most important guardrail for AI-built work is boring: it lands in staging, and a person signs off before it reaches production. Not a modal, not a policy, a state the work has to pass through. Here is why that one gate does more for trust than any amount of model tuning.",{},9,{"title":830,"description":909},"resources\u002Fstaging-is-the-safety-net","E6FJ9Ck9FhaB3bk-xMkcks0FgRvaGmpeLcPCYCdJUkY",{"id":916,"title":917,"author":7,"body":918,"date":137,"description":1136,"extension":139,"meta":1137,"navigation":141,"order":1138,"path":1139,"seo":1140,"stem":1141,"__hash__":1142},"resources\u002Fresources\u002Fpoint-claude-at-your-plan-in-10-minutes.md","Point Claude at your plan in 10 minutes: the DevStride MCP, end to end",{"type":9,"value":919,"toc":1128},[920,923,926,936,945,949,963,967,970,976,982,989,993,996,999,1005,1010,1036,1042,1046,1049,1054,1065,1068,1072,1075,1109,1113],[12,921,922],{},"Most project-tool MCP servers do one thing: an agent asks for a ticket, the server hands back a ticket. Useful, shallow.",[12,924,925],{},"The DevStride MCP is different in kind. It lets an agent read your live plan, reason over real delivery metrics, and propose real changes to the work, while a human keeps the final say. Same protocol, a very different amount of leverage.",[12,927,928,929,935],{},"This guide takes you from nothing to an agent working your plan. It uses the real tool names, shows the shape of what comes back, and is honest about the edges. If you would rather read the reference first, the full setup and tool catalog live in the ",[124,930,934],{"href":931,"rel":932},"https:\u002F\u002Fdocs.devstride.com\u002Fintegrations-and-extensibility\u002Fdevstride-mcp-server\u002Fwhat-is-the-devstride-mcp-server",[933],"nofollow","DevStride MCP Server docs","; this piece shows the tools in use.",[937,938,939],"blockquote",{},[12,940,941,944],{},[33,942,943],{},"A note on the examples."," The responses below are representative. Yours will differ, because they come from your workspace. The point of the walkthrough is the sequence and the tool names, both of which are real.",[19,946,948],{"id":947},"what-you-need","What you need",[27,950,951,960],{},[30,952,953,954,959],{},"A DevStride workspace (the ",[124,955,958],{"href":956,"rel":957},"https:\u002F\u002Fdocs.devstride.com\u002Fintegrations-and-extensibility\u002Fdevstride-mcp-server\u002Fsetting-up-your-connection",[933],"Connect AI page"," is where you generate the connection).",[30,961,962],{},"An AI client that speaks MCP: Claude, ChatGPT, Cursor, Copilot, Codex, or Gemini CLI. Your client's own subscription is separate from DevStride.",[19,964,966],{"id":965},"step-1-connect-about-2-minutes","Step 1: connect (about 2 minutes)",[12,968,969],{},"Add the DevStride MCP server to your client and authorize it. Connection uses OAuth, scoped to your permissions in DevStride, so the agent can only see and touch what you can. There is no long-lived API key to paste around.",[12,971,972,973,322],{},"Once connected, confirm the agent is talking to the right workspace. Ask it to run ",[359,974,975],{},"whoami",[474,977,980],{"className":978,"code":979,"language":479},[477],"> whoami\n{\n  \"username\": \"you\",\n  \"name\": \"Your Name\",\n  \"teams\": [ \"Platform\", \"Growth\", ... ]\n}\n",[359,981,979],{"__ignoreMap":130},[12,983,984,985,988],{},"If the name and teams are yours, you are in. If you manage more than one organization, ",[359,986,987],{},"get_workspace_context"," returns the active org's configuration: its work types, statuses, priorities, and the IDs the other tools take as input.",[19,990,992],{"id":991},"step-2-read-your-plan","Step 2: read your plan",[12,994,995],{},"Start read-only. Here is where the difference from a ticket lookup shows up: the agent is not fetching one item, it is querying a live model.",[12,997,998],{},"Ask a plain-language question and let the agent pick the tool.",[474,1000,1003],{"className":1001,"code":1002,"language":479},[477],"> How is throughput trending this quarter?\n# calling get_throughput\nUp quarter over quarter. Three teams are ahead of plan;\nCheckout can pull work forward.\n",[359,1004,1002],{"__ignoreMap":130},[12,1006,1007,1009],{},[359,1008,361],{}," returns completed work per period with a trailing average, and it nets out reopened items so the totals stay honest. Its siblings answer the other questions leaders actually ask:",[27,1011,1012,1017,1022,1027],{},[30,1013,1014,1016],{},[359,1015,375],{}," for what a team completes per cycle.",[30,1018,1019,1021],{},[359,1020,389],{}," for how long work takes from start to finish.",[30,1023,1024,1026],{},[359,1025,403],{}," for done versus in progress versus not started, at any level.",[30,1028,1029,725,1032,1035],{},[359,1030,1031],{},"search_items",[359,1033,1034],{},"get_item_hierarchy"," to pull the actual work behind any number.",[12,1037,1038,1039,1041],{},"Because the plan and the work share one model, the figure the agent reports is the same figure on your board. Verify it: pull the number from ",[359,1040,389],{},", then open the board. They match, because there is one source, not a copy.",[19,1043,1045],{"id":1044},"step-3-propose-a-real-change-with-a-human-gate","Step 3: propose a real change (with a human gate)",[12,1047,1048],{},"Reading is table stakes. The reason the DevStride MCP is worth connecting is that the agent can move real work, and the guardrail is that it does so as a proposal, not a fait accompli.",[474,1050,1052],{"className":1051,"code":478,"language":479},[477],[359,1053,478],{"__ignoreMap":130},[12,1055,1056,1057,1060,1061,1064],{},"When you approve, the change is applied through the real tools, for example ",[359,1058,1059],{},"move_to_cycle"," for the reschedule and ",[359,1062,1063],{},"bulk_update_items"," for a batch, and it lands on the shared record attributed to both the agent that proposed it and you, the person who approved it. The record shows who did what, and in what order.",[12,1066,1067],{},"Here is the part that matters, and the part most \"AI in your PM tool\" pitches skip. The oversight is not a sentence in the docs asking you to review before you accept. Propose-then-approve is how the loop runs: the agent prepares the decision, you make it, the system records and executes it.",[19,1069,1071],{"id":1070},"the-honest-edges","The honest edges",[12,1073,1074],{},"A technical reader will test exactly one of these, so here is the truth up front:",[27,1076,1077,1091,1097,1103],{},[30,1078,1079,1082,1083,1086,1087,1090],{},[33,1080,1081],{},"The MCP writes live data."," There is no separate sandbox. A ",[359,1084,1085],{},"create_item"," or ",[359,1088,1089],{},"update_item"," you approve is immediate. Read first, approve deliberately.",[30,1092,1093,1096],{},[33,1094,1095],{},"The gate is in the workflow, not a fake modal."," The propose-then-approve pattern is enforced by how DevStride's plan-and-build loop runs, and code changes land in staging with a human sign-off before they reach production. It is not a claim that an app dialog blocks every write.",[30,1098,1099,1102],{},[33,1100,1101],{},"Scopes are real."," The agent inherits your permissions. It cannot see or change what you cannot.",[30,1104,1105,1108],{},[33,1106,1107],{},"Numbers need history."," Velocity and cycle-time reports are only as meaningful as the data behind them; a two-week-old workspace will not have a trend yet.",[19,1110,1112],{"id":1111},"where-to-go-next","Where to go next",[27,1114,1115,1123],{},[30,1116,1117,1118,1122],{},"The ",[124,1119,1121],{"href":931,"rel":1120},[933],"MCP Server docs"," carry the full tool reference, parameters, and auth setup. Keep this guide for the why, keep the docs for the exact signatures.",[30,1124,1125,1126,237],{},"Want to see the same loop run against a real roadmap, end to end? ",[124,1127,236],{"href":235},{"title":130,"searchDepth":131,"depth":131,"links":1129},[1130,1131,1132,1133,1134,1135],{"id":947,"depth":131,"text":948},{"id":965,"depth":131,"text":966},{"id":991,"depth":131,"text":992},{"id":1044,"depth":131,"text":1045},{"id":1070,"depth":131,"text":1071},{"id":1111,"depth":131,"text":1112},"Most project-tool MCP servers let an agent look up a ticket. DevStride's lets an agent read your live plan, reason over real delivery metrics, and propose real changes, with a human keeping the final say. Here is the full connect-and-run walkthrough.",{},10,"\u002Fresources\u002Fpoint-claude-at-your-plan-in-10-minutes",{"title":917,"description":1136},"resources\u002Fpoint-claude-at-your-plan-in-10-minutes","KuQ65QyGtd8Rbr7DNf51imX1YNFdqX-3v-1cgS4TOXc",{"id":1144,"title":1145,"author":7,"body":1146,"date":137,"description":1341,"extension":139,"meta":1342,"navigation":141,"order":1343,"path":1344,"seo":1345,"stem":1346,"__hash__":1347},"resources\u002Fresources\u002Finternal-business-case-for-devstride.md","The internal business case for DevStride: a one-team pilot your boss will approve",{"type":9,"value":1147,"toc":1334},[1148,1151,1154,1157,1161,1164,1167,1171,1174,1254,1257,1261,1264,1270,1276,1282,1288,1292,1295,1321,1325,1328],[12,1149,1150],{},"You saw the demo. You get it. The problem now is not the product. It is the gap between you liking DevStride and your organization committing to it, and that gap is where most good tools quietly die.",[12,1152,1153],{},"Here is the thing that gap teaches you: the person who loves a tool is rarely the person who signs for it. Your VP does not feel the pain you feel in your day. Procurement does not care that the value map is elegant. What they hear when you say \"new delivery tool\" is risk, migration, and another line item.",[12,1155,1156],{},"So do not ask them to buy a tool. Ask them to run a small, reversible experiment. Below is the case that gets a yes, structured the way a skeptical approver reads it.",[19,1158,1160],{"id":1159},"step-1-propose-a-pilot-not-a-migration","Step 1: propose a pilot, not a migration",[12,1162,1163],{},"The fastest way to lose the room is to frame this as ripping out what you have. You do not have to. Import the Jira board you already run and see it on your own work, alongside Jira, for one team. No rip-and-replace, no committee, no big-bang cutover. If it does not earn its place in a few weeks, you turn it off and you have lost nothing but a little time.",[12,1165,1166],{},"That framing does three things at once. It shrinks the decision, it removes the switching fear, and it puts the burden of proof on the tool instead of on you.",[19,1168,1170],{"id":1169},"step-2-the-one-page-proposal-copy-fill-in-forward","Step 2: the one-page proposal (copy, fill in, forward)",[12,1172,1173],{},"Approvers do not read essays. They read one page that answers four questions: what problem, what we will try, how we will know, what it costs. Copy the block below, fill the brackets, and send it up.",[937,1175,1176,1181,1203,1217,1235,1248],{},[12,1177,1178],{},[33,1179,1180],{},"Pilot proposal: DevStride, one team, four weeks",[12,1182,1183,1186,1187,1191,1192,1195,1196,1199,1200,322],{},[33,1184,1185],{},"The problem we are solving."," ",[1188,1189,1190],"span",{},"Team"," loses time and credibility to ",[1188,1193,1194],{},"pick one or two: missed delivery dates, status that looks green until it slips, no single view a client can trust, planning that scatters as we move faster with AI",". In the last ",[1188,1197,1198],{},"quarter",", this cost us ",[1188,1201,1202],{},"a slipped deadline \u002F a strained client \u002F X hours rebuilding reports",[12,1204,1205,1208,1209,1212,1213,1216],{},[33,1206,1207],{},"What we will try."," Run ",[1188,1210,1211],{},"one team"," on DevStride for four weeks, alongside our current tools. Import our existing ",[1188,1214,1215],{},"Jira"," board so we start from real work, not a blank slate. No other team is affected.",[12,1218,1219,1222,1223,1226,1227,1230,1231,1234],{},[33,1220,1221],{},"How we will know it worked."," We will compare, before and after: ",[1188,1224,1225],{},"percentage of items with a real delivery date",", ",[1188,1228,1229],{},"how quickly a status change shows up across every view",", and ",[1188,1232,1233],{},"time spent building status\u002Freports each week",". We will also ask the team one question at the end: would you go back?",[12,1236,1237,1186,1240,1243,1244,1247],{},[33,1238,1239],{},"What it costs.",[1188,1241,1242],{},"Seats for one team"," for the pilot window, plus roughly ",[1188,1245,1246],{},"a few hours"," of setup. Reversible at any time. Our clients and customers who write in do not consume paid seats.",[12,1249,1250,1253],{},[33,1251,1252],{},"The ask."," Approve a four-week, one-team pilot. Decision to expand or stop at the end, based on the numbers above.",[12,1255,1256],{},"The whole thing fits on one page, deliberately small, because small is what gets approved.",[19,1258,1260],{"id":1259},"step-3-pre-answer-the-four-objections-before-they-are-raised","Step 3: pre-answer the four objections before they are raised",[12,1262,1263],{},"Your approver will not say no. They will raise one of these four, and if you have not already answered it, the pilot stalls. Answer them inside the proposal or in the meeting.",[12,1265,1266,1269],{},[33,1267,1268],{},"\"We are happy with Jira.\""," You are not asking them to be unhappy with Jira. The pilot runs alongside it. The question the pilot answers is narrower and fairer: does one connected system, where the plan and the work share one model, beat a board that shows a card moved but not what it means for the timeline. Let the four weeks answer that, not a slide.",[12,1271,1272,1275],{},[33,1273,1274],{},"\"Migration will break us.\""," There is no migration in a pilot. You import one board to start from real work and keep running your current stack untouched. Nothing is cut over. Nothing has to be moved back if you stop.",[12,1277,1278,1281],{},[33,1279,1280],{},"\"We will just build it ourselves.\""," Sometimes true, so meet it honestly. A team can stand up a board in a sprint. The cost is not the build, it is the maintenance: the rollups, the dependency logic, the reporting, the AI plumbing, kept current for years by engineers you would rather have shipping product. The pilot lets you compare a maintained system against your real backlog before you commit anyone to owning one.",[12,1283,1284,1287],{},[33,1285,1286],{},"\"Is it safe to let AI near our delivery data?\""," This is the right question, and the answer is the reason DevStride exists. AI does the legwork: drafting the plan, sequencing dependencies, writing detail back in. People keep the judgment: work lands in staging, and nothing reaches production without a human sign-off. Every action, human or AI, lands on one shared record with a name on it. You get the speed of AI without handing over the decisions.",[19,1289,1291],{"id":1290},"what-to-actually-measure","What to actually measure",[12,1293,1294],{},"Pick numbers your approver already trusts, and keep the list short:",[27,1296,1297,1303,1309,1315],{},[30,1298,1299,1302],{},[33,1300,1301],{},"Dates you can believe."," The share of in-flight work that carries a real, current delivery date, before and after.",[30,1304,1305,1308],{},[33,1306,1307],{},"One source of truth."," How long a status change takes to show up everywhere else. In a connected system it is immediate; count the minutes you save chasing the current picture.",[30,1310,1311,1314],{},[33,1312,1313],{},"Reporting time."," Hours per week the team spends assembling status and reports, before and after.",[30,1316,1317,1320],{},[33,1318,1319],{},"The honest question."," At the end, ask the team: would you go back? A team that will not go back is the strongest data point you have.",[19,1322,1324],{"id":1323},"the-move","The move",[12,1326,1327],{},"The reason to run this as a pilot is not caution. It is speed. A four-week, one-team, reversible experiment clears the approvals a full purchase cannot, and it puts a real answer in front of your boss instead of your enthusiasm. Bring them the one page above, run it on real work, and let the team's own verdict do the arguing.",[12,1329,1330,1331,1333],{},"When you are ready to scope the pilot, ",[124,1332,548],{"href":235}," and we will set it up around your team, your board, and the numbers you want to prove.",{"title":130,"searchDepth":131,"depth":131,"links":1335},[1336,1337,1338,1339,1340],{"id":1159,"depth":131,"text":1160},{"id":1169,"depth":131,"text":1170},{"id":1259,"depth":131,"text":1260},{"id":1290,"depth":131,"text":1291},{"id":1323,"depth":131,"text":1324},"You are sold. Now you have to get the org sold. Here is the one-page pilot proposal, the numbers to bring, and the four objections to pre-answer, so an individual yes becomes an organizational one.",{},11,"\u002Fresources\u002Finternal-business-case-for-devstride",{"title":1145,"description":1341},"resources\u002Finternal-business-case-for-devstride","fqerAPNAJ3yDzPTgaCR5vYuF43zGcDbJS7RMnqZIVm4",{"id":1349,"title":1350,"author":7,"body":1351,"date":1985,"description":1986,"extension":139,"meta":1987,"navigation":141,"order":1988,"path":1989,"seo":1990,"stem":1991,"__hash__":1992},"resources\u002Fresources\u002Fbegin-learning-case-study.md","Six tools became one. So did the picture.",{"type":9,"value":1352,"toc":1957},[1353,1388,1391,1396,1403,1406,1417,1420,1425,1428,1430,1435,1442,1445,1454,1457,1460,1467,1475,1478,1486,1489,1496,1501,1503,1508,1515,1518,1531,1534,1541,1544,1549,1552,1559,1562,1575,1578,1587,1589,1594,1601,1604,1613,1623,1626,1635,1638,1653,1655,1660,1667,1670,1679,1682,1691,1694,1698,1701,1710,1721,1723,1728,1735,1738,1747,1750,1762,1768,1774,1776,1781,1788,1791,1796,1799,1801,1806,1813,1816,1819,1825,1833,1836,1845,1848,1853,1856,1865,1868,1876,1879,1882,1889,1891,1896,1903,1908,1911,1913,1920,1923,1931,1943,1948],[1354,1355,1356,1373],"table",{},[1357,1358,1359],"thead",{},[1360,1361,1362,1367,1370],"tr",{},[1363,1364,1366],"th",{"align":1365},"left","6 → 1",[1363,1368,1369],{"align":1365},"2 hours",[1363,1371,1372],{"align":1365},"$50K+ \u002F year",[1374,1375,1376],"tbody",{},[1360,1377,1378,1382,1385],{},[1379,1380,1381],"td",{"align":1365},"ClickUp, Monday, Asana, Jira, Pivotal Tracker — and the spreadsheet holding them together",[1379,1383,1384],{"align":1365},"For most people to learn it, with no training",[1379,1386,1387],{"align":1365},"Off the software bill, at a small company",[1389,1390],"hr",{},[12,1392,1393],{},[33,1394,1395],{},"THE COMPANY",[19,1397,1399,1400],{"id":1398},"four-brands-one-company-no-project-managers","Four brands, one company. ",[459,1401,1402],{},"No project managers.",[12,1404,1405],{},"BEGiN Learning is an early-childhood education company built from four separate brands brought under one umbrella — digital apps and physical products for kids aged two to ten, with a hyper-focus on two to five.",[937,1407,1408,1411],{},[12,1409,1410],{},"\"That's where learning starts, and where kids typically need the most help, because they're just getting into school, or getting ready for school, and kids can be in wildly varying different spots.\"",[12,1412,1413,1416],{},[33,1414,1415],{},"Keith Brickley",", Senior Program Manager, BEGiN Learning",[12,1418,1419],{},"Keith runs operations and delivery practice across the organization. Notably, BEGiN doesn't really staff project managers.",[937,1421,1422],{},[12,1423,1424],{},"\"We have people here who have been project managers, but that's not their official title — they have that mindset. I work across the organization with all the teams, making sure they're spending as little time as possible doing reporting and task management, and the most amount of time doing work. Creating, building, fixing.\"",[12,1426,1427],{},"That constraint matters. Every hour BEGiN's teams spent maintaining the picture of the work was an hour not spent making the product.",[1389,1429],{},[12,1431,1432],{},[33,1433,1434],{},"THE PROBLEM",[19,1436,1438,1439],{"id":1437},"six-tools-no-way-to-see-across-them","Six tools. ",[459,1440,1441],{},"No way to see across them.",[12,1443,1444],{},"When four companies become one company, the org chart merges long before the tooling does.",[937,1446,1447],{},[12,1448,1449,1450,1453],{},"\"We had four companies that came together that all used different tools. ClickUp, Monday, Asana, Jira, Pivotal Tracker. There were at least five or six different tools teams used to track work that were now all under one roof. ",[33,1451,1452],{},"And we had to go to one tool — to make it work for everyone, and for leadership to be able to track and see progress.","\"",[12,1455,1456],{},"That second half is the whole brief. Consolidation wasn't the goal on its own; it was the only route to a single view of what was happening across a company that had just quadrupled its number of teams.",[12,1458,1459],{},"The tools themselves were the barrier. The sheer number, as Keith puts it, \"alone creates silos\" and \"creates barriers for both information and collaboration.\"",[12,1461,1462,1463,1466],{},"And BEGiN is unusually cross-functional, so the silos bit constantly. A single piece of web work might need data, creative and marketing alongside it — each in a different system. \"It was, ",[459,1464,1465],{},"oh, let me make a ticket in your tool and you go make a ticket in my tool,","\" Keith says. \"They don't talk to each other.\"",[1468,1469,1471,1472],"h3",{"id":1470},"the-sixth-tool-was-a-spreadsheet-and-it-was-wrong-on-arrival","The sixth tool was a spreadsheet. ",[459,1473,1474],{},"And it was wrong on arrival.",[12,1476,1477],{},"Because none of the five spanned the teams, cross-functional status lived where it always lives: in a sheet somebody had to keep alive by hand. That spreadsheet was, in every practical sense, the sixth tool — the only one everybody used, and the only one nobody could trust. Keith's internal pitch for change came down to a single sentence.",[937,1479,1480],{},[12,1481,1453,1482,1485],{},[33,1483,1484],{},"The moment you put it into a sheet, it's out of date."," The moment you get an export from any tool — because you have to combine data into one spot — it's literally out of date after you hit export. If someone goes in and changes one status, you don't have that status update. So you're always behind the ball.\"",[12,1487,1488],{},"He'd built exactly that artifact himself: a sheet with a section per department, everyone filling in their part, everyone then going back to update their own tool and never the sheet, and the whole group meeting around a document that had been wrong since the moment it was created.",[12,1490,1491,1492,1495],{},"The licensing math made it worse. The stale sheet wasn't just the ",[459,1493,1494],{},"best"," shared view — it was the only one most people could open.",[937,1497,1498],{},[12,1499,1500],{},"\"Not everyone has access to every tool, and not everyone can see, because you're not paying for licenses across the whole company. That's just super expensive. So I bring up the sheet — but it's always out of date.\"",[1389,1502],{},[12,1504,1505],{},[33,1506,1507],{},"THE OBJECTION",[19,1509,1511,1512],{"id":1510},"any-one-of-them-would-have-worked-for-half-the-company","Any one of them would have worked. ",[459,1513,1514],{},"For half the company.",[12,1516,1517],{},"The obvious move was to pick a winner from the tools they already had. Keith could see why that wouldn't hold.",[937,1519,1520],{},[12,1521,1522,1523,1526,1527,1530],{},"\"You could have gone to any one of those tools. But when you look at those tools in a vacuum, they serve only a portion of the users. If you say, hey, let's all move to Asana — the marketing team, the sales team, they love that. Engineers hate it. If you say let's move to Jira, engineers are like, ",[459,1524,1525],{},"yep, that's my world",". And the marketing team's like, ",[459,1528,1529],{},"I don't ever want to touch that thing",".\"",[12,1532,1533],{},"Every option on the table won one half of the company by losing the other half. And Keith had watched what happens when a team tries to escape that trade by migrating from one heavyweight tool to another.",[937,1535,1536],{},[12,1537,1538],{},[33,1539,1540],{},"\"You're going from one massive tool with lots of stuff to another massive tool with lots of stuff. You're not making it easier. You're just replacing the chaos with a different form of chaos.\"",[12,1542,1543],{},"What made a single system survivable was that it didn't demand a single way of working. Some BEGiN teams run Kanban. Some run sprints. Both are true at once, and neither taxes the other.",[937,1545,1546],{},[12,1547,1548],{},"\"One team's desire to work that way does not impact or impede another team's desire to work in a different way. But you can have it all level up to the same single point. And that's what matters to everyone else. The teams get what they want, PMs and leadership get everything they want. It's almost a meeting-in-the-middle type thing.\"",[12,1550,1551],{},"Keith's framing of where a tool should bend and where it shouldn't:",[937,1553,1554],{},[12,1555,1556],{},[33,1557,1558],{},"\"It's flexibility right where you want it. And it's inflexible in all the places where it probably shouldn't be flexible.\"",[12,1560,1561],{},"He's equally clear about the opposite failure — the tool that lets you customize everything until nobody can untangle it.",[937,1563,1564],{},[12,1565,1566,1567,1570,1571,1574],{},"\"You could make Jira super customized, and it becomes very unwieldy for anyone to break apart. A new person comes on board and you're like, ",[459,1568,1569],{},"yeah, we have this, but you need to know five different teams use it five different ways."," In DevStride there aren't a thousand features, there isn't ",[459,1572,1573],{},"I can flip every one of these switches and make this super customizable"," — because once you go down that road, you can't come back.\"",[12,1576,1577],{},"That restraint pays off later, too. BEGiN has reworked its workstream structure more than once as company focus shifted. In most tools that's a rebuild; here it's a drag, and it doesn't disturb anyone below it.",[937,1579,1580],{},[12,1581,1582,1583,1586],{},"\"It changes nothing about your boards, changes nothing about your statuses. Everything you do will still remain. They would literally not notice the difference unless they were really keen on a breadcrumb name change. That's always a wipe-off-the-brow moment for people — ",[459,1584,1585],{},"okay, that's not as big of a deal as I thought."," Because other tools make it a big deal. They have trauma from other tools.\"",[1389,1588],{},[12,1590,1591],{},[33,1592,1593],{},"THE SWITCH",[19,1595,1597,1598],{"id":1596},"an-export-and-a-mapping-under-five-hours","An export and a mapping. ",[459,1599,1600],{},"Under five hours.",[12,1602,1603],{},"BEGiN moved out of Jira the way most teams hope a migration will go and rarely find it does.",[937,1605,1606],{},[12,1607,1608,1609,1612],{},"\"We did an export from tool X — Jira — into a CSV file, and just mapped it to fields that already existed. Most of them already did. If we had to create a couple new ones, that was easy too. And then, boom, import it all. We could literally dump it where and how we wanted it. ",[33,1610,1611],{},"I want to say hours — less than five."," It was not a heavy lift at all.\"",[12,1614,1615,1616,1619,1620,1622],{},"The mapping carried structure across, not just rows: work labelled ",[459,1617,1618],{},"bug"," in Jira landed in a workstream called ",[459,1621,1618],{},", and so on down the list. Teams arrived already organized.",[12,1624,1625],{},"Onboarding was a short demo and a couple of pages of screenshots Keith wrote up so people had something to refer back to. What came back surprised him.",[937,1627,1628],{},[12,1629,1630,1631,1634],{},"\"The one thing I heard more than any other thing was that once they got in there themselves, ",[33,1632,1633],{},"within two hours — if not less — they knew how to do most everything."," They were very surprised at how easy it was to pick up. It's almost like we built it up to be more scary than it actually is.\"",[12,1636,1637],{},"The clearest test was someone with no stake in defending the choice. BEGiN's VP of Operations gave herself an hour and a list of questions.",[937,1639,1640],{},[12,1641,1642,1643,1646,1647,1652],{},"\"She said, ",[459,1644,1645],{},"I'm just going to jump in, and I'll get back to you in an hour or two with five questions."," After an hour she sent me a message. She said, ",[459,1648,1649],{},[33,1650,1651],{},"I love this. This is great."," She didn't have any questions. She'd already made stories.\"",[1389,1654],{},[12,1656,1657],{},[33,1658,1659],{},"WHAT CHANGED",[19,1661,1663,1664],{"id":1662},"every-team-kept-its-board-leadership-got-the-picture","Every team kept its board. ",[459,1665,1666],{},"Leadership got the picture.",[12,1668,1669],{},"Asked for the single biggest benefit — setting the cost savings aside entirely — Keith went straight to the view.",[937,1671,1672],{},[12,1673,1674,1675,1678],{},"\"The biggest one, even taking out being cost-effective, is being able to work cross-functionally. Different teams that literally worked different ways in different tools still work in different ways in this tool — ",[33,1676,1677],{},"but can work together in a way where we can all see the status, the progress, the Gantt charts, the calendar"," of the things being worked on.\"",[12,1680,1681],{},"The mechanism is ordinary and it is the whole point: separate items, on separate boards, with separate statuses, all rolling up to the same epic.",[937,1683,1684],{},[12,1685,1686,1687,1690],{},"\"The web team goes and makes their tickets, does what they need to do. But they might also need data help for insights on who's clicking around the web page. They might need marketing help. So we can have separate items, but ",[33,1688,1689],{},"they all lead to the same epic"," — and people can put them on their own boards. The web team has all these statuses, the creative team puts it on their board and has all these statuses. It doesn't matter. They're not in conflict, because they're doing their own work.\"",[12,1692,1693],{},"So the working teams look down at their own board, and Keith looks across at the epic — one place where every contributing team's work, from six formerly separate systems, sits together with its dependencies. \"I can easily go to an epic and that will have everything underneath that anyone could see,\" he says. \"You can manage it in your own way, but see it all tied together.\"",[1468,1695,1697],{"id":1696},"status-meetings-became-working-sessions","Status meetings became working sessions",[12,1699,1700],{},"With one live system underneath, the reconciliation ritual disappeared — and the meeting changed character.",[937,1702,1703],{},[12,1704,1705,1706,1709],{},"\"I do this every week with our creative team. We're on a call and it's, ",[459,1707,1708],{},"oh yeah, that one's actually done"," — and I just click done on the screen, and it's done. Nothing is out of date. We did it in real time. No exporting, no other spot to go duplicate the effort.\"",[12,1711,1712,1713,1716,1717,1720],{},"It also surfaced problems the spreadsheet had been hiding. Once nobody is merging exports by hand, the question stops being ",[459,1714,1715],{},"whose copy is right"," and becomes ",[459,1718,1719],{},"why isn't this being kept current"," — a question you can actually act on.",[1389,1722],{},[12,1724,1725],{},[33,1726,1727],{},"THE PROOF",[19,1729,1731,1732],{"id":1730},"the-plan-got-built-in-the-room-not-written-up-afterwards","The plan got built in the room. ",[459,1733,1734],{},"Not written up afterwards.",[12,1736,1737],{},"BEGiN began planning the launch of a new physical product under its Little Passports brand. Keith, the CMO, and the physical-product team went into a room and built the go-to-market plan directly in DevStride rather than writing it up afterwards.",[937,1739,1740],{},[12,1741,1742,1743,1746],{},"\"Just having everyone in the same room looking at one tool, we built out what we need to do to go to market with this. And then having it built out all along the way, we'd refer back to it — ",[459,1744,1745],{},"okay, here are the things we need to talk about."," It kept us very on track and in line. It was a central spot for different folks from different teams who could all view the same project plan.\"",[12,1748,1749],{},"The same pattern held for a second, very different piece of work — sunsetting an older offering — where the plan was assembled live, on screen, as the conversation happened.",[937,1751,1752],{},[12,1753,1754,1755,1758,1759,1453],{},"\"People were like, ",[459,1756,1757],{},"oh, we need to do this"," — and someone can just make a new item as a placeholder. Then you could see all the things we need to do, start throwing out dates, use the Gantt chart to move some stuff around. ",[33,1760,1761],{},"Being able to do that in one spot progressed the conversation dramatically faster.",[12,1763,1764,1765,1453],{},"The shift is small to state and large to live in: meetings stopped ending with a list of things to go write down. Before, Keith says, it was \"a lot of hours — which costs a lot of money, people time and dollars — spent just trying to come together on ",[459,1766,1767],{},"what's the current status?",[12,1769,1770,1773],{},[33,1771,1772],{},"The project delivered on time."," A plan built in the room, hitting the date the room set.",[1389,1775],{},[12,1777,1778],{},[33,1779,1780],{},"THE LINE ITEM",[19,1782,1784,1785],{"id":1783},"off-the-software-bill-more-than-50000-a-year","Off the software bill. ",[459,1786,1787],{},"More than $50,000 a year.",[12,1789,1790],{},"With the legacy tools shut down, the software spend went with them.",[937,1792,1793],{},[12,1794,1795],{},"\"We were able to shut those all down and save over $50,000 a year. And we're a small company. For larger companies this would scale up significantly. It was a big chunk of money, just saved on tools.\"",[12,1797,1798],{},"That number is the floor, not the ceiling. It counts licenses. It doesn't count the hours BEGiN's teams were spending exporting, pasting, formatting and reconciling a picture of the work that was wrong on arrival.",[1389,1800],{},[12,1802,1803],{},[33,1804,1805],{},"KEITH'S ADVICE",[19,1807,1809,1810],{"id":1808},"the-software-took-an-afternoon-the-agreement-took-longer","The software took an afternoon. ",[459,1811,1812],{},"The agreement took longer.",[12,1814,1815],{},"Worth being precise about what took time at BEGiN, because it's easy to read the wrong lesson into it.",[12,1817,1818],{},"The technical work was trivial. The export, the field mapping and the import ran in under five hours. Teams were productive inside two. BEGiN's VP of Operations — not an engineer — sat down expecting to surface a list of questions and had built stories inside an hour instead.",[12,1820,1821,1824],{},[33,1822,1823],{},"What took a while was getting a company that had just merged four cultures to agree to move at all."," That's a change-management problem, and it would have existed no matter which tool BEGiN picked.",[937,1826,1827],{},[12,1828,1829,1830,1453],{},"\"It took a while for me to get DevStride adopted here. It was a long journey, which I think most people usually give up on. There was a time where I was like, ",[459,1831,1832],{},"okay, this just seems like it's never going to happen.",[12,1834,1835],{},"The resistance wasn't about capability. It was about memory. Everyone in the room had lived through a bad migration before, and they were pricing that experience into this one.",[937,1837,1838],{},[12,1839,1840,1841,1844],{},"\"There's a bit of ",[459,1842,1843],{},"too good to be true."," People are scared of change, especially at a company. If they moved from Monday to Jira, it's just a pain — you're going from one massive tool with lots of stuff to another massive tool with lots of stuff. So there's a mental barrier there. It's tough to switch, I don't want to think about it.\"",[12,1846,1847],{},"What broke it open wasn't a better argument. It was showing people their own work, already moved.",[937,1849,1850],{},[12,1851,1852],{},"\"It's not only persistence. It's take a chance on it yourself. Get the tool for yourself and run with an example. Make some examples of what it would look like with your company. Because the proof is in the pudding.\"",[12,1854,1855],{},"So Keith — a program manager, not a developer — did a sample import of BEGiN's real Jira data, with help from the DevStride team, and put the two side by side.",[937,1857,1858],{},[12,1859,1860,1861,1864],{},"\"It's, ",[459,1862,1863],{},"here — here's literally your work from Jira. This is your today in Jira. This is my today in DevStride. And I can drag these things around. I can do this. I can create a marketing thing."," That took, I'd say, a day. Not even a full day — I did it in the time between other things.\"",[12,1866,1867],{},"The demo did what argument couldn't, because it removed the part people were afraid of.",[937,1869,1870],{},[12,1871,1872,1873,1453],{},"\"The farther back you are from showing concrete examples to your colleagues, the more they have to imagine what it could be. And when people imagine, they'll think the worst — because that's how they've always been burned by something. ",[33,1874,1875],{},"Leave less to the imagination, and show it.",[12,1877,1878],{},"Once colleagues could see it rather than picture it, the objections went with the picture: \"Once I show folks, all of a sudden those walls start to come down.\"",[12,1880,1881],{},"Asked what he'd tell someone sitting where he was sitting, he didn't need long.",[937,1883,1884],{},[12,1885,1886],{},[33,1887,1888],{},"\"It's not as hard as you think.\"",[1389,1890],{},[12,1892,1893],{},[33,1894,1895],{},"WHERE BEGiN IS NOW",[19,1897,1899,1900],{"id":1898},"consolidate-and-simplify-then-grow-together","Consolidate and simplify. ",[459,1901,1902],{},"Then grow together.",[937,1904,1905],{},[12,1906,1907],{},"\"We consolidated and simplified — and then we took the simplified consolidation and grew that into what we needed it to be, and what we were missing before. It's almost like you go backwards, but I don't mean that in a bad way. Let's all start at the same spot, and now let's all grow together. The fact that you can be in one spot and start on a solid foundation — the rest is up to the folks you have at the company. That's a people thing, not a tool thing.\"",[12,1909,1910],{},"Four brands. Six tools. One system, and one picture of the work.",[1389,1912],{},[1468,1914,1916,1917],{"id":1915},"six-tools-became-one-yours-can-too","Six tools became one. ",[459,1918,1919],{},"Yours can too.",[12,1921,1922],{},"Export from the trackers you run today, import into DevStride, and manage every team's work in one place. Keith's whole migration took under five hours — and no team had to change how it works.",[12,1924,1925],{},[33,1926,1927],{},[124,1928,1930],{"href":1929},"\u002Fcontact","Get a guided walkthrough →",[12,1932,1933,1934,1937,1938,1942],{},"Or talk to a person: ",[33,1935,1936],{},"Laura Haner",", Director of Strategic Partnerships · ",[124,1939,1941],{"href":1940},"mailto:laura@devstride.com","laura@devstride.com"," · +609-865-7416",[12,1944,1945],{},[459,1946,1947],{},"Every plan includes every capability. No tiers, no surprises.",[12,1949,1950],{},[124,1951,1956],{"href":1952,"rel":1953,"target":1955},"\u002Fcase-studies\u002Fbegin-learning-case-study.pdf",[1954],"noopener","_blank","Download the case study (PDF) ↗",{"title":130,"searchDepth":131,"depth":131,"links":1958},[1959,1961,1966,1968,1970,1974,1976,1978,1980],{"id":1398,"depth":131,"text":1960},"Four brands, one company. No project managers.",{"id":1437,"depth":131,"text":1962,"children":1963},"Six tools. No way to see across them.",[1964],{"id":1470,"depth":332,"text":1965},"The sixth tool was a spreadsheet. And it was wrong on arrival.",{"id":1510,"depth":131,"text":1967},"Any one of them would have worked. For half the company.",{"id":1596,"depth":131,"text":1969},"An export and a mapping. Under five hours.",{"id":1662,"depth":131,"text":1971,"children":1972},"Every team kept its board. Leadership got the picture.",[1973],{"id":1696,"depth":332,"text":1697},{"id":1730,"depth":131,"text":1975},"The plan got built in the room. Not written up afterwards.",{"id":1783,"depth":131,"text":1977},"Off the software bill. More than $50,000 a year.",{"id":1808,"depth":131,"text":1979},"The software took an afternoon. The agreement took longer.",{"id":1898,"depth":131,"text":1981,"children":1982},"Consolidate and simplify. Then grow together.",[1983],{"id":1915,"depth":332,"text":1984},"Six tools became one. Yours can too.","2026-07-30","How BEGiN Learning replaced five trackers and the spreadsheet holding them together with one system — a live view across every project, and $50K+ a year saved in licenses.",{},50,"\u002Fresources\u002Fbegin-learning-case-study",{"title":1350,"description":1986},"resources\u002Fbegin-learning-case-study","qNNBBye6A6ie3e6QCdMgWip0lWOWJ5WSyirki7iJKp8",{"id":1994,"title":1995,"author":7,"body":1996,"date":1985,"description":2118,"extension":139,"meta":2119,"navigation":141,"order":2120,"path":2121,"seo":2122,"stem":2123,"__hash__":2124},"resources\u002Fresources\u002Fintraprise-case-study.md","Effectiveness is the new efficiency",{"type":9,"value":1997,"toc":2108},[1998,2026,2028,2032,2035,2042,2045,2053,2060,2063,2066,2070,2073,2087,2094,2097,2102],[1354,1999,2000,2013],{},[1357,2001,2002],{},[1360,2003,2004,2007,2010],{},[1363,2005,2006],{"align":1365},"20–30 concurrent projects",[1363,2008,2009],{"align":1365},"One operating system",[1363,2011,2012],{"align":1365},"Delivered under budget",[1374,2014,2015],{},[1360,2016,2017,2020,2023],{},[1379,2018,2019],{"align":1365},"Coordinated in a single view",[1379,2021,2022],{"align":1365},"Proposals, change orders, PTO, capacity planning",[1379,2024,2025],{"align":1365},"With predictable, automated cadence",[1389,2027],{},[19,2029,2031],{"id":2030},"about-intraprise","About Intraprise",[12,2033,2034],{},"Intraprise TechKnowlogies is a non-traditional CPA firm focused on business transformation and holistic risk management. Running 20–30 consulting projects at once, the firm needed a way to coordinate complex work across multiple methodologies and clients — without losing visibility or control.",[19,2036,2038,2039],{"id":2037},"the-challenge-rigid-or-too-technical","The challenge: ",[459,2040,2041],{},"rigid, or too technical",[12,2043,2044],{},"Traditional project tools forced a choice: waterfall systems were too rigid, while agile platforms were too technical for consulting workflows. Managing status through email and spreadsheets led to fragmented visibility, inconsistent cadence, and excessive overhead.",[937,2046,2047,2050],{},[12,2048,2049],{},"We weren't looking for a faster way to manage projects. We were looking for a smarter way to deliver results.",[12,2051,2052],{},"— Donny Shimamoto, Managing Director",[19,2054,2056,2057],{"id":2055},"the-solution-one-system","The solution: ",[459,2058,2059],{},"one system",[12,2061,2062],{},"The turning point came with DevStride's Item Hierarchies, which established clear relationships between projects, deliverables, and dependencies — eliminating the need for manual workarounds.",[12,2064,2065],{},"Using workstreams, automations, and forms, Intraprise unified proposals, change orders, PTO, and capacity planning into one system, creating consistent accountability and predictability.",[19,2067,2069],{"id":2068},"the-results","The results",[12,2071,2072],{},"DevStride helps the firm anticipate issues, make better decisions, and deliver under budget. With DevStride, Intraprise has:",[27,2074,2075,2078,2081,2084],{},[30,2076,2077],{},"Visibility across 20–30 concurrent projects",[30,2079,2080],{},"Reduced PM workload and email traffic",[30,2082,2083],{},"Predictable cadence through automation",[30,2085,2086],{},"A consolidated system replacing legacy tools",[19,2088,2090,2091],{"id":2089},"the-takeaway-effectiveness-over-efficiency","The takeaway: ",[459,2092,2093],{},"effectiveness over efficiency",[12,2095,2096],{},"DevStride gives Intraprise the infrastructure to manage hybrid methodologies at scale — combining the rigor of PMBOK with the agility of modern workflows. The result: fewer silos, faster insight, and a single operating system for transformation.",[12,2098,2099],{},[33,2100,2101],{},"Effectiveness is the new efficiency — and DevStride makes it measurable.",[12,2103,2104],{},[124,2105,1956],{"href":2106,"rel":2107,"target":1955},"\u002Fcase-studies\u002Fintraprise-case-study.pdf",[1954],{"title":130,"searchDepth":131,"depth":131,"links":2109},[2110,2111,2113,2115,2116],{"id":2030,"depth":131,"text":2031},{"id":2037,"depth":131,"text":2112},"The challenge: rigid, or too technical",{"id":2055,"depth":131,"text":2114},"The solution: one system",{"id":2068,"depth":131,"text":2069},{"id":2089,"depth":131,"text":2117},"The takeaway: effectiveness over efficiency","How Intraprise TechKnowlogies built a hybrid work-management system on DevStride — visibility and predictable cadence across 20–30 concurrent client projects, without losing control.",{},51,"\u002Fresources\u002Fintraprise-case-study",{"title":1995,"description":2118},"resources\u002Fintraprise-case-study","tvvmj4-od7yJ28dWEz5nFMeNA0B48EHRr5wp6xBdr_Y",{"id":2126,"title":2127,"author":7,"body":2128,"date":1985,"description":2330,"extension":139,"meta":2331,"navigation":141,"order":2332,"path":2333,"seo":2334,"stem":2335,"__hash__":2336},"resources\u002Fresources\u002Ftenger-ways-case-study.md","The gold standard for continuous service delivery",{"type":9,"value":2129,"toc":2318},[2130,2158,2160,2167,2173,2179,2185,2191,2194,2214,2221,2224,2244,2246,2249,2255,2261,2267,2271,2274,2294,2301,2304,2312],[1354,2131,2132,2145],{},[1357,2133,2134],{},[1360,2135,2136,2139,2142],{},[1363,2137,2138],{"align":1365},"18 months → 2 weeks",[1363,2140,2141],{"align":1365},"160 hours → a fraction",[1363,2143,2144],{"align":1365},"100% work-to-value traceability",[1374,2146,2147],{},[1360,2148,2149,2152,2155],{},[1379,2150,2151],{"align":1365},"Arden's file-upload fix, mapped and resolved",[1379,2153,2154],{"align":1365},"Effort measured as outcomes, not hours",[1379,2156,2157],{"align":1365},"Golden Thread, fully operationalized",[1389,2159],{},[19,2161,2163,2164],{"id":2162},"building-a-modern-operating-model-for-continuous-value-delivery","Building a modern operating model for ",[459,2165,2166],{},"continuous value delivery",[12,2168,2169,2172],{},[33,2170,2171],{},"The client."," Tenger Ways is a fast-growing technology consulting firm helping mid-market organizations move beyond project management to continuous value delivery.",[12,2174,2175,2178],{},[33,2176,2177],{},"The need."," To support that philosophy, the team needed a platform flexible enough to manage complex, multi-client work yet structured enough to tie every task to measurable outcomes.",[12,2180,2181,2184],{},[33,2182,2183],{},"The breakthrough."," After finding traditional tools too rigid, Tenger Ways chose DevStride to power its proprietary Digital Factory and Golden Thread frameworks — serving as the backbone of its value-delivery model.",[19,2186,2038,2188],{"id":2187},"the-challenge-trapped-in-complexity",[459,2189,2190],{},"trapped in complexity",[12,2192,2193],{},"Most project management tools were built for the industrial age. No existing tool could support Tenger Ways' modern delivery frameworks or provide the transparency clients expected.",[27,2195,2196,2202,2208],{},[30,2197,2198,2201],{},[33,2199,2200],{},"Rigid frameworks"," — Traditional project tools were built for fixed processes, not adaptive frameworks.",[30,2203,2204,2207],{},[33,2205,2206],{},"Fragmented ecosystem"," — Multiple disconnected systems created silos, duplicate work, and lost visibility.",[30,2209,2210,2213],{},[33,2211,2212],{},"Limited traceability"," — Work couldn't be consistently tied to client goals or measurable outcomes.",[19,2215,2217,2218],{"id":2216},"the-solution-turning-complexity-into-clarity","The solution: turning complexity into ",[459,2219,2220],{},"clarity",[12,2222,2223],{},"Tenger Ways adopted DevStride as its single operational backbone — a system flexible enough to mirror each client's workflow while enforcing a consistent, outcome-driven model across the firm.",[27,2225,2226,2232,2238],{},[30,2227,2228,2231],{},[33,2229,2230],{},"Flexible framework"," — DevStride adapts seamlessly to Tenger Ways' proprietary Digital Factory and Golden Thread frameworks.",[30,2233,2234,2237],{},[33,2235,2236],{},"Unified solution"," — A single platform replaces tool sprawl, keeping every client engagement connected.",[30,2239,2240,2243],{},[33,2241,2242],{},"Unparalleled traceability"," — Every task links to business value, giving clients real-time visibility and measurable impact.",[19,2245,2069],{"id":2068},[12,2247,2248],{},"By running all client work through DevStride, Tenger Ways shifted from measuring outputs to measuring outcomes. Every work item is now linked to business value, fueling faster, more strategic decision-making and stronger client trust.",[12,2250,2251,2254],{},[33,2252,2253],{},"Arden Insurance turnaround."," When Arden Insurance struggled with a file-upload failure unresolved for 18 months, Tenger Ways used DevStride to map and prioritize the fix — resolving it in just two weeks and sparking a partnership that fueled growth and led to a private-equity acquisition.",[12,2256,2257,2260],{},[33,2258,2259],{},"100% work-to-value traceability."," Golden Thread is now fully operationalized in DevStride. Every task traces to executive vision and business objectives, ensuring resources align to measurable outcomes.",[12,2262,2263,2266],{},[33,2264,2265],{},"Measured business impact."," From 160 hours to a fraction. Tenger Ways measures outcomes, not effort — driving faster, smarter, more collaborative results with DevStride.",[19,2268,2270],{"id":2269},"why-devstride","Why DevStride",[12,2272,2273],{},"DevStride is not another project management tool. It provides the infrastructure and workflows for measurable impact:",[27,2275,2276,2279,2282,2285,2288,2291],{},[30,2277,2278],{},"Flexibility to run any framework",[30,2280,2281],{},"Full visibility without leaving systems or tools",[30,2283,2284],{},"API-first and integration-friendly",[30,2286,2287],{},"Scalable from single team to enterprise portfolio",[30,2289,2290],{},"Connects every task to measurable business value",[30,2292,2293],{},"Engineered for performance and adoption",[19,2295,2297,2298],{"id":2296},"the-shift-from-projects-to-continuous-value","The shift from projects to ",[459,2299,2300],{},"continuous value",[12,2302,2303],{},"Most organizations still operate with an \"industrial-age\" mindset: complete a project, move on, repeat. In the AI era, that approach is obsolete. Modern practices demand continuous value delivery — measurable impact every day. DevStride provides the flexibility and visibility to help clients make that shift, meeting them where they are while guiding them toward a more effective operating model.",[937,2305,2306,2309],{},[12,2307,2308],{},"We can adapt to any client, any project, and always prove the value we deliver with DevStride.",[12,2310,2311],{},"— Daniel Keith, Owner, Tenger Ways",[12,2313,2314],{},[124,2315,1956],{"href":2316,"rel":2317,"target":1955},"\u002Fcase-studies\u002Ftw-continuous-service-delivery.pdf",[1954],{"title":130,"searchDepth":131,"depth":131,"links":2319},[2320,2322,2324,2326,2327,2328],{"id":2162,"depth":131,"text":2321},"Building a modern operating model for continuous value delivery",{"id":2187,"depth":131,"text":2323},"The challenge: trapped in complexity",{"id":2216,"depth":131,"text":2325},"The solution: turning complexity into clarity",{"id":2068,"depth":131,"text":2069},{"id":2269,"depth":131,"text":2270},{"id":2296,"depth":131,"text":2329},"The shift from projects to continuous value","How Tenger Ways runs every client engagement on DevStride — powering its Digital Factory and Golden Thread frameworks, and tying every task to measurable business value.",{},52,"\u002Fresources\u002Ftenger-ways-case-study",{"title":2127,"description":2330},"resources\u002Ftenger-ways-case-study","-lchKxORZygU3mQit-l373yr6zmoAxElQprTbawYmqQ",1785519825529]