BONUS: Breaking the Permission Loop in Agile Teams

In this BONUS episode, we explore why teams often wait for permission even when they already have skill, tools, and good ideas. Tara Scott, executive, product, and culture coach and author of Breaking the Permission Loop, explains how agency starts with noticing our own reactions, building alignment, and practicing small moments of self-trust.

When a Compliment Becomes a Detour

"You don't really feel like you can say no. So I said yes."

Tara starts with a startup story many Scrum Masters and product leaders will recognize. She was building momentum with user research when a CEO redirected her into a data science initiative that sounded urgent, but did not answer the core product question: do people actually use this product? The request was framed as a compliment, and that made it harder to challenge. Tara's point is practical: sometimes the permission loop begins in the small space between our concern and the automatic yes that comes out before we have understood the tradeoff.

Slow Down Before the Yes

"Sometimes no isn't even no. It's just not right now or give me more context."

For Tara, the first move is observation. Before a team can change a pattern, people need to notice what happens inside them when pressure rises: defensiveness, shame, blame, justification, or the urge to please. Tara connects this to The Responsibility Process, a practice for recognizing when we are below the line and bringing attention back to our own behavior. In a team setting, this is not about blaming ourselves for everything. It is about giving ourselves enough room to ask a better question before committing to work we do not believe in.

Permission Loops Are Patterns We Can Interrupt

"For me, a permission loop is there's different opportunities within those loops where we can step in and say, this could be a really good time to break this."

Tara chose the word loop because the pattern repeats until someone interrupts it. Teams say, "it is what it is," decisions wait for a manager, and people move through the same script because it feels familiar. The useful part is that loops also create openings. A meeting, a question, a moment of discomfort, or a request for one more thing can become the cue to pause and run a small experiment. The goal is not dramatic confrontation. It is a calmer, clearer way to step into the moment with evidence, context, and a suggestion.

Healthy Alignment Is Different From Waiting for Permission

"It is validate, communicate, confirm."

Tara makes an important distinction between acts of authorization and permission-based behavior. In software teams, some decisions need security, architecture, compliance, or dependency alignment. That is real. The permission loop starts when people ask for approval for things nobody can actually give them, such as self-trust, courage, or the right to raise a concern. Tara's working pattern is simple: validate what needs to happen, communicate it clearly, and confirm that the right people are aligned. That connects closely with intent-based leadership from David Marquet's Turn the Ship Around!: say what you intend to do, check alignment, then move.

Autonomy Without Direction Can Leave Teams Lost

"I was told I have total freedom, but to do what?"

Tara challenges a common agile assumption: autonomy alone will not solve the problem. She describes a team that had been told they had freedom, but no shared goal. Leadership and developers blamed each other, and everyone was using different language for success. Without direction and explicit alignment, autonomy becomes another source of confusion. That is why Tara shifts the focus toward agency: enough trust in yourself to speak, enough confidence to offer a path forward, and enough humility to be wrong and still keep working with others.

Atomic Habits for Breaking the Loop

"We have to start where we start and start small."

Tara connects her six-week practice to James Clear's Atomic Habits: habits continue because the cues and rewards are already wired into us. Breaking a permission loop also needs cues. In Tara's startup example, the cue could have been the CEO asking, "What do you think?" That would have been her window to explain the user research data, name the tradeoff, and propose a better way forward. If the cue does not appear, we may need to create it ourselves. The practice is small, but the shift is significant: prepare for the moment before emotion runs the meeting.

About Tara Scott

Tara Scott is an executive, product, and culture coach with 20+ years in agile, helping organizations build healthier, behavior-driven cultures. Her book, Breaking the Permission Loop, is out now. Tara is a certified Fearless Organization practitioner focused on psychological safety. LinkedIn: Tara Scott.

You can link with Tara Scott on LinkedIn and find more about Tara's work and Breaking the Permission Loop at TaraScott.net.

In my last post I wrote that syntax recall was never the goal.

It’s easy to say though and I wanted to see what it meant in practice.

I extended a small prototype I had centred around a virtual business analyst and virtual project manager. I added a virtual developer agent to the solution then gave them this prompt:

“Create a basic customer order search functionality using a simple HTML form and JavaScript. The form will allow users to input a customer name or order ID, and upon submission, it will display the matching orders from a predefined list. Clicking on a selected order will show the order details below the search results.”

A few minutes later I had user stories, risks and assumptions, 16 tickets with story points, code for the top three tickets and a Visual Studio 2022 solution.

I opened it, hit build, and it ran.

That’s a big chunk of what people in the industry have been paid to do.

So what’s left of these jobs?

~

What I Built

Nothing fancy. Three agents built with Microsoft Agent Framework, each doing the job you’d expect from the title.

• The BA agent takes the requirement and turns it into user stories, functional and non-functional requirements, assumptions and risks.
• The PM agent takes those and creates Jira-style tickets with story points, priorities and acceptance criteria.
• The Developer agent picks up the top three tickets and writes the code.

There’s a button at the end that generates a VS2022 solution.

There’s also a small web front end so you can watch the work move through the pipeline.

It’s a prototype. I recorded a short demo, posted it, and the response was better than I expected. One of the people who liked it was a client.

Here’s the demo:

~

What It Got Right, And What It Didn’t

It worked, but many things jumped out at me straight away. The first thing I noticed was that the BA and PM agents both went well beyond what was asked for.

Here is a breakdown of the main things each agent did.

Business Analyst

• Turned one paragraph into user stories, risks and assumptions
• Added requirements I never asked for: accessibility for keyboard and screen reader users, search handling 5K orders in under 200ms, all text sanitised against XSS
• Flagged its own ambiguity: one input field or two? Would partial name matching match what stakeholders expect?
• Assumed no backend and USD
• Wrote stories with two inputs, name and order ID. The app has one search box

