Agilish

I recently joined the Naperville AI Enthusiasts Meetup, led by James ("Jim") Harmon. The concept is refreshingly simple: bring together a few presenters and a room full of people who are genuinely interested in learning, sharing ideas, and discussing their experiences with AI. Each meeting typically features two or three presentations, along with plenty of time before and afterward for informal conversations and networking. Those discussions are often just as valuable as the presentations themselves. One of the things I appreciate most is the diversity of the group. You'll find experienced software engineers, data scientists, entrepreneurs, and AI practitioners alongside people with little or no technical background who are simply curious and eager to learn. That mix creates an environment where everyone can contribute. One of the most impressive demonstrations I've seen was from a self-taught salesperson who built an outstanding user interfaces leveraging AI tools ...

My friend James Harmon is teaching two AI courses next Friday, June 5th at the Northern Illinois University - Naperville Campus. Here are details about the courses... Claude AI for Everyone 9 AM to Noon ($49) For anyone who wants to put Claude to work: writing prompts that get professional results, real business tasks, and the features most people miss (Projects and Skills). No technical background needed. click here to learn more and register Claude Code: AI-Powered Development in Practice 1 to 4 PM ($99) For developers and power users: build features, debug, and refactor with Claude right in your codebase — plus hooks, MCP servers, and multi-agent workflows. Some coding experience helps but isn't required. click here to learn more and register

I’ve had some time recently to re-tool and refocus, which led me down an AI journey that ultimately resulted in building a showcase web application called Tee It Up Chicago . Tee It Up Chicago is a golf course catalog and utility platform for golfers in the Chicago area, featuring course information, scorecards, handicap tracking, and other tools designed for local players. I am working on adding round and match scoring and other features to make outings and tournaments easier to score and track. The best way I can describe the experience working with agentic AI agents is this: it feels like having the smartest kid from my computer science class sitting next to me, helping me build software. This “AI teammate” never gets tired, never complains when I ask a basic question, and can jump in and write code when I need it to. The more I’ve worked with these AI coding tools, the more I’ve learned how to collaborate with them effectively — and the faster I’ve been able to build web appl...

Some organizations decide to maintain only two environments: Development and UAT. The reasoning usually sounds practical. One fewer environment to maintain. One fewer pipeline to manage. One less budget line to defend. In practice, it eliminates the one thing that makes a pre-production release testable. When QA and UAT are the same environment, in-progress work and release candidates sit side by side. Business stakeholders doing acceptance testing are looking at code that may not even be part of the upcoming release. External partners are testing against something that does not represent what production will look like. Most critically, there is no stable, controlled place to validate the actual release before it ships. The result is that the final validation happens in production. Nobody sets out to test in production — but many organizations end up there because they removed the environment that would have prevented it. UAT as Your Most Valuable Diagnostic Tool Con...

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...

ag·il·ish /ˈajəliSH/ adjective Able to apply Agile values and principles to execute a plan quickly and easily. "The team worked in an Agilish way to meet their deadline in spite of unplanned obstacles." Relating to or denoting a method of project management characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans. "Agilish methods apply Agile concepts to different types and sizes of projects." The World Agile Assumes The Agile Manifesto was written in 2001 by seventeen practitioners who believed — rightly — that there was a better way to build software. The values and principles they articulated have stood the test of time. Incremental delivery, collaboration, responding to change, working software over documentation — these ideas work. The evidence is overwhelming. But the Agile Manifesto was not written with a Program Management Office in the room. It was not written with a heavily regulated ...

par·kin·son's law noun — "Work expands so as to fill the time available for its completion." — C. Northcote Parkinson, The Economist, 1955 In a previous post I wrote about Ron Jeffries, the co-founder of Extreme Programming and the man credited with inventing story points. One of Jeffries' core arguments — and the reason he eventually grew to regret story points — is that estimation tends to become a target, and once it becomes a target it stops being useful. Teams stop working toward delivering value and start working toward hitting a number. There is a law that explains exactly why this happens. It has been around since 1955 and it has nothing to do with software. But it describes software teams perfectly. What Is Parkinson's Law? Cyril Northcote Parkinson was a British naval historian who published a satirical essay in The Economist in 1955. In it, he observed something that anyone who has worked in a large organization will immediately recognize: w...

Estimating Software Projects is a Conundrum. co·nun·drum /kəˈnəndrəm/ noun — a confusing and difficult problem or question. The problem to solve is this: when you work at a company that has a Program Management Office (PMO) and/or is highly regulated, the business partners that sponsor and regulate projects expect accurate estimates for the work you are going to do. They also expect evidence that you are delivering on those estimates. At the same time, large projects tend to take a long time. It may not take long to deliver working software into production if your team is good, but to "finish" a project — such as a re-platform or a large scope of work — can take months if not years to complete. And over the course of that time, things change. Business priorities change. Technologies change. Your budget will change. The people on your project team will change. The longer a project needs to run, the bigger the challenge with estimating and delivering the software that...

