The Google AI Professional Certificate is now the most popular gen AI program on Coursera, and we are expanding it with vibe coding.

Wasim Osman: When a Scrum Team's Silence Becomes a Self-Fulfilling Prophecy

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

 

"No team is interested in deliberately destroying their outcome or their team. Nobody does that on purpose." - Wasim Osman

 

Wasim's team was building a SaaS product with real potential. They followed Scrum, shipped features fast—and quietly let the bugs pile up. When customers finally pushed back ("you built five features, four of them have bugs"), the team made a confident bet: one quarter for new features, then one month to fix everything. It didn't work. The bug-bashing month revealed deeper, structural problems that demanded refactoring, and the roadmap was already packed. Then the fixes got handed to a single team, who felt demoted from the "prestigious" work of building features. Resentment grew between the teams. At the height of that tension, the company was acquired by a waterfall-driven parent company. The head of engineering left, the chief architect and two senior engineers followed, and it became chaos. Wasim's hardest lesson wasn't about the acquisition—it was about voice. The engineers assumed waterfall was being forced on them and stopped pushing back; leadership assumed the engineers were fine with it. Nobody said what they actually thought, and the fear became reality. As Wasim puts it, there was "no captain on the ship."

 

In this segment, we talk about how even conversations need to be iterative, and how a Scrum Master has to balance speaking up (so the team isn't rudderless) without speaking so much that the team stops voicing their own opinions.

 

Self-reflection Question: Where on your team is an unspoken assumption quietly hardening into reality, and what would it take for you to name it out loud first?

Featured Book of the Week: Difficult Conversations by Douglas Stone, Bruce Patton, and Sheila Heen

Wasim's most-recommended book is Difficult Conversations: How to Discuss What Matters Most. What stuck with him is a deceptively simple model: every hard conversation is really made of three conversations—the "what happened" conversation (the content), the feelings conversation, and the identity conversation (what the situation says about whether you're competent, good, or lovable). "When I first read it, I thought there can't be only three types of conversations," Wasim admits. "But once you've gone through the book, you can put any conversation into one of those funnels." He found it especially powerful in retrospectives: when the same issue keeps resurfacing, the real conversation is often about feelings, not action items—someone was never okay with an earlier decision, and that's why the follow-ups never happened.

 

Self-reflection Question: In your last tense retrospective, which of the three conversations—content, feelings, or identity—was really driving the room?

 

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

 

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

 

Buy Now on Amazon

 

[The Scrum Master Toolbox Podcast Recommends]

 

About Wasim Osman

 

Wasim Osman is a seasoned Agile Coach and a Product Owner at Orkestra SCS. He launched his agile career at a Silicon Valley startup based in New York, then spent years coaching teams across Canada, helping organizations transform how they deliver value. Wasim brings a rare blend of agile discipline and product thinking. He's passionate about building technology that drives real business impact.

 

You can link with Wasim Osman on LinkedIn.

 

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20260811_Wasim_Osman_Tue.mp3?dest-id=246429

---

Agents are unusually capable credential-handling tools. They read logs, execute commands, inspect files, call external services, and frequently operate on inputs that weren’t written by the person who deployed them.

Giving an agent a long-lived secret means trusting not only the agent itself, but every tool it invokes, every file it reads, and every instruction it encounters, magnified by autonomous decision making.

At exe, we believe agents should be able to access everything they need. That said, we do our best to avoid giving them persistent credentials that could leak.

The safer model is to give the agent an identity and let it obtain narrowly scoped, short-lived access when it needs it. We’ve already built quite a few things around this idea, including our HTTPS proxy integration and our LLM integration, and recently we added support for Workload Identity Federation, or WIF.

So what is WIF, and why is it a big deal?

Years ago, back when I was working on Kubernetes, one of the most popular workflows users had was giving workloads running in k8s access to some cloud resource, say BigQuery.

The typical solution up until that point was to create a service account, download its secret JSON file—which let you act as that service account—put it in a Secret in the k8s API, mount it into your pod, and then configure the cloud APIs to use it.

It was a fairly suboptimal user experience. The secret had to be long-lived, could be leaked, needed to be rotated periodically, and there was really no way to know who or what was using it.

Sounds familiar!

Then the great security engineers working on Kubernetes realized that, by adding a few features to GCP and Kubernetes, they could use the Kubernetes API server as a trust boundary by having it act as an identity provider.

In some ways, it already was one: the secrets were stored there, it already had a concept of service accounts, and it knew which workload was running as which identity.

It worked by letting pods ask the k8s API server for a signed token (or JWT), which could then be presented to GCP to impersonate a service account. GCP would confirm that the k8s API server had signed it and that the cluster was within the configured trust boundary.

