Articles
Transparency and the Biased Teammate
AI is not neutral. Teams need transparency around assumptions, bias, and how AI-supported decisions are made.

Transparency and the Biased Teammate
Article 8 of 9 in the series.
Picture a Sprint Review where a stakeholder, respected, senior, and careful, asks a question that should be easy. “Why did the team choose this approach over the alternative we discussed last quarter?”
The Product Owner pauses. The team looks at each other. The decision was made to go with the chosen solution. The rationale for that decision was not. An agent proposed the approach. A human approved it. Neither is in the room to provide the rationale or explain the decision. It is not that people tried to hide the information. Nobody lied. Nobody took a shortcut. It is just that the conversation and decision made simply have no transparent trail back to a human judgment call.
And so, the stakeholder moves on, politely. The team looks professional. But something quiet, and important, has gone wrong.
In the first seven articles of this series, I proposed a Definition of Value, argued accountability concentrates as agents enter the team, reframed refinement as option framing, raised the Increment bar to require adoption, replaced the demo-style Sprint Review with an Evidence Review, named the Tacit Knowledge Tax, and proposed a Context Lake as Product Management’s new core artifact. Seven practices, stacked. This eighth article is about the two properties of a Scrum Team those seven practices are most likely, quietly, to erode if nobody is watching: transparency, and the integrity of the five Scrum Values when one member of the team is, measurably, a biased one.
This is a visionary piece, not a predictive one. I cannot tell you how transparency norms or professional ethics around AI in Scrum Teams will settle over the next five years. I can share how a room full of experienced Professional Scrum Trainers thinks they must evolve, and why the conversation cannot be deferred another Sprint. The full list of contributors from the Amsterdam Face-to-Face Event sits at the foot of the article. The arguments here are mine. The thinking is ours.
The Pillar Most at Risk
The Scrum Guide’s three pillars are transparency, inspection, and adaptation. They are, in that order, a dependency chain. You cannot inspect what you cannot see. You cannot adapt what you have not inspected. Transparency is the foundation.
Make no mistake; the Scrum Guide is not broken here. The pillar is as correctly placed today as it was in 1995. What has changed is the cost of maintaining it. For thirty years, in many teams, transparency was mostly related to transparency of the Product Backlog, Sprint Backlog, Definition of Done, and Product Increment. It was often related to the work to be done, how to approach the work, and the desired quality of the work. A team that pair-programmed, showed its work in refinement, and demoed every Sprint generated transparency almost for free. The Scrum Guide did not need to tell the team how to be transparent. The team’s practices made it transparent.
AI breaks that pattern. More and more of the work, the drafting, the reasoning, the option generation, the summarization, the scoring, happens inside a model nobody on the team can directly see. Transparency stops being a byproduct of the work. It becomes an active discipline the team must now pay for, deliberately, every Sprint.
What “Transparent” Has to Mean Now
Transparency in an AI-powered team means three concrete things, at minimum.
Transparency of direction. The Product Goal, the Definition of Value, the current Option Frame bets, and the guardrails are all visible, legible, and versioned. Every human and every agent on the team reads from the same source. This is the Context Lake from Article 7, working as intended.
Transparency of decisions. Every non-trivial decision carries a visible answer to three questions: what was chosen, by whom, on what reasoning. If an agent proposed the option, the agent is named. If a human overrode or accepted, the human is named. But also, consider how the Agile Manifesto spoke about “Working Software over Comprehensive Documentation.” This Agile value still stands, partly. As long as you focus on building great products, you will need less (user) documentation. However, with the rise of AI, we also see that the need for documentation grows. Documentation like: Why did we build a feature? Why that feature and not another one? Why that feature in that way, and not in another way? And so on. The Accountability Test from Article 2 depends on this trail existing.
Transparency of the agent itself. The team knows what its agents have access to, what they have been tuned on, what their known biases are, and where their outputs require the most human pressure-testing. This is the uncomfortable one, and it is the one most teams are skipping today.
Three layers, one pillar. If any of the three is missing, transparency is notional, not real.
The Biased Teammate
I want to be direct about something a lot of AI discussions dance around. Every AI agent your team is using is biased. Not because it was designed to be. Because the data and optimization it was trained on encoded the biases of the humans, products, and markets it learned from. Research on large language models has repeatedly documented patterns of gender, racial, cultural, and occupational bias, as surveyed in work like Bias and Fairness in Large Language Models, Gallegos et al.. The specifics vary by model, by task, and by prompt. The existence of bias does not vary.
Treat this as a simple, practical fact. A new team member joined your team last year. That team member is fast, productive, and enthusiastic. That team member also carries a set of biases nobody on the team has fully mapped. If the team were hiring a human with that profile, it would, correctly, invest heavily in onboarding, review, and cultural integration. Agents rarely receive the same care.
A biased teammate is not disqualifying. An unexamined biased teammate is.
The Five Scrum Values, Re-read
The Scrum values are courage, focus, commitment, respect, and openness. All five hold. All five are put under new pressure when a biased agent is active in the team.
Courage. The Developers, the Product Owner, and the Scrum Master need the courage to challenge agent outputs, especially the ones that look polished and confident. A plausible-sounding answer from an agent is a test of courage, not a substitute for it. Also, they need to be courageous towards stakeholders, who may approach them with (counter-productive) AI-generated insights, ideas, prototypes, and more.
Focus. The team must focus on the bets it framed in the Option Frame, not on the work the agent happens to produce well. Agents have a gravitational pull toward the work they are fluent at. That is not the same as the work that creates value.
Commitment. The team, not the agent, commits to the Sprint Goal. The team, not the agent, owns the Definition of Done. The distinction matters more, not less, as the agent’s share of the work grows.
Respect. Respect for customers requires honesty about what the team knows and does not know, which means honesty about what the agent has and has not done. Respect between team members requires that an agent’s contribution is not used to paper over a human disagreement.
Openness. The team is open with stakeholders about the role agents are playing, the confidence levels of agent-produced work, and the known biases of the tools in use. Openness about the tools is part of openness about the work.
Get Robbin Schuurman’s stories in your inbox
Join Medium for free to get updates from this writer.
Enter your email
Subscribe
Remember me for faster sign in
Re-read carefully, the five values are not diluted by the presence of a biased agent. They are sharpened by it. A team that takes the values seriously in an AI-powered world is running a higher standard than it was running before, not a lower one.
How the Context Lake Buys You the Pillar Back
The reason the Context Lake from Article 7 is proposed before this article is not stylistic. It is load-bearing. You cannot maintain transparency of direction, decisions, and agent behavior without a curated, traceable place to maintain it in. The Context Lake is that place.
Concretely, the lake is where transparency lives. Decisions are logged there. Guardrails are written there. Agents’ access and known biases are documented there. Stakeholders can be pointed at it. New team members can be onboarded from it. Without the lake, transparency becomes a set of good intentions scattered across Slack threads and quarterly all-hands slides. With it, transparency becomes a property of the team’s operating rhythm.
The Context Lake answers what the team knows. Transparency, in this article, is the discipline that keeps what the team knows legible to the humans and the agents who have to use it.
What This Looks Like in Practice
Picture a fintech team using an agent for first-pass refinement and research synthesis. Without transparency practice, the team notices, eight months in, that most of its recent feature bets have skewed toward urban, high-income user segments. Nobody chose that. The agent had learned, from the corpus it was trained on, to treat those segments as the default. The team’s own backlog has quietly inherited that bias.
With transparency practice, three things were already true. The team had documented, in the Context Lake, the known-bias profile of the agent. The Product Owner had, in each refinement, explicitly asked “what user segment does this bet serve, and is the agent’s framing of that segment balanced against our Definition of Value?” The team had, in the Retrospective, a standing agenda item to review recent bets for skew.
The team was not slower. The team was more honest. Over twelve Sprints, the team’s backlog reflected its actual customer base, not the bias of its most productive contributor. That is a concrete, measurable business outcome. It is also, quietly, a values outcome.
Four Things You Can Do in Your Next Sprint
- Write a one-page Agent Profile for every agent your team uses. What it is, what it has access to, what it is good at, what its known biases are, and what kinds of work require the most human pressure-testing. Store it in the Context Lake. Refresh it quarterly.
- Tag every agent-produced artifact with the agent, the human accountable, and the reasoning for acceptance. A small, visible tag. Not ceremony. A transparency trail that can be read six months later.
- Add one standing question to every refinement. “Whose interests does this bet serve, and whose might it be quietly missing?” Two minutes. If the team cannot answer, the bet is not framed yet.
- In your next Retrospective, inspect the values, not just the work. Pick one value, courage, focus, commitment, respect, or openness, and ask the team where the agent’s presence most tested it this Sprint. The conversation will be awkward. It will also be exactly what the values were written for.
The Turn
For thirty years, Scrum’s three pillars and five values have been treated, in too many teams, as the soft part of the framework. The ceremonies got attention. The accountabilities got attention. The pillars and values sat on a wall, unread. That was survivable when the work was happening in the open.
In an AI-powered world, the pillars and values are not the soft part. They are the only reason the team can trust what it ships. A team that keeps transparency alive, and takes the biases of its agents seriously, is running a harder, sharper, and more professional operating model than any team was running five years ago. That is what aiming higher looks like, at the level of trust.
Over to You
Ask your team one question in your next Retrospective. “What has an agent on this team done in the last four Sprints that no single human on the team could fully explain, defend, or redo?” Listen carefully. If the list is short, you are running transparent. If the list is long, or uncomfortably silent, you have just found the most valuable conversation your team can have this month.
The final article in the series ties every thread together. For thirty years, the Scrum Guide has described the minimum rules. Many teams, comfortably, treat those rules as the ceiling. AI is finally making that a losing strategy. What does it look like when teams stop aiming for average, and start aiming higher than the Guide? See you there.
Contributors
This article was created based on the Scrum.org PST Face-to-Face Event #137 in Amsterdam. It would not have been possible without the discussions with: Dave West, Merel van de Wiel-Riedeman, Tommi Kemppi, Sjoerd Nijland, Jesse Houwing, Robbin Schuurman, Martijn Magermans, Guus Verweij, Steven Deneir, Gregor Stuhldreier, Paul Kuijten, Mehdi Hoseini, Simon Kneafsy, Vivien Colas, Jeroen de Jong, Kate Hobler, Olivier Ledru, Roderick Schoon, Stephan Vlieland, Tiffanie Newton, and Karel Smutný. The arguments here are mine. The thinking is ours.
Sources
The Scrum Guide, Schwaber and Sutherland
Bias and Fairness in Large Language Models, Gallegos et al.
NIST AI Risk Management Framework
Evidence-Based Management, Scrum.org
You Can’t Delegate Accountability to an Agent, Article 2 of this series
The Knowledge Your Team Is Losing, Article 6 of this series
The Context Lake Is Product Management’s New Core Artifact, Article 7 of this series
Scrum Was Written for the Average Team. It Is Time to Aim Higher, Article 9 of this series
Our Ideas
Explore More Articles
Contact