I have had many discussions and some arguments about story pointing and project estimating over the years. One day I got so frustrated with a colleague that I decided to go to the source. The cool thing is that I think I found the source! Ron Jeffries is credited with being the inventor of story points. Ron is one of the original seventeen signatories of the Agile Manifesto and a co-founder of Extreme Programming (XP). I think this video is fantastic and must-watch for anyone trying to figure out how to estimate Agile projects with any kind of accuracy The Genesis of Story Points I don't usually so this, but I also don't usually get authenticate message like this from the horse's mouth either. I have included main points of the transcript below. I don't promise to tell the story the same way every time, but it's worth noting that on the first XP project we started with a large-scale estimate. As it happened, we had a complete set of storie...

After many races, lessons, and retrospectives, the Hare and the Agile Coach had become quite skilled at running their course. The path was simple. The flags were clear. The finish line was always in sight. But one morning a messenger arrived carrying a large stack of papers. “These,” said the messenger, “are requirements from the Project Management Office.” The Hare stared at the pile. Forms. Reports. Schedules. Approvals. “If we carry all of this,” sighed the Hare, “we’ll never reach the finish line.” The Agile Coach scratched his chin thoughtfully. “Governance is not the enemy,” he said. “But we must be wise about how we carry it.” The Tortoise slowly stepped forward. “Let me take the load,” he said. The Hare blinked. “That stack is enormous!” The Tortoise smiled. “I may not be fast,” he said, “but I am strong. And I am patient.” So the team made a plan. The Hare and the Coach would run the course, ...

An Agile fable about cleaning the path before it slows everyone down. One evening the Hare and the Tortoise visited the wise old Owl. They had been running many races and placing many flags. But the path had become cluttered. Old flags leaned sideways. Some had fallen over. Others pointed in the wrong direction. The Hare sighed. “This course used to be easy to follow.” The Tortoise looked at the tangled flags. “Now it is confusing.” The Owl blinked slowly. “You have been adding many improvements,” he said, “but you have not been cleaning the path.” The Agile Coach nodded. “That’s true.” “So what should we do?” asked the Hare. “Spend some time repairing the course,” said the Owl. The next day the team worked together. They removed old flags. They replaced broken ones. They straightened the path. By afternoon the course was clear again. The Hare ran the race once...

An Agile fable about keeping the race manageable. One afternoon the Hare and the Tortoise were planning their next race. The Agile Coach had drawn a simple path across the field with four flags marking the milestones. “Run to each flag,” he explained, “and you will reach the finish quickly.” Just then the Fox appeared. “What a wonderful race you’re planning!” he said. “Thank you,” replied the Hare. “But wouldn’t it be even better,” said the Fox, “if the race also included a hill climb?” The Hare looked interested. “Well…” “And perhaps a river crossing,” continued the Fox. “That might be fun,” said the Tortoise. “And maybe,” the Fox added excitedly, “a maze through the forest, a bridge over the stream, and a loop around the mountain!” Soon the race path was covered with new lines and twists. The flags were moved again and again. The starting time came and went. Finally the Hare sighed. ...

An Agile fable about learning after the race. After the great rematch race, the Hare, the Tortoise, and the Agile Coach became something of a team. They trained together, ran together, and occasionally celebrated together. But one morning the Hare arrived at practice looking frustrated. “I keep getting faster,” he complained, “but sometimes things still go wrong. Yesterday I ran the course and tripped over one of the flags!” The Agile Coach nodded thoughtfully. “That happens,” he said. “Speed is important, but learning is even more important.” The Tortoise tilted his head. “What do you suggest?” “A retrospective,” said the coach. They sat together beneath a large oak tree and began discussing the last race. “What went well?” asked the coach. “The flags helped me stay focused,” said the Hare. “And the spacing made the course easy to follow,” added the Tortoise. “Good,” said the coach. “Now, what ...

A modern fable about speed, humility, and incremental delivery. After losing the famous race to the Tortoise, the Hare was devastated. For days he replayed the moment in his mind—how he had sprinted ahead, grown overconfident, taken a nap, and awakened only to see the Tortoise crossing the finish line to thunderous applause. The Hare had always been fast, but now he realized something painful: speed alone was not enough. Determined to redeem himself, the Hare hired an Agile coach—another hare known throughout the forest for helping teams achieve their goals. The Agile coach listened patiently as the Hare described the race. “You were faster,” said the coach, “but you didn’t manage your progress. Let’s train for a year and build a better approach.” For the next twelve months they practiced every day. The coach taught the Hare how to break a long journey into smaller goals, how to measure progress, and how to ce...