Agilish

Given that UAT is reserved for external-facing testing against market infrastructure and external partners, your internal teams need somewhere else to test. That environment is QA — and the name is where things start to break down. UAT is a term almost everyone understands. Say it in a room full of developers, business analysts, project managers, or regulators, and they all broadly know what you mean: the environment where acceptance testing happens before a release goes live. QA does not carry the same shared understanding. Ask teams across different systems or business lines what they call their pre-UAT environment, and you will get a different answer from each one: SIT (System Integration Testing), INT (Integration), TEST, UAT2, STAGE, or simply "the lower environment." These are all names for the same concept, but the lack of consistent terminology creates real operational friction. When teams across multiple systems are trying to coordinate an end-to-end test,...

AI writes the code, so we need fewer developers. And if we need fewer developers, the thinking goes, we probably need fewer testers too. The software just…works. That story is wrong . Not slightly wrong. Fundamentally and dangerously wrong. AI is changing how software gets built. It is not changing the fact that software is used by humans, that humans make mistakes, that systems fail under pressure, and that every new line of code — whether written by a person or generated by a model — introduces new ways for things to go wrong. If anything, the rise of AI-generated software makes rigorous, human-led testing more important, not less. AI Makes Testing Better — It Does Not Make It Optional None of this is an argument against using AI in testing. AI is already making testing faster and more thorough. It can generate test data at scale, suggest regression suites, identify patterns in defect history, and reduce the mechanical burde...

I value trust and honesty as core beliefs. I have always been transparent in work and in my personal life because I have nothing to hide. I do not lie, cheat, or steal — so why wouldn't I be? With that context, this post is not an April Fool. But I do want to share the best April Fool that ever got me. It got thousands — if not millions — of us. Every year I think about it, remember my friend Erik and his dad, and I smile. 1985 The year was 1985. Erik and I were baseball-crazy teenagers getting ready for our first freshman high school baseball season. I was finishing dinner with my parents when the white rotary phone in my mom's kitchen rang. "It's over! It's over! Baseball as we know it is over." Erik was on the other end, more excited than I had ever heard him. He went on and on about a new pitcher the Mets had found who threw 168 miles per hour with pinpoint accuracy. The Mets would win the World Series — nobody could beat a team with pitching li...

I love fables. Like a picture is worth a thousand words, a simple story with a moral lesson is a good way to share experience — translating something complex into something smaller and more digestible. Looking back across my career, I have led teams of every sort, shape, and size across a lot of different industries. The people were different. The platforms were different. The tools were constantly changing, sometimes mid-project. But when I think across every engagement, one thing runs through all of them: incremental delivery of software. That is the only constant. Not the language, not the methodology, not the org chart or the budget. Just the steady act of shipping working software piece by piece and learning from what it tells you. I have done a lot of it. I have lived through the wins, the near-disasters, and the moments where the wheels came completely off. Every one of those experiences taught me something. Fables strip it down to what matters. A tortoise and a hare do n...

There is a particular kind of manager who is deeply involved in everything and yet somehow never actually close to the work. They attend every meeting. They ask for constant status updates. They want to be copied on every email. They weigh in on decisions that are nowhere near their level. And yet, despite all of that involvement, they do not actually know what is going on. They are micro-managing from 50,000 feet — controlling everything in theory while understanding very little in practice. I have seen this pattern more times than I can count. And I have seen the damage it does. What It Actually Looks Like Micro-managing from altitude is harder to spot than the classic version, where a manager is looking over someone's shoulder telling them how to type. The high-altitude version feels more sophisticated. The manager is "engaged." They are "across" the project. They are "asking the right questions." But what they are really doing is creating...

No, really. Stop for a second and ask it plainly: what is the problem here? If we are doing projects, we are problem solving. We are trying to help our business run more efficiently, compete more effectively, or do something it could not do before. That is the whole point. Everything else — the methodology, the tools, the ceremonies, the frameworks — is in service of that goal. Not the other way around. The Problems Come in Every Shape and Size No two projects are the same. The business problem might be a spreadsheet that one very clever person built five years ago to track customer orders, and which now has 47 tabs, three people who understand it, and zero ability to scale. Converting that into a real system that can be supported and maintained is a genuine problem worth solving — and it looks nothing like building a new customer-facing mobile app from scratch, which looks nothing like upgrading a twenty-year-old core banking platform that nobody wants to touch. The permutatio...

I have lived through this more than once. You walk into an organization, you can see clearly that Agile would make things better, and you hit a wall. Not a wall of bad intentions — most of the people involved are smart, experienced, and genuinely trying to deliver good work. The wall is something older and harder than that. It is culture. It is history. It is the accumulated weight of a command-and-control framework that has been built up over years, sometimes decades, and that has been working well enough that nobody with real power has had a reason to change it. And then you show up and tell them they should. Why Large Organizations Struggle The Agile Manifesto was written in 2001. But mainstream adoption — real adoption, not just putting "Agile" on a job description — did not come until much later. And even today, after more than twenty years, plenty of large organizations are still working through it. That is not laziness. It is complexity. Think about what it a...