Big Agile

Big Agile Contact information, map and directions, contact form, opening hours, services, ratings, photos, videos and announcements from Big Agile, Colleyville, TX.

Big Agile helps organizations deliver tangible business outcomes, not just output, through agile training, executive coaching, and transformation services that cut waste, boost impact, and align teams around what truly matters.

A Scrum Master messaged me last month with a question that summed it all up."Our stakeholders stopped coming to sprint r...
06/10/2026

A Scrum Master messaged me last month with a question that summed it all up.

"Our stakeholders stopped coming to sprint review three months ago. They like the team. They think the work is good. They just don't see the point."

That isn't a relationship problem. It's a signal problem.

A stakeholder is rationally responding to a meeting that doesn't change anything in their world. If you stopped showing up to a recurring meeting and your work life got no worse, you were right to stop showing up.

I've watched four causes do most of the damage to sprint review engagement over the last decade:

The review has no real decisions to make.
The demo requires domain knowledge they don't have.
The work doesn't connect to outcomes they care about.
Previous feedback was ignored without explanation.

Each one has a specific fix. Each one is a one-week change, not a six-month transformation.

If you lead a product or engineering org with a sprint review attendance problem, the diagnosis is usually faster than the cure. And the cure is meeting design, not relationship repair.

Read the full breakdown including the 5-question diagnostic for a disengaged stakeholder: https://big-agile.com/blog/why-stakeholders-stop-engaging-with-sprint-reviews-and-what-brings-them-back

Your sprint review might be the most expensive meeting on your calendar. Ten engineers, a few product folks, a VP, a cou...
06/08/2026

Your sprint review might be the most expensive meeting on your calendar. Ten engineers, a few product folks, a VP, a couple of stakeholders, ninety minutes blocked off, all to watch a polished demo where no real decision gets made.

The sprint review was never meant to be a show. It's meant to be the moment the team and the business look at reality together and decide what to do next.

In this episode, Lance Dacy lays out how to turn a demo back into a decision meeting, the three questions that tell you which one you actually ran, and why honest feedback loops separate the teams that pull ahead from the ones that fall behind.

Watch or read the full thing at the link in the comments. 👇

Your AI adoption dashboard is green. That should worry you, not reassure you.Here is the tension almost no leadership te...
06/05/2026

Your AI adoption dashboard is green. That should worry you, not reassure you.

Here is the tension almost no leadership team is sitting with honestly.

Developer adoption of AI tools hit 84% this year. Trust in the accuracy of what those tools produce sits around 29%. People are leaning on tools they increasingly do not believe, and most organizations are only measuring the leaning.

To me, that is a trap. We see it in the outcome vs. output metrics debates all the time.

Adoption rate is the easiest number to move and the least useful to brag about. It can only go up. It tells you people are using AI. It tells you nothing about whether the work is any good.

There is a better number, and almost nobody tracks it. I walk through what it is, why a "zero rejections" report might be your biggest red flag, and the exact question to bring to your next leadership review, in this week's edition.

If you lead a product or engineering org and you are reporting AI adoption upward, this one is worth a few minutes.

New edition of Next-Gen Agility is live!

A product team I worked with shipped something genuinely good last spring. An AI assistant built into their support tool...
06/04/2026

A product team I worked with shipped something genuinely good last spring. An AI assistant built into their support tool that drafted a first reply to every ticket. Launch week looked great. Three weeks later, the usage chart showed a cliff.

The agents who tried it had quietly gone back to writing every reply by hand.

The instinct in the room was familiar. Better onboarding email. Lunchtime webinar. Maybe a tooltip.

Here is the uncomfortable part. If people tried it and went back to the old way, they understood it well enough to reject it. More explaining was never going to fix that.

Adoption does not get won at launch. It gets won during development, in three quiet decisions most teams skip.

Did we say the value in the user's own words, or in our feature language?

Did we make the system easy to trust, with a visible confidence signal and a one-click override?

Did we measure how long it takes a new user to reach their first real win, and then cut everything in between?

With AI, the bar is even higher, because people lose faith in an algorithm faster than they do in a person after the exact same mistake. Your good product is carrying a trust that a human would never have.

So before you draft another onboarding email, pull your usage data. Find the one action where a user first gets value. Measure the median time from signup to that moment for your last twenty users.

That number is your adoption problem, stated plainly. And it is yours to fix.

Read more: https://big-agile.com/blog/your-product-is-good-adoption-is-still-stuck

A product leader told me last week that she approves code she could not read if her life depended on it. Then she added,...
06/04/2026

A product leader told me last week that she approves code she could not read if her life depended on it. Then she added, almost apologizing, "and now a lot of it is written by AI."

She is not behind. She is most product and engineering leaders right now.

Here is the part nobody hands you. In October, Ox Security analyzed more than 300 repositories and found AI-generated code is not more buggy per line than human code. The trouble is that AI repeats the same structural shortcuts over and over, and it strips out the slow-downs (review, debugging, the careful second pass) that used to catch them before customers did.

You do not have to learn to read code to manage that. You have to learn the handful of predictable ways AI code goes wrong, and ask about them in the rooms you are already in.

