We Called It Agile, Then We Buried It
| How a two-minute manifesto turned into a certification economy, and what it costs the teams still living inside it. Somewhere along the way, a simple idea got heavy. It started light. A few people sitting close together, talking often, shipping small pieces of software, getting feedback fast. If something was wrong, they changed direction the next week, not the next quarter. People felt like they had some control. Work moved. The customer was happier. Then the idea grew up. And growing up, in this case, meant getting complicated. In 2001, seventeen people met at a ski lodge in Snowbird, Utah, and wrote the Agile Manifesto. Four values. A page so short you can read the whole thing in two minutes. That was the seed. Look at what grew from it. Certifications appeared. Frameworks appeared. Coaches, badges, two-day courses, ladders of titles. Everyone had their own flavor of Agile, and most of them were selling it like a product. The lightweight idea turned into a system. The system turned into a business. Today a lot of teams proudly say they are "Agile." But what they actually run is a long list of roles, rituals, and reports. People do not collaborate better. They follow the process and hope it works. The two-minute page became a certification economy. And somewhere in that trade, the point quietly left the room. Sound familiar? At some point we confused Agile with speed. Not learning. Not adapting. Just delivering faster. But speed was never the point. Feedback was. Adaptation was. Small, safe failures that teach you something before they cost you something. Speed is what happens when that whole thing works. It is the result, not the goal. And here is the part that stings... Chasing speed actually slows you down. You build the wrong feature. You skip validation. You ship something nobody asked for. Then you spend three weeks fixing what one honest question would have caught in the first week. A team moving fast without learning is just automating its worst decisions, very efficiently. You can watch it happen. The burndown chart looks beautiful. Every sprint closes on time. The dashboard is green. And yet the product drifts further from what the customer actually needed, week after well-measured week. Everyone is busy. Nobody is sure it is working. Speed is what a healthy process produces. It is not something you can demand directly. So when someone says "we need to go faster," the useful answer is rarely a new sprint cadence. It is usually a better question asked earlier. The same hunger shows up right at the start, especially with people leading their first big project. They try to plan everything before they begin. Every step mapped. Every risk predicted. Every detail signed off before a single thing ships. It feels responsible. It feels safe. It is neither. Real projects do not behave. People change their minds. Priorities shift on a Wednesday for reasons that made no sense on Monday. A blocker shows up that no plan saw coming. The more time you pour into perfecting the plan, the longer you go without the one thing that actually moves a project forward, which is a small result people can see and touch. It is a bit like trying to draw the perfect map of a road you have never driven. You will get half the turns wrong, and you will only find out once the car is moving. The plan is not the project. Movement is. The embarrassingly small thing that worksSo what does work? Something almost too small to brag about. Deliver one piece. Quickly. Low risk. Let people see it work. Each small win buys a little trust, and trust, not velocity, is the real currency of any project. Momentum follows trust. Never the other way around. Then you do it again. And again. And the belief in the outcome grows with every visible step. You still adjust as you go. You still plan. But you plan enough to start, not enough to stall. If you are leading your first project right now, here is the whole method, with no certification required:
Notice that none of this needs a framework. It needs a clear mission, a real conversation, and the courage to deliver something imperfect on purpose. Before you blame the manifestoWhen Agile does not work, it is tempting to say "Agile is not a good fit for us" or "Agile failed in our organization." Most of the time, that is not what happened. We failed to understand it. We wanted the benefits without the mindset. The outcomes without the culture. The speed without the trust. So we took something light and flexible and slowly turned it back into the rigid system it was built to replace. We added roles, rules, rituals, and reports. We tried to measure creativity with a velocity chart. We swapped real collaboration for a standup script that everyone recites while staring at their shoes. And then we wondered why teams felt burned out and disconnected. If Agile is not working on your team, the problem is probably not the manifesto. It is the mirror (yes, you got it). That is harder to hear than "the framework was wrong," because a framework you can swap. A mirror you have to face. And facing it is cheaper than it sounds. It does not mean firing the coaches or canceling every ceremony. It means asking, honestly, which of those rituals still creates trust and which ones only create the appearance of work. Keep the first kind. Quietly retire the second. The way out is the same size as the way inThe good news hiding in all of this is that the fix is small. The same size as the original idea. You do not need a new methodology. You do not need another certificate on the wall. You need a clear mission, an honest conversation with the people doing the work, and one low-risk piece you can deliver before the end of the week instead of the end of the quarter. Pick the small thing. Ship it. Earn the trust. Repeat. And the next time someone in the room says "we need to be more Agile," it is worth pausing and asking what they actually mean. Do they want the team to learn faster? Or do they just want it to move faster? Because those are two very different projects. And only one of them tends to arrive. |
Posted on: June 24, 2026 01:00 AM
| Permalink |
Comments (0)
What Happens to Your Lessons Learned After the Meeting Ends?
| The finding gets filed, named, and forgotten. The owner, deadline, and sign-off that turn a lessons learned note into a fix the next project actually uses. Have you ever left a lessons learned session feeling like something actually changed? I have sat through ninety-minute reviews where people took turns listing complaints dressed up as feedback. I have also been the one facilitating, trying to keep the energy up while watching everyone mentally check out. You write the document. You give it a name. You file it. And somewhere in the back of your head, you already know nobody is opening that folder until the next project. Which will repeat the same mistakes anyway. So we check the box. And we move on. Or? Maybe not? What do you do? The problem is not that we skip the review. Most teams run one. The problem is what we think a review is supposed to do. Chris Argyris, working with Donald Schön, described two types of learning that I think explain exactly why most post-project reviews fail. Single-loop learning fixes the error. Double-loop learning asks why the system produced the error in the first place. Argyris used a thermostat as the example. A thermostat set to 21 degrees does its job perfectly well. Room gets cold, it kicks the heat on. Room warms up, it shuts off. It corrects the gap, over and over, all day long. What it never does is ask whether 21 is the right number. Or whether someone left a window open. That is single-loop. Reliable, tireless, and completely blind to its own assumptions. Most lessons learned sessions live exactly there. "The vendor was late." "Communication broke down in week four." "The scope changed too many times." All true. And almost useless for stopping the same thing from happening again, because they describe what happened without ever asking what in the process allowed it to happen. The shift from symptom to system is the whole game. Why did they use the wrong specs? Keep asking.Let me make this concrete with something that will probably sound familiar. An integration fails testing for two weeks, late in the project, when everyone is already tired. The typical review lands on: "The development team used the wrong specifications." The fix? "Make sure everyone uses the right specs next time." That is not a fix. That is a wish. A diagnostic review keeps pulling the thread. Why did they use the wrong specs? Because the updated version was filed in the wrong place. Why was it in the wrong place? Because nobody owns document control on this team. Why does nobody own it? Because we never assigned it. By the fourth or fifth why, you are no longer talking about a developer who slipped up. You are talking about a gap in the process that will come back, in a different costume, on the next project. That is the difference between a lessons learned document and an actual lesson. The room fills with whatever you do not put on the tableWhen a team walks in without shared data in front of them, what fills the room is emotional recall. People remember the most recent frustration. They remember the personality clash, not the structural failure hiding behind it. And almost nobody is going to criticize a process their own manager designed. I have seen this dynamic kill good reviews. The room wants to be honest. But honesty without data is just venting. The way to change this is not complicated, but it asks for discipline before the meeting even begins. The project leader puts three objective numbers on the table.
This is where the lesson goes to dieThen there is what happens after the meeting ends. And this is where I think most organizations quietly give back everything they just worked so hard to find. The finding gets written up. Someone attaches it to a SharePoint folder. The folder gets a name like "Lessons Learned 2024 Q3." And the next project kicks off without anyone reading it, because nobody made reading it mandatory. Nobody handed the fix to someone with the authority to actually change the process. It is like writing down that the smoke alarm needs a new battery, sticking the note on the fridge, and then wondering why you are buying a new smoke alarm two years later. The fix is simple. Every real finding from a review becomes a task with a named owner, a deadline, and a confirmation step at the start of the next project. Did the fix get applied? If not, the project leader needs executive sign-off to proceed with the known gap still open. That small friction is the whole mechanism. It closes the loop. Without it, you are collecting insights. Not learning. Three questions. Almost nobody answers all three.The organizations that actually get better over time are not the ones running the most reviews. They are the ones that treat every review as a conversation between the project that just ended and the one about to begin. What did we learn? Who owns fixing it? Is the fix in place before we start again? Three questions. Most teams never answer all three. Maybe worth sitting with that for a minute. What did your last post-project review actually change? |
Posted on: June 22, 2026 01:00 AM
| Permalink |
Comments (1)
The Longest Project You Will Ever Manage
| Applying baselines, risk logs, and stakeholder maps to the one project that follows you everywhere. I know... Most project managers can produce a stakeholder register, a risk log, and a full set of baselines for a client initiative. Far fewer have ever built the equivalent for the longest project they will ever run, which is their own career. The neglect is rarely deliberate. It follows from an assumption that sounds reasonable and so goes unexamined: do good work, and the work will speak for itself. Deliver the project, protect the budget, keep the sponsor calm, and the next role arrives on its own. That assumption misreads what a promotion is. A promotion is not a reward for work already completed. It is a forward-looking decision about what a person can be trusted to carry next. Organizations advance people on expected future contribution, not on a record of past delivery alone. Peter Drucker described this gap in "Managing Oneself." His argument was that knowledge workers must take responsibility for their own development and positioning, because no employer will do it reliably on their behalf. The discipline a project manager applies to external work is precisely the discipline missing from the internal one. Every project begins with a baseline. Career management should begin the same way, with an accurate reading of current capability. The difficulty is that self-assessment is one of the least reliable inputs available. Most people think they know what they are good at. They are usually wrong. That observation, also from Drucker, is the reason structured external feedback exists. The entire premise of 360-degree feedback is that individuals tend to overrate their interpersonal strengths and underrate the specific competencies that the next level demands. The gap between how a person sees their own performance and how the surrounding room reads it is where careers most often stall. The correction is to replace self-assessment with observation. Two questions, put to a manager, a trusted peer, and a sponsor, are usually enough. The first asks what single contribution saves the most time or cost, which identifies the strength worth being known for. The second asks what capability would be missing if the person were handed a project twice the size of their largest to date. That answer is the single development priority. Not a list of courses. One skill. The conventional sequence, earn the title and then perform the role, is reversed in practice. Capability is demonstrated first, and the title formalizes a contribution that is already visible. This is how competency-based advancement actually operates, since organizations promote against observed behavior rather than stated potential. The mechanism is available in most environments. There is usually an unowned problem one level above the current role: an unnamed risk on an adjacent project, a process everyone complains about and no one owns, a review that keeps being postponed. Taking responsibility for one of these, and then recording the outcome in measurable terms, converts effort into evidence. Hours recovered, a risk closed before it materialized, a delay that did not happen. Enthusiasm does not advance careers, but measured evidence does. When the conversation about a next step finally takes place, the case rests on a record rather than a request. That conversation introduces a second factor, one that operates independently of competence. Advancement decisions are typically made in discussions the candidate never attends. The relevant question is what the people in that discussion actually know about the contribution. Quiet, effective delivery carries a specific liability. Work that succeeds without visible strain is often read as work that was easy, so the better the firefighting, the more invisible it becomes. The correction is not constant self-promotion. It is accurate, occasional communication of impact to the people who shape advancement decisions, stated as fact. A risk identified in March that avoided a defined cost in June is a contribution to a record, not a performance. Peer and cross-functional advocacy carries unusual weight here. When a finance manager or an engineering lead represents a person's value in that room, the endorsement is more credible than any self-description. Management research on sponsorship, as distinct from mentorship, describes this directly: advancement accelerates when established figures actively speak for a person in their absence. This reframes the question that early-career project managers most often ask. Instead of focusing on when an organization will grant a promotion, the more productive focus is on which parts of the next role a person is already performing, visibly and with evidence. Understood this way, a promotion is largely administrative. It is the formal record catching up with a contribution that was established months earlier. Your career is a project with no defined end, no handover, and no closing phase. It still requires a baseline, one clear development priority, documented evidence of contribution, and a map of the people who will discuss it when it matters. The discipline already exists in every competent project manager. It only needs to be turned inward. |
Posted on: June 15, 2026 01:00 AM
| Permalink |
Comments (0)
Project Manager: Stop Waiting for Good Work to Speak for Itself
| Most project managers who stall in their careers are not bad at the job. They are just invisible. And the frustrating part? The work is there. The crises averted, the schedules held, the stakeholder conflicts resolved before they escalated... it all happened. It happened quietly, and that is exactly the problem. Quiet is the enemy of career growth. The Myth That Good Work Speaks for Itself There is a belief a lot of us carry, often without noticing it, that excellent work will eventually be recognized. That the right people will connect the dots. Those results open doors on their own. They don't. Not automatically. The organizations we work in are complex social systems, and senior leaders see only a fraction of what you actually do. They catch the status report, the governance meeting, maybe a quick corridor update. Everything in between, which is usually where your real value lives, stays invisible. Credibility is not a reward for hard work. It is an asset you have to build, document, and position strategically. The difference between a PM who advances and one who doesn't is rarely competence. It is almost always how well that competence reaches the people who make decisions about careers. The vendor who almost derailed the timeline. The budget risk you caught three weeks early. The scope conflict you resolved before it hit the steering committee. From where your executives sat, everything looked green. That is excellent leadership. But also, when you shield the organization from chaos, which you absolutely should, the side effect is that your most impressive work leaves no trace. The executive sees a smooth delivery and assumes it was a smooth project. You have to document the storm, not just the calm weather. A practical way to do this is what I call the CAV Story, short for Challenge, Action, Value. For every major crisis you handle, write three things down: what was about to go wrong and how bad it would have been, what you specifically did to prevent it, and what the organization saved as a result in time, money, or strategic outcome. Not a long document. A few lines. Something you can pull out when it matters. "We were facing a six-week delay and a $500K penalty. I convened the team and the vendor for a focused session, negotiated a rollback, and we held the original launch date." That is a CAV Story. Career ammunition, instead of disappearing into the noise of the next sprint. I spent years thinking delivery was enough. It isn't. Getting Your Results in Front of the Right People Evidence alone is not enough. You need it to travel. The steering committee meeting is not just a governance checkpoint. It is your most valuable stage, and most PMs use it only to report status. The ones who advance use it to demonstrate judgment. There is a real difference between saying "we have a vendor risk" and saying "we identified a vendor risk early and here is how we contained it." One makes you a reporter. The other makes you a strategist. Same situation, completely different impression. The same logic applies to how you write your executive updates. Filter complexity for your team. Elevate outcomes for leadership. Frame your wins in the language executives actually care about: time, cost, and strategic delivery. Keep it short. Make it land. And don't overlook the people around you. A colleague or sponsor who mentions your contribution in a cross-functional meeting does more for your credibility than anything you say about yourself. That kind of third-party validation is hard to manufacture and easy to earn, if you ask for it clearly and right after the moment happens. "I think I'm ready for the next role." That framing puts you in a weak position from the first sentence. You are asking for something. They are deciding whether to give it. Reframe it entirely. Walk into that conversation with documented evidence, your CAV Stories, the complexity you managed, the financial stakes you controlled, and make the case that the organization has a gap you are already equipped to fill. You are not asking for a title. You are proposing a solution to a real problem, and you happen to be the most logical person to own it. That shift changes the whole dynamic of the conversation. This is not self-promotion. It is strategic alignment of your track record with an organizational need. Senior leaders feel the difference immediately. The work was always there. Now make sure the story is too. What would change in your next career conversation if you walked in with three documented wins instead of a feeling that you deserved more? |
Posted on: June 08, 2026 01:00 AM
| Permalink |
Comments (1)
The Real Reason Your AI Project Is Going Nowhere
| Walk into any leadership meeting today, and someone has just come back from a conference. There was a demo. It looked impressive. And now there's pressure, that particular kind of pressure that doesn't have a deadline yet but already feels urgent, to "do something with AI." Budgets get approved. A team gets pulled together. The mood in the room feels like the beginning of something. Then the months pass. The proof of concept works fine in the controlled environment where everyone is watching. But moving it into production becomes a slow grind nobody prepared for. Integration stalls. The data your team needs turns out to be locked behind a permissions process that takes six weeks. Deadlines shift. The energy fades. And eventually, the project gets reframed, delayed, or quietly shelved. The official explanation is usually something like "AI turned out to be more complex than expected." That explanation is polite. And incomplete. Here's what the retrospective usually won't say: the algorithm was almost never the problem. The models being used today are advanced, well-tested, often open source. What breaks an AI initiative is whether the organization's data is accurate, accessible, and integrated, what people in this field call "data readiness." Think of it like a football pitch full of holes. You can have the best strikers, the most expensive coaching staff, the smartest tactics... but if the field is unplayable, the game is already lost before kickoff. In AI projects, those "holes" show up in three specific places:
If your AI project collapses, the cause is almost always one of these three. Not the algorithm. The foundation. And here's the uncomfortable part: most people inside the project know this from day one. Data is messy. Integration is unclear. Permissions will take forever. But because these problems feel unglamorous next to shiny demos and impressive model benchmarks, they get pushed aside until it's too late. Where Project Managers Actually Need to Step InManaging an AI project does not mean becoming a data scientist. You don't need to build pipelines or design neural networks yourself. But you do need to take ownership of whether the foundations are in place before the project is allowed to move forward. That governance responsibility gets handed off to "IT" more often than it should. And when it does, nobody really owns it. Here's what actually stepping in looks like: Make data readiness visible. Create scorecards with four or five clear metrics: completeness of fields, error rates, duplication levels, how fresh the data is. Simple enough that anyone can read them in a status meeting. And then enforce them. Projects with red scores don't advance, no matter how compelling the demo was. Build data checkpoints into your stage gates. Stage gates are the structured review points where a project must prove it's ready before moving to the next phase. Extend them. At discovery, require that datasets are mapped with clear owners. At feasibility, demand profiling results. At pilot, require automated checks running for at least 30 days. At scale, 90-day stability with monitoring and rollback plans. This stops enthusiasm from skipping the boring but necessary preparation. Make ownership real, not decorative. Everyone agrees with "data ownership" as a concept, until actual responsibility is required. Be explicit about who approves schema changes, who checks quality daily, who enforces the gates. And tie those roles to budgets and performance reviews. Without accountability, ownership is just a word on a slide. Think across the portfolio, not just the project. One failed AI initiative is painful. Ten failed initiatives across different parts of the organization, all for the same underlying reason, is something else entirely. Publish readiness heatmaps across domains. Map dependencies between initiatives. Link funding to readiness scores. If one part of the organization is consistently not ready, leadership needs to see it. Monitor after go-live. Passing a gate is not the end of the job. Data drifts. Systems change. Business definitions evolve. Build monitoring into your definition of done, from the beginning. NASA lost the Mars Climate Orbiter in 1999 because one team used metric units and another used imperial. A $125 million spacecraft disintegrated in the atmosphere because of a mismatch in definitions. The science was correct. The integration wasn't. AI projects carry the same fragility. Brilliant models cannot survive poor definitions, weak ownership, or inconsistent systems. And the people best positioned to prevent that fragility are not the data scientists, not the vendors... they're the project managers and PMOs, the ones trained to make invisible risks visible and hold the line when pressure says to move faster. So here's the question worth sitting with honestly: if your AI project stalls this year, will it be because the model underperformed, or because the data was never ready to begin with? That's not a philosophical question. It's an operational one. And answering it before the kickoff might be the most valuable thing a project manager can do right now. |
Posted on: June 01, 2026 01:00 AM
| Permalink |
Comments (0)