If everything was configured correctly, your Kubernetes pods could now magically act as a GCP service account without ever being given a long-lived GCP credential. As a bonus, you could know exactly which pod was accessing which resources.

Under the hood, this uses a lesser-known OAuth 2.0 flow called token exchange. One system issues a cryptographically signed token asserting who you are, and another system decides whether it trusts that issuer and is willing to exchange that token for one of its own.

The method quickly spread, and all the major clouds shipped some version of it. Things like GitHub Actions adopted it too, letting you use GitHub’s identity to access cloud resources instead of storing long-lived cloud credentials.

The new exe WIF integration follows suite and allows an agent (or workload) running on exe to use its identity to access resources on any cloud, or really anywhere, without needing a long-lived credential sitting around inside the VM.

It is the same basic idea Kubernetes arrived at years ago: give the workload an identity, establish trust between systems, and mint short-lived access when it is actually needed instead of copying secrets everywhere.

To use it in exe, go to the integrations page and create a new Identity Federation integration. You can then attach it to tags or individual VMs.

You’ll need to configure the resource provider (GCP, AWS, etc) to consume the credentials. We have some guides for AWS and GCP already and more are coming soon.

We would love to hear which services you would use this with and how we could improve the experience.

Bonus - sequence diagram

sequenceDiagram
    autonumber

    box Inside the exe VM
        actor Agent as Agent or workload
        participant Auth as Google auth library
    end

    box exe.dev
        participant Integration as Attached WIF integration
        participant Issuer as exe.dev OIDC issuer
    end

    box Google Cloud
        participant STS as Google STS
        participant IAM as IAM Credentials API
        participant BigQuery as BigQuery
    end

    Note over Integration,BigQuery: One-time setup<br/>The integration is attached to this VM<br/>Google trusts the exe.dev OIDC issuer<br/>The exe identity may impersonate the service account

    Agent->>Auth: Make a BigQuery request

    Note over Auth: Google auth loads the external account configuration<br/>and discovers the exe token endpoint

    Auth->>Integration: Request an exe identity token

    Note over Integration,Issuer: Request crosses from the VM<br/>into exe.dev

    Integration->>Integration: Verify the VM is allowed<br/>to use this integration
    Integration-->>Auth: Short-lived exe.dev OIDC token

    Note over Auth,STS: The VM sends the exe identity token<br/>directly to Google Cloud

    Auth->>STS: Exchange exe.dev OIDC token<br/>for a Google federated token

    opt Google does not have the signing keys cached
        STS->>Issuer: Fetch OIDC metadata and signing keys
        Issuer-->>STS: Issuer metadata and signing keys
    end

    STS->>STS: Verify signature, issuer,<br/>audience, expiry, and subject
    STS-->>Auth: Short-lived federated token

    Auth->>IAM: Request an access token for<br/>the configured service account
    IAM->>IAM: Verify the exe identity may<br/>impersonate the service account
    IAM-->>Auth: Short-lived service account access token

    Auth->>BigQuery: Call BigQuery with<br/>the service account access token
    BigQuery-->>Auth: Query response

    Auth-->>Agent: Return result

C# expert Mark Michaelis explores what .NET developers still need to learn for themselves as AI takes on more coding work, highlighting DevOps, testing, technical debt and the engineering discipline needed to keep agentic development on track.

Part 1 of 8: Durable AI for InterlinedList

---

I’ve been chewing on a question for weeks. If InterlinedList is going to have real AI features (the “Coming Soon” ones on the pricing page, the ones I actually want to use myself) what does the plumbing behind them look like? Not the prompts. The plumbing. And every time I sketched it out, I hit the same wall in the same four places.

So I did the thing I’d tell anyone else to do. I stopped sketching in a vacuum and pointed Claude at the actual repository.

The Wall Is Serverless, and I Put It There

InterlinedList is 100% serverless on Vercel. That was a deliberate choice and mostly a great one. It’s also the thing shaping every AI idea I have, whether I like it or not.

A serverless function has a duration ceiling. It has no durable memory between requests, it can’t pause and wait for you to click “yes,” and when it fails partway through expensive work, it has no idea what it already paid for. For a request/response app that serves pages, none of that matters. For anything that calls a language model, all of it matters. A lot.

Here are the four places I kept getting stopped.

Scheduling is already fragile, and this one isn’t hypothetical. InterlinedList has scheduled publishing today (a Subscriber feature). The cron at app/api/cron/publish-scheduled-messages/route.ts runs every minute. I checked vercel.json, it’s a literal * * * * *. It fans a due post out to Bluesky, Mastodon, LinkedIn, and X, then flips the message out of “scheduled” state. There’s no lock and no idempotency key. So if the cross-posts succeed but that final UPDATE fails (a reaped Neon connection, a cold-start hiccup) the message stays “due” and the next tick republishes it. To every platform. Again. That’s a slow-moving double-post waiting for a bad minute, a bug I already own, sitting in production, with zero AI anywhere near it.