Project Manager

• 16 tickets with story points, across two sprints, for a search page
• Included a cross-browser test matrix and performance tuning
• Marked the sanitisation ticket Critical

Developer

• Built the top three tickets, sanitisation first
• One search box, a results list and a details panel
• Sample data included <script>alert('admin')</script> as a customer name. It renders as plain text
• Wrapped everything in a .NET project with a minimal API. I asked for HTML and JavaScript
• Never called that API. The UI reads from a JS data file, so the sample data exists twice
• Picked the currency from the browser locale: pounds for me, dollars for everyone else

The PM agent marking sanitisation as Critical, and the Developer agent building it first, is defensible. I probably wouldn’t have done that as a first task though.

The agents also didn’t always agree with each other. The BA’s two input fields became one search box. The BA assumed no backend, and the Developer built an API that nothing calls.

Then there’s the estimate. Sixteen tickets and two sprints for a basic search page. An experienced PM would challenge the scope before the first stand-up. Left to their own devices, these models don’t seem to worry about over-delivering. Your token bill will confirm it. ;-)

So, the virtual team was good at producing detailed work that looks ok on the surface. They’re not as good at staying consistent with each other, or knowing when to stop.

Human judgement is required.

~

Where The Work Moves

If pushing around syntax and writing docs is becoming cheaper, the value moves to the start and the end.

At the start, someone has to work out what’s actually needed.

One search box or two? Partial match on names or exact? Is this a quick internal tool or the first step of something that will sit on top of a real database?

The BA agent raised some of these questions itself, which is impressive, but raising a question isn’t answering it. Someone still has to go back to the business, get an answer and make sure every agent sticks to it.

At the end, someone has to check what comes out and be accountable for the output. Saying “the AI generated it” doesn’t cut it.

• Does it handle the edge cases?
• Is it secure?
• Does it fit the existing system and the way the team deploys?

When it falls over in production, who gets the call?

~

Who Gets Squeezed And Who Doesn’t

If your role is mainly taking Jira tickets and turning them into code, these roles are going to contract.  That doesn’t mean software development disappears, but it does mean teams may need fewer people to produce the same amount of code.  Highly regulated environments, and organisations that aren’t comfortable with their data being pushed to an overseas frontier firm, will be slower to adopt, but I don’t think they’ll be immune.

The wider industry is starting to grapple with what this means for its workforce. Microsoft recently announced a voluntary exit offer available to around 60,000 employees across participating teams.  About 25% of the workforce, that’s substantial.

That doesn’t mean 60,000 people are being replaced by AI, and Microsoft hasn’t claimed that. But against the backdrop of its substantial AI investment, it raises a question worth asking: as companies spend more on AI and change how work gets done, will they need the same number of people to deliver it?

Equally though, I don’t think AI is all bad news for the industry. Most real systems aren’t greenfield. I spend a lot of my time reverse engineering legacy systems and replacing them with more recent technologies.

Agents can help with that, but you still need someone who understands what the old code is doing and why it was written that way in the first place. Someone also has to design how it all fits together, decide what not to build, and keep it running in production.

Also, someone has to run the agents. Set them up, keep them on track, check what they produce and take responsibility for it.

That still leaves the question from my last post. If AI writes the code, how do people starting out build their judgement?

I don’t have a perfect answer for that.

My advice would be to use the agents, but understand the output. Trace the code, run the tests, investigate the decisions and understand why the solution works. Don’t accept an answer just because it builds. Call the model out when your experience or wider context tells you there’s more to consider.

~

Where I Am Now

I started out as a .NET developer over 20 years ago. I was the guy on client sites, some with the internet disabled for security reasons, building CRUD apps from memory.

These days, I still type code, but a little less than I used to. The bulk of the time is on engaging stakeholders, figuring out the problems, working out what should be built, how it fits together, and whether what’s been built is any good.

The prototype is done, but it’s not a massive leap to take it to the next logical step and implement a Tester agent that turns the acceptance criteria into tests and keeps looping until they pass.

~

Closing Thought

A short paragraph of requirements to a working Visual Studio solution in a few minutes. A couple of years ago I wouldn’t have believed it.

But the agents didn’t decide what was worth building. They didn’t settle the questions they raised. And they won’t be the ones answering for it if it breaks.

That part is still on us.

Generating code is getting cheaper but good judgement is not. And that comes with experience and being in the trenches.

What do you think?

Drop your comments below.

~

In a conversation between a group of software developers recently, one of them talked about how many attempts it took them using Claude Code to get a good result.

The consensus was that devs who needed fewer tries were better at using the tool. But I’m not so sure…

I’ve recently been spending my weekends and early mornings “vibe-coding” a browser-based tool with Claude Code for folks to use in online modular design workshops – in the definitive Karpathy sense that I wasn’t even looking at the code being generated. (When I did finally peek at the code, I regretted it.) And it’s been through a lot of iterations and many, many tweaks to get it into the ballpark of what I consider good enough for the workshops.

So I must be doing it wrong, right?

Or do I just have a clearer sense of what I want?

Take two film directors – Ed Wood and Stanley Kubrick. Wood famously rarely did more than one take on any of his movies. Kubrick did many, many takes. Kubrick must have been doing it wrong, no?

Or was he just less easily satisfied? Watch their two most famous science fiction films back to back and let me know who you think was the better director.

There’s some research that suggests that the divide between the “I did 3 months’ work in 3 hours with Claude” and the “It would have been quicker to do it myself” folks might be more plausibly attributed to the height of their quality bar than to actual AI skills.