You cannot lead what you have not lived. Transformation does not wait for permission — and neither should you.
When my organization started encouraging everyone to use Microsoft Copilot, most people treated it as an invitation to explore. I treated it as a window.
I did not wait for a training team to schedule something. I built a Prompt Engineering 101 session and ran it myself. Not because it was in my job description, but because I knew that how people first learned to prompt would shape the value we got from every interaction and what it would cost us at scale.
The Cost of Poor Prompting
Poor prompting is not just ineffective; at enterprise scale, it is expensive. Token utilization compounds quickly, and most adoption rollouts do not talk about that until the bill arrives.
I opened the session with a simple demonstration. I typed “Create a business requirements document.” The model produced pages of generic, loosely structured output that nobody would use without a significant rewrite.
Then I showed the same request rebuilt using structured frameworks RTF (Role, Task, Format). “You are a business analyst at a financial services company. Create a business requirements document for an internal loan processing workflow. Structure it with sections for objective, scope, functional requirements, and constraints. Do not include any customer names, account numbers, or proprietary data. Keep the response under 500 words.”
The initial prompt forces the model to guess everything — who, what, scope, format — which produces bloated generic output and burns tokens on content nobody asked for. The structured prompt gets a usable first draft in one shot, with boundaries that protect sensitive data.
Teaching Guardrails Early
The session was not just about getting better outputs. We talked about guardrails. We talked about what our company policies actually meant in practice when you are feeding real business context into a model. I wanted people to build good habits from the start, not learn the hard way after something went wrong. The room was engaged in a way that a policy document never produces. People had questions they had been sitting on for weeks.
That was my first real lesson in leading AI change rather than following it. The window is open for a short time. Someone is going to define how your organization learns to use these tools. It might as well be someone who thinks carefully about the consequences.
Feedback Loops Do Not Stop at the External Customer
A few months later, my team had built an AI agent that automated user story creation. The conversation immediately moved to what features to add next. More intelligence. Better outputs. Additional integrations.
I asked a question that made the room quiet for a moment: Do we actually know if people are using what we already built?
Nobody had a clear answer. We had deployment data. We did not have adoption data. We did not know which teams were using it regularly, which had tried it once and stopped, or what friction was getting in the way.
We were about to pour investment into improving a product without first closing the feedback loop on what we had already shipped. We would never do that for an external customer. We were about to do it reflexively for an internal one.
Adoption Over Features
We paused the improvement backlog and ran a structured adoption survey first. What we found changed the direction of the work entirely. Functionality was not the barrier. It was trust and habit. People were uncertain whether the agent’s outputs were reliable enough to act on without heavy review. That is a transparency and education problem, not a feature problem. No amount of new capability would have fixed it.
This is not a new idea. It is about inspect and adapt. The twelfth principle of the Agile Manifesto calls for regular reflection on how to become more effective, and the practice of frequent delivery exists precisely so teams can gather real feedback before building the next thing on top of assumptions. We apply this discipline rigorously to external products. We rarely apply it to the internal tools and agents we build for ourselves.
The principle is not complicated: internal agents deserve the same feedback discipline we apply to anything we build for customers. They have users. Those users have needs, frustrations, and workarounds. You have to go find out what they are before you build the next thing on top.
Cultural Change Happens in the Room, Not in the Announcement
The shift I did not expect came when I introduced an AI agent into backlog refinement.
I had expected efficiency. What I noticed was engagement. People who typically came to refinement passively, letting the loudest voices shape the conversation, started reacting to what the agent surfaced. They questioned it. They corrected it. They used its outputs as a starting point for a sharper conversation rather than a conclusion to accept.
The agent did not replace the judgment in the room. It shifted who felt confident enough to use it.
Making Thinking Visible
One moment stood out. A team member who rarely spoke during refinement — someone who would typically listen and nod — reacted to the agent’s output with a perspective none of us had considered. The agent had framed the story from an angle the team hadn’t discussed, and that reframing gave him something concrete to respond to rather than a blank canvas to contribute to. He pushed back, refined the idea, and suddenly others followed.
The conversation that opened up was not just more inclusive. It was sharper. People started asking clarifying questions about the story that had never come up in previous refinements. Assumptions that had been silently baked in for weeks surfaced in a single session.
The agent did not make the team smarter. It made the team’s thinking visible and that visibility gave everyone, not just the loudest voices, something to engage with.
Cultural change in AI adoption does not come from announcements or mandatory training. It comes from people having a different experience inside a meeting they were already attending. Ceremonies are the most underused lever a Scrum Master has in this transition. You do not need to introduce AI as a big initiative. You need to bring it into the room and let the team react to it honestly.
You Cannot Teach What You Have Not Felt
I participated in an AgentHack — a hackathon focused on building AI agents because I realized there was a gap in my own credibility that I needed to close.
I was facilitating conversations about AI agents, asking teams to reflect on how they were building and adopting them, and I had not yet gone through the experience of building one myself. That gap was invisible in most conversations. But I felt it. When a developer described the friction of prompt iteration, I was nodding without fully knowing.
Experience Changes Facilitation
Building changed that. I felt the distance between what I imagined an agent would do and what it actually did. I understood, in a way I had not before, why the user story agent adoption problem was about trust rather than features. I came back and facilitated differently, asking sharper questions, sitting with uncertainty more comfortably, and describing AI challenges in terms I had earned rather than inherited from other people’s articles.
If you are leading AI adoption conversations and you have not yet built anything, I would encourage you to close that gap. Not because it will make you technical. Because it will make you honest.
The Change Agent is Not the One Who Knows the Most
I want to be careful about what I am and am not claiming here. I am not the AI expert on my teams. I do not have the deepest technical knowledge in the room, and I do not need to.
What I have is fifteen years of watching organizations struggle with the human side of change — the trust gaps, the adoption plateaus, the moments where good technology sits unused because nobody helped people know what to do with it. That experience is what this moment actually needs. Not because AI is just another change management challenge — it is bigger and faster than most — but because the fundamentals have not changed. People still need safety to experiment. Feedback loops still matter. Governance embedded early is still cheaper than governance bolted on late.
The Scrum Masters who lead this moment are not the ones who know the most about AI. They are the ones who go first, reflect honestly on what they find, and bring it back to their teams without waiting to be asked. That is servant leadership. It always has been.
A Final Thought on Transformation
I will be honest: transformation is not easy. I have seen it stall, lose momentum, and quietly get deprioritized when the next urgent thing arrives. I have felt the weight of trying to move people toward something they cannot yet see the value of.
But the one thing I keep coming back to is this: if you want to lead the transformation, you have to be part of the transformation. Not a commentator on it. Not a facilitator of it from a safe distance. Actually in it — learning, building, stumbling, adjusting.
Going First
So here is what I would ask of you. Pick one thing this week. Run a prompt engineering session for your team. Bring an AI agent into your next refinement. Survey your team on an internal tool they already have access to but probably underuse. Or sign up for a hackathon and build something uncomfortable. You do not need to go far. You just need to go first and then bring what you learned back to the room.
That is how you stay two steps ahead. And that is how transformation actually moves.
