When we started applying Agile to AI work, I assumed our existing playbook\u2014thin slices, short sprints, frequent demos\u2014would carry over. It didn\u2019t. We shipped increments, yes. But the increments often looked productive while learning the wrong lessons. In my world (Salesforce ecosystems in healthcare and banking), that gap showed up as models that \u201cworked\u201d in sprint reviews yet created downstream friction, compliance churn, or quietly optimized for the wrong behavior.<\/p>\n\n\n\n
Over several programs, though, I learned that Agile does fit AI if you redefine two fundamentals up front:<\/p>\n\n\n\n
Below, I\u2019ll share the patterns that made the difference, the moments that forced me to change my mind, and a practical backbone you can take into your next AI iteration.<\/p>\n\n\n\n
The moment my thinking changed came during a sprint demo where our AI assistance reduced Salesforce Opportunity creation time dramatically in a banking context. On paper, this was a win. But a week later, compliance flagged subtle edge cases the model had learned from historical shortcuts in the CRM. We had optimized speed at the cost of governance. Sprint \u201cdone\u201d wasn\u2019t business \u201cdone.\u201d<\/p>\n\n\n\n
What finally worked: we added Outcome Evidence to our Definition of Done (DoD):<\/p>\n\n\n\n
This didn\u2019t slow us down; it prevented expensive rework. It also changed our sprint reviews: instead of demoing \u201clook what the model can do,\u201d we demoed \u201clook what we learned and how we know we didn\u2019t learn the wrong thing.\u201d<\/p>\n\n\n\n
In healthcare integrations (Epic\/Genesys \u2194 Salesforce Health Cloud), we learned that the people who review model output\u2014care coordinators, operations leads, security, compliance\u2014are as critical as end users. If they lack visibility or a lightweight override path, your team will quietly harden manual workarounds outside the system. That\u2019s how \u201cshadow process\u201d is born.<\/p>\n\n\n\n
Our rule of thumb now:<\/strong><\/p>\n\n\n\n When we took this view, adoption improved, and the model learned faster because feedback lived where the work is<\/em>, not in a separate spreadsheet.<\/p>\n\n\n\n On a Salesforce program, our first \u201cthin slice\u201d was UI\u2011centric: autocomplete fields, smart defaults, then later a recommendation panel. Velocity looked great; learning did not. The model wasn\u2019t exposed to the decision pressure we actually cared about (e.g., which lead deserves attention now; which case needs escalation).<\/p>\n\n\n\n We changed the slice to \u201cone decision, end\u2011to\u2011end\u201d:<\/p>\n\n\n\n That slice exposed the real trade\u2011offs (precision vs. recall, throughput vs. fairness) far earlier and gave us the right conversations in sprint reviews.<\/p>\n\n\n\n In classic Agile, \u201cas a user I want\u2026\u201d stories can blur model training, data remediation, and governance hardening into one mega\u2011ticket. We split the work into three tracks, each with its own cadences, but we demo them together:<\/p>\n\n\n\n One sprint review equals one narrative: what we changed in the model, what data moved because of it, and how controls evolved. Executives track value; auditors see traceability; teams see cause and effect.<\/p>\n\n\n\n In one hospital rollout, we had brilliant feedback buried in SharePoint and email threads. We moved it into the systems where work happened: Salesforce comments, case objects, and lightweight review forms. We also surfaced \u201cTop 5 feedback themes\u201d on an SPM dashboard that leadership already reviewed weekly.<\/p>\n\n\n\n That closed the loop. Instead of asking clinicians and support teams to go somewhere else<\/em> to be heard, we met them in the flow of work. Model quality improved because the feedback finally did<\/em>.<\/p>\n\n\n\n A counterintuitive lesson: there are moments where the most Agile move is not to build a model. If the data generating process is unstable (e.g., new workflow, new form fields, evolving taxonomy), first stabilize the process with automation or explicit rules. Then invite an AI challenger. Otherwise, you\u2019ll teach your model yesterday\u2019s chaos and call it learning.<\/p>\n\n\n\n We now use a simple guardrail: If we cannot articulate a stationary slice of the process for 4\u20136 weeks, we don\u2019t train, we instrument. That instrumentation later becomes gold for training.<\/p>\n\n\n\n A lightweight backbone you can copy<\/strong><\/p>\n\n\n\n Working on AI inside fast\u2011moving, highly regulated environments hasn\u2019t made me more certain about the \u201cright way\u201d to do things. If anything, it\u2019s humbled me. I\u2019ve had late\u2011night standups where the model drifted without warning, sprint reviews where a small insight changed the entire roadmap, and moments where I caught myself asking, \u201cAre we even solving the right problem?\u201d<\/em><\/p>\n\n\n\n What I\u2019ve learned, often the hard way, is that the teams that thrive treat learning as the real product. Controls become features, and decisions become tiny, testable slices of truth. When we redefine \u201cdone\u201d and \u201cuser\u201d through that lens, the model gets better one sprint at a time, and the organization starts trusting it enough to scale.<\/p>\n\n\n\n So, if you\u2019ve ever paused mid\u2011project and questioned, \u201cIs this still working?<\/em>\u201d while building AI in a multi\u2011system, highly regulated world, you\u2019re not alone. That question is usually where the real conversation begins. I\u2019d love to hear how you\u2019re navigating it, too.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Why classic Agile breaks down with AI and what actually works instead, from redefining \u201cdone\u201d and \u201cuser\u201d to slicing by decisions, evidence, and controls in regulated environments.<\/p>\n","protected":false},"author":8142433,"featured_media":8103891,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_tec_requires_first_save":true,"_EventAllDay":false,"_EventTimezone":"","_EventStartDate":"","_EventEndDate":"","_EventStartDateUTC":"","_EventEndDateUTC":"","_EventShowMap":false,"_EventShowMapLink":false,"_EventURL":"","_EventCost":"","_EventCostDescription":"","_EventCurrencySymbol":"","_EventCurrencyCode":"","_EventCurrencyPosition":"","_EventDateTimeSeparator":"","_EventTimeRangeSeparator":"","_EventOrganizerID":[],"_EventVenueID":[],"_OrganizerEmail":"","_OrganizerPhone":"","_OrganizerWebsite":"","_VenueAddress":"","_VenueCity":"","_VenueCountry":"","_VenueProvince":"","_VenueState":"","_VenueZip":"","_VenuePhone":"","_VenueURL":"","_VenueStateProvince":"","_VenueLat":"","_VenueLng":"","_VenueShowMap":false,"_VenueShowMapLink":false,"_tribe_blocks_recurrence_rules":"","_tribe_blocks_recurrence_description":"","_tribe_blocks_recurrence_exclusions":"","ep_exclude_from_search":false,"_jf_limit_responses":"","footnotes":""},"categories":[883,908,906],"tags":[],"content_source":[],"class_list":["post-8103881","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mindset","category-process","category-technology"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts\/8103881","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8142433"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=8103881"}],"version-history":[{"count":9,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts\/8103881\/revisions"}],"predecessor-version":[{"id":8104705,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts\/8103881\/revisions\/8104705"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8103891"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=8103881"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=8103881"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=8103881"},{"taxonomy":"content_source","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/content_source?post=8103881"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
3. Thin vertical slices for AI are different: Slice by decision, not by screen<\/strong><\/h2>\n\n\n\n
\n
4. Backlog hygiene: Separate model work, data work, and control work, but demo them together<\/strong><\/h2>\n\n\n\n
\n
5. Make feedback frictionless (and visible) inside the tooling people already use<\/strong><\/h2>\n\n\n\n
6. When to say \u201cno\u201d to a model<\/strong><\/h2>\n\n\n\n
\n
What this work has taught me<\/strong><\/h2>\n\n\n\n