Long generation doesn’t fit. A 16k-token document, streamed out of a model, will blow past a serverless function’s budget before it finishes. There’s no clean way to say “keep going, I’ll be back.”

Batch and agentic work has nowhere to live. “Tag every untagged message.” “Add twenty rows to this list matching these criteria.” “Research my saved links and draft a doc.” Those are multi-minute, multi-step, retry-heavy jobs. A function that dies at ninety seconds is the wrong shape for all of them.

And there’s no cost governor. This is the one that kept me up. Every retry re-bills the model. There’s no budget ceiling, no cheap-model-first policy, no response cache, no dedup. One runaway loop and you’ve torched real money.

The Expensive Line Item Is Never the Infrastructure

Once I reframed the money question, the design mostly wrote itself. This reframe runs under the whole series, so it’s worth stating plainly.

The expensive thing about AI features is tokens, not servers. Basically never servers.

A durable-workflow engine (Temporal, in this case) costs on the order of tens of dollars a month, flat. One small always-on worker, maybe a managed namespace. That number does not move when your users get busy. The model bill does, and it moves a lot.

So the question isn’t “can I afford Temporal.” It’s “does Temporal make the model bill smaller.” And the reason it kept showing up in my brainstorm is that its mechanics do that, structurally:

• Durable memoization. A completed step is persisted. When a six-step pipeline fails at step five, the retry re-runs step five, not the four already-billed model calls before it. A retry never re-invokes an LLM call you already paid for. This is the single biggest saver in the whole list.
• Model cascade. Cheap model first (Haiku, Flash) and escalate to an expensive tier only when the work demands it, or the user explicitly asks for long-form.
• Batching. Tag fifty messages in one call instead of fifty calls. The per-request overhead and the duplicated context collapse.
• Rate-limit obedience. Cap concurrency to stay under provider limits, so you don’t trip a 429 storm whose retries waste both wall-clock and, on some providers, tokens.
• Response and URL dedup. Identical prompts get served from cache. A link that’s already been fetched isn’t fetched again. An embedding is computed once, ever.
• A hard token-budget gate. Check spend before each call and refuse to exceed a per-user ceiling. A leaked key or a runaway agent can’t burn unbounded credits.
• Confirm-before-spend. Pause and wait for the user to approve the plan before generating the expensive part. You don’t pay to build fifty list rows against a schema the model guessed wrong.

Every one of those pushes the bill down. The infrastructure that enables them is a rounding error against what it saves. And I want to be clear that “cheap as possible, relative to running raw Claude or ChatGPT calls” is why the architecture looks the way it does in the first place. I didn’t bolt cost control on at the end. I designed around it, and everything else grew out of that constraint.

Brainstorm Against Your Real Code, Not a Whiteboard

Now the part about working with an LLM to build this, because that’s what this series is modeling.

I didn’t design this on a whiteboard. I opened Claude, gave it the real repo, and asked it to map the idea onto the code that already exists. It found the every-minute cron and traced the exact failure path where the double-post lives. It pointed at lib/security/ssrf.ts and the safeFetch guard that any link-crawling feature has to route through, and at the link detector and metadata fetcher already sitting in lib/messages/. It also noticed there’s no lib/ai/ directory yet. Nothing generative is built, which lines up with AI being “Coming Soon” rather than shipped.

The output of that session was a grounded proposal (temporal-solutions.md) that complements an earlier BYO-key and MCP plan I’d written. That earlier plan covered what the AI produces and who pays for the tokens. It said nothing about orchestration, durability, or cost. This new one fills that gap, and it fills it against real file paths, not imagined ones.

Steal this if it’s useful. Don’t design architecture in a vacuum and then go hunting for where it fits. Let the agent read the actual repository first. Have it map your idea onto the code that exists, name the real hazards, and pressure-test it into something concrete before a single line of implementation. Explore first. The proposal you get back is grounded because the agent actually went and looked.

There’s a catch I want to name up front, because I try not to write brochure copy. Temporal has parts that fundamentally cannot run on Vercel serverless: a durable-state backend and long-lived worker processes that poll continuously. That’s a real new piece of always-on infrastructure in an app I deliberately built to have none. It’s the scariest unknown in the whole plan, and I’m not going to pretend it away.

Next post, I go straight at it: where Temporal actually runs when you’re all-in on serverless, and how the Vercel side stays a three-line client that just kicks off a workflow.

Adron brainstorming and working on InterlinedList.