So I translated all ten patterns Ox Security documented into plain language, with one question you can ask in a sprint review for each. Things like fake test coverage that lifts the dashboard without testing anything real, and code that worked on someone's laptop but ignores production.

You will not sound like an engineer. You will sound like a leader who knows where the soft spots are.

If you lead a product or engineering org and you are funding AI-assisted delivery, you cannot personally inspect; this one is for you.

Link in comment below

A product leader told me last week that she approves code she could not read if her life depended on it. Then she added,...
06/03/2026

A product leader told me last week that she approves code she could not read if her life depended on it. Then she added, almost apologizing, "and now a lot of it is written by AI."

She is not behind. She is most product and engineering leaders right now.

Here is the part nobody hands you. In October, Ox Security analyzed more than 300 repositories and found AI-generated code is not more buggy per line than human code. The trouble is that AI repeats the same structural shortcuts over and over, and it strips out the slow-downs (review, debugging, the careful second pass) that used to catch them before customers did.

You do not have to learn to read code to manage that. You have to learn the handful of predictable ways AI code goes wrong, and ask about them in the rooms you are already in.

So I translated all ten patterns Ox Security documented into plain language, with one question you can ask in sprint review for each. Things like fake test coverage that lifts the dashboard without testing anything real, and code that worked on someone's laptop but ignores production.

You will not sound like an engineer. You will sound like a leader who knows where the soft spots are.

If you lead a product or engineering org and you are funding AI-assisted delivery you cannot personally inspect, this one is for you.

A new MIT/Wharton paper landed last week (May 27, 2026) that puts hard numbers on the productivity paradox I have been w...
06/03/2026

A new MIT/Wharton paper landed last week (May 27, 2026) that puts hard numbers on the productivity paradox I have been writing about all last week.

The authors measured AI coding productivity across 100,000+ GitHub developers, tracing the effect from individual keystrokes all the way to shipped software.

The pattern they document is the cleanest version of an argument I have been making the long way around.

When developers adopt AI coding agents:

Lines of code: +741%
Pull requests: +65%
Releases: +20%

The engine got faster. The car did not get faster because nothing else in the production system scaled with it. The bottleneck moved from writing code to reviewing, integrating, and shipping it.

The paper's deepest finding is a structural parameter. The elasticity of substitution between AI output and human effort in software production is 0.25. In plain English, that means AI and humans are strong complements in this work, not substitutes. You cannot solve a review bottleneck by adding more AI.

You can only solve it by upgrading the review.

This is the productivity paradox with the kind of rigor most operating dashboards will never reach.

Source: Demirer, Musolff, and Yang, "Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools," MIT and Wharton, May 2026.

Link: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6843118

Ask the person who has done the job for fifteen years to explain how it works, and watch what happens.They start strong....
06/03/2026

Ask the person who has done the job for fifteen years to explain how it works, and watch what happens.

They start strong. Three steps in: "well, it depends." A few steps later: "oh, except for the corporate accounts." And then they tell: "I don't really think about it, I just do it."

That person is the most valuable source of truth in the building, and they still cannot fully tell you what they know.

We keep treating that gap as a tooling problem. It is not. Talking to computers has been getting easier for seventy years, from punch cards to plain English. Talking to humans about what they actually need has not gotten easier at all.

AI is crushing the cost of building and barely touching the cost of understanding. Which means the expensive problem, knowing what to build, is now the only one left standing. And cheap building makes it more tempting to skip.

The scarce skill is no longer coding. It is not even prompting. It is knowing and being able to say what you actually need.

New on the blog: why understanding the problem is still the hard part, and how to get good at the part that stays human.

Read the full breakdown: https://big-agile.com/blog/talking-to-computers-is-getting-easier-talking-to-humans-still-hard

A common misconception about an AI-augmented CSPO is that it is a course on prompt engineering.It is not.The AI generate...
06/02/2026

A common misconception about an AI-augmented CSPO is that it is a course on prompt engineering.

It is not.

The AI generates the first draft. That part takes minutes. The actual course is what happens next. Your team translates that draft onto chart paper, debates it, marks it up, throws half of it away, and produces artifacts you can defend to a stakeholder who has never heard of generative AI.

The walls of sticky notes are the actual course.

We give you seven pre-engineered prompts so you do not waste class time tuning prompts. You spend that time on the harder work: deciding what is actually true about your product, your users, and your real team capacity.

Link in the first comment: 👇

Quick gut check: an AI tool writes a feature, it passes all the tests, it ships, and a week later it exposes customer da...
06/01/2026

Quick gut check: an AI tool writes a feature, it passes all the tests, it ships, and a week later it exposes customer data. Who's accountable?

If you had to pause, that pause IS the problem.

AI didn't remove accountability from our teams. It diffused it across so many hands that nobody's quite sure where their job ends and the AI begins. Meanwhile the data shows security findings climbing 10x and architectural flaws surging while everyone's dashboard looks great.

Lance Dacy walks through why this is a leadership design problem (not a developer one) and a dead-simple fix you can try with one team this week.

Watch or read the full episode. Link's in the comments 👇

Address

Colleyville, TX

Telephone

+18775244244

Website

Alerts

Be the first to know and let us send you an email when Big Agile posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to Big Agile:

Shortcuts

Share