I had two thoughts in the spa yesterday. The first was that I’m content, which is not a word I’d normally use about work. The second was that I’m a scrum master again, fourteen years after the last time.
This one isn’t a build log. Nothing broke, nothing shipped, and there’s no config at the bottom. It’s a retrospective on a year of working with Claude more and more, written the day after sitting in a spa that an AI agent taught to heat itself on spare sunshine, which is as good a place as any to wonder what my job has become.
The contentment first
For most of my working life an idea had three possible fates. It got done, which cost an evening or a weekend. It went on a list, which is where ideas go to be felt guilty about; I wrote three articles about a list like that. Or, most often, it never got as far as the list. Too many unknowns, too much effort, too much complexity, or it needed a language I didn’t write and skills I’d have to go and learn first. Those ideas didn’t wait. They were discarded on the spot and forgotten by the end of the day.
That third pile is the seed of the contentment, because it’s the one that no longer exists. A connector written in Rust would have gone straight into it a year ago.
What’s changed is that a small idea now costs a prompt. Not a prompt that builds the thing, usually. A prompt that goes and looks: what’s already there, what the options are, what it would take, and what I’ve got wrong about my own setup. The spa piece is the clearest case I have. The first task in that brief was to discover the current state, read-only, and the first thing discovery found was the Powerwall I’d forgotten to mention.
So every idea gets a hearing. Some come back as “that’s an afternoon”, some as “that’s a bad idea, and here’s why”, and both answers are worth having. What’s left on the list is there because I decided so, not because I ran out of evenings.
And sometimes the answer is “yes, and sooner than you think”. The best example I have is last week’s. My 3D printing business had a website that was friendly right up to the quote form, and after that it was an email to me, with every quote, photo, invoice and tracking number handled by hand from whichever inbox the last message landed in. That had been true for as long as the site existed. Four days later, and those four days were a couple of evenings and a few hours on the weekend, it was an order management system: every enquiry an order with its own page, customers signing in by emailed link, quotes accepted with a tick-box, postage and payment built in. Eight milestones, each a pull request, and the first real order went all the way through on launch day.
I’d have put that project at months, which is to say never.
That’s the contentment. It isn’t the thrill of going fast. It’s that nothing gets thrown away for being too hard any more. Every one of those ideas can be acted on now, and the only limits left are my own: how much I can hold in my head at once, and how much I want it.
Then the job title
In July I wrote that when I work with the agent, I’m the product manager, architect and QA, and the agent is the engineering team. I still think that’s true. I also think it left out most of my day.
Because when I look at what I do between the deciding and the checking, it’s this. I find out why the work has stopped. I log in to the thing the agent can’t log in to. I approve the permission, authorise the connector, restart the service that needs a human at the keyboard. I go and talk to the person who has to agree, whether that’s an open-source maintainer or someone in my own house. I notice the same mistake has happened twice and write the fix down where the next session will read it. I keep things moving.
None of that is product management or architecture. It’s clearing the path so a team can keep working, and I know the name for the person who does that, because I used to be one. Fourteen years ago, when my first Salesforce project went live, I was its scrum master.
I wasn’t hired as one. I was voluntold. I’d been the business subject matter expert through the implementation, which meant I knew what the platform was supposed to do for the people using it, and I’d picked up a lot of Salesforce along the way. I’d been a certified admin for about a year, and I was the only one on the team. The platform had gone live, I was moving out of a business and project role into IT, and the team that would deliver on it from then on needed a scrum master. So I did that alongside the admin work and the business questions, because those were my job too.
It’s an uncomfortably good match for now. Then, as now, I was the one who knew what the thing was for, doing real work on the platform and keeping everyone else’s work moving in the gaps.
Has anyone said this already?
I went looking, expecting to find the idea worn smooth. It’s there, but not quite in this shape. What I found falls into three camps.
The developers say orchestrator. The popular framing is Addy Osmani’s conductor and orchestrator: a conductor steers one agent in real time, an orchestrator hands work to several and reviews what comes back. His comparison for the second is a tech lead delegating to developers and reading their pull requests. I don’t think that’s a rival to my word. Orchestrating is a fair description of half of what a scrum master does. It’s the half you can see. The other half is the unblocking, and that’s the half the metaphor leaves out.
The Scrum people are writing about the scrum master as a separate person. A Scrum.org piece from March describes a team that’s half agents, with the scrum master watching logs and rate limits so the bots stay unblocked. IBM argued last month that agents should take over the status-chasing that has quietly eaten the role, leaving the judgement to the human. Both are about what happens to someone whose whole job is Scrum Master. I’ll come back to why I think that’s the wrong starting point.
The framework builders hand the role to a bot. There are several projects that run a set of agents as a Scrum team, and the scrum master is usually one of the agents. The nearest thing to my thought is in Michael Bleterman’s write-up of AI-Scrum, which says the human ends up as the “Scrum Master of a virtual team”. That’s very close, and it’s the same phrase I landed on. Where we differ is where the human stands. In his design the agents fill every seat on the team, product manager and QA included, and the human sits outside it: setting the direction for the sprint, reviewing what comes back at the end, adjusting the guardrails. That’s a manager of a team. I’m on the team. I write the requirements, I test what gets built against a real system, and I do the scrum master’s job in between.
So: raised, and by people who’ve thought about it harder than I did in a spa. What I couldn’t find is anyone arguing it from the seat I’m in, which is one person, one agent or a few, and no org chart anywhere in sight.
Where it fits
The Scrum Guide is short and worth rereading with an agent in mind. Four things describe my year better than I expected.
A scrum master who also does the work. I’ve never believed in the dedicated scrum master. The role works when it’s held by a member of the team who gets real work done too, and it goes wrong when it becomes somebody’s entire job. That’s what IBM’s piece reads like to me: a description of a role that filled its empty hours with ticket-tidying. The human in the loop can’t go that way. I’m specifying, testing and deciding, which is real work by anyone’s measure, and the scrum master part happens in between because somebody on the team has to do it and I’m the only one who can.
Impediments. The scrum master is the one who causes impediments to be removed. With an agent, almost everything that stops the work is something only I can remove: a credential, an approval, a decision, a cable. On the Rust contribution, the Windows toolchain ate an afternoon, and no amount of capable code generation was going to install it.
Serving, not assigning. A scrum master isn’t the team’s boss. The Guide calls them leaders who serve. I don’t tell the agent how to do the work, and the sessions go worse when I try. I make sure it can see the system, has the context, and knows what done looks like.
The retrospective. In Scrum the team stops at the end of each sprint to ask what went well, what didn’t, and what to change. With human teams the actions have a way of evaporating by the next sprint, because people carry the lesson in their heads and feel that’s enough. An agent carries nothing in its head overnight. If the lesson isn’t written down where the next session reads it, it didn’t happen. The lessons in my instruction files mostly have a date on them and an incident behind them, which makes them the most rigorous retrospectives I’ve ever kept.
Where it creaks
Honest version. The analogy strains in two places.
The Guide gives the requirements to the product owner, not the scrum master. When I said my job included managing stakeholders and requirements, that was the product owner’s half. I hold both, and on a team of people that’s a known hazard: there’s nobody to push back when the one who wants the feature and the one protecting the team are the same person. I haven’t solved that. I’ve mostly been lucky that the agent pushes back for me, as it did over the Powerwall.
And a scrum master’s team is supposed to get better at running itself. Mine starts from zero every morning. I’m not coaching a team towards independence. I’m its memory.
Don’t give the job to the agent
The full-time scrum master has mostly gone. Capital One removed its whole agile job family in January 2023, about 1,100 roles, saying the work would be folded into engineering. One writer’s check of job listings this August found the standalone title close to absent in Toronto and London, bundled with other skills in the United States, and surviving mainly in the big Indian consultancies where it’s a billable line. I don’t mourn it. That’s the version of the role I never believed in.
But there’s a tempting next step, and the frameworks I found have nearly all taken it: if nobody’s job is scrum master any more, make it an agent’s. I think that’s a mistake, and it’s the same mistake in a new place.
An agent can do the parts of the job that were never the point. It can chase status, tidy the board, notice that something has been stuck for two days and say so. Let it. What it can’t do is the thing the role exists for. The impediments worth the name need someone with access, authority and standing: a credential only I hold, a decision only I can make, a conversation with a person who needs to hear it from a person. An agent scrum master can tell you the team is blocked. It can’t unblock it.
That was always the critical piece. The scrum master was there to unblock the team and keep it productive, and everything else was housekeeping. Most of what the full-time version of the role fussed over was exactly that: housekeeping, done at length, to justify the position. It’s also, as far as I can tell, the plainest answer to why the humans are still needed. For now.
So the role didn’t disappear. It moved to whoever is in the loop. Call it the agentic scrum master if it needs a name: a human on the team, doing real work, whose team happens to be agents. In my experience that’s the arrangement that gets results, and it’s the one the role should have been all along.
Why content, and not fried
Not everyone doing this is happy. Boston Consulting Group surveyed about 1,500 workers this year and found 14 per cent reporting a kind of mental hangover from working with AI tools, with productivity turning down once people took on a fourth agent. Flavio Copes, who has shipped a remarkable amount this way, wrote last month that the small satisfactions of building things by hand have gone, and that the joy has moved to deciding what should exist.
I recognise both. I usually have two or three sessions going at once, and that’s comfortable. I can push it to six, and at six I hit exactly what that survey describes: I’m switching context faster than I can rebuild it, and I can feel the quality of my decisions dropping. Their number and mine are close enough that I believe theirs.
And the pressure is real. An agent sitting there waiting for me pulls harder than an unread email, harder than the red badge on Slack. It has stopped, it has said exactly what it needs, and the only thing between it and the next hour of work is me.
But that feeling is borrowed from somewhere else. It comes from working with people, where waiting genuinely costs something. A person who’s blocked on you is losing their afternoon, and the clock on that is what makes so much of working life stressful. I learned to feel that clock, and now I feel it for something that doesn’t have one. A waiting agent costs nothing. It doesn’t get bored, it doesn’t lose the thread, and it will be in exactly the same state in an hour or tomorrow morning.
So this is the adjustment, and I think it’s the one that decides whether you end up content or fried. Six sessions waiting is not six people waiting. When it’s too many, I let three of them sit, and nothing is lost. The urgency was never coming from the agents. We spent years building tools that turn every human interaction into something time-sensitive, and it would be a waste to do the same thing to ourselves with the first colleagues who genuinely don’t mind.
The retro
What went well. Ideas get a hearing. I’ve shipped in languages I don’t write. The lessons get written down.
What didn’t. I still brief from memory instead of from the system, and the agent still has to catch me at it. I’m the bottleneck more often than the agent is.
What I’d change. Treat the unblocking as the job, not as an interruption to it. Write the lesson down the first time, not the third. Let a waiting agent wait.
Fourteen years ago I was a scrum master because a project needed one and I was already on the team. It turns out I am again, for the same reason. The team just types faster.
Co-authored with Claude, because I don’t do anything alone any more.
Top comments (0)