An Agile Retrospective on the Project That Broke Me (Part 2 of My 25-Year Look Back) Part 1 is here
I’ve carried this story in my head for years, sharing bits and pieces during trainings, almost like a form of group therapy. But now, I’m putting it all down — in full detail — in the hope that telling it will finally help exorcise this demon once and for all.
The Project That Had It All
At the peak of my consulting career, I was hired to manage a full system replacement project. It was exactly the kind of work I loved — high stakes, delivery-focused, and I had real autonomy. The rules were simple: deliver the project on time and within budget. How we got there was up to me.
We built a blended team:
- 3 vendor teams focused on platform development
- 1 internal team on data migration
- 1 internal team for legacy app integration
We used Scrum at the team level but didn’t buy into big “scaling” frameworks. Our scaling model was simple — fit-for-purpose, what I jokingly called “The Dan Model.” It worked.
We weren’t doing continuous releases — this was a full system replacement, so we built to critical mass and planned quarterly internal releases for integration testing and UAT. Sprints were three weeks. We were tracking scope, burnup, quality, and budget. And we were delivering.
What made this project special wasn’t just the success metrics — it was the team.
When I arrived, IT was ranked 13th out of 13 departments in job satisfaction. The team was burnt out. Distrustful. Beaten down. I introduced daily scrums — and I don’t mean standups for show. I mean functional accountability every single day. People either stepped up or opted out. A couple of lifers left early. That cleared the way for the rest of the team to thrive.
I wasn’t a developer — not unless you count Fortran and Pascal in college — but I had worked with dev teams for 20 years. I knew how to ask the right questions, push through the noise, and translate tech into business risk, cost, and timing.
My approach was simple:
If you brought me a problem, bring me the options.
I’d keep asking questions until we had a shared understanding (and they dumbed it down for me), and we’d make decisions together.
That collaboration built trust. That trust built momentum. And that momentum built morale.
A year later, under this new working model and culture, we ran the culture survey again. IT ranked #1 in job satisfaction. That’s still one of the things I’m most proud of in my career.
So when I accepted a full-time role to stay and lead the effort through delivery, I thought I’d found my forever job.
And then it all fell apart.
Then the Executive Interference Started
Halfway through the project, we’d built enough functionality for our first external release. Our SMEs — now product owners — ran full UAT and gave the green light. We were ready.
And then everything changed.
Our executive sponsor, the CFO, retired. Her replacement, a director from inside the org, was promoted. She hadn’t been involved in the project to that point. She hadn’t seen the progress, the process, or the results. But suddenly, she was in charge.
Whether it was fear, pressure to prove herself, or some performance-based incentive, she made her first big move: she brought in one of the Big 3 consulting firms to audit the project.
They used standard PMI waterfall audit criteria. Of course we failed.
- No task-level project plans
- No formal risk register
- No “stage gate” documentation
We weren’t following waterfall. We weren’t supposed to. We were delivering.
At first, I thought it was a joke. I actually laughed with my boss, the CIO. “Of course we failed — we’re not doing any of that.”
But it wasn’t a joke. The new CFO was serious. And my boss, a peacekeeper by nature, agreed to “fix” it.
The Collapse Begins
We hired a full-time project manager to build all the artifacts. Then another. They couldn’t keep up — the teams were moving faster than the paper pushers could document.
Now we were over budget.
Still delivering, still strong team culture — but now we were burning money to make the project look right on paper.
I did everything I could to shield the team from the noise. But it started seeping in. Confidence wavered. Fear and disillusionment replaced momentum.
The CFO refused to allow our first external release — too risky, she said. She wanted the entire system rebuilt and replaced in one big bang. And we all know where that leads.
We kept building. Kept auditing. Kept documenting.
Six months later, we had a second formal audit. Again:
- No mention of working functionality
- No recognition of low defect rates
- No acknowledgment of scope control
Just red marks on artifacts.
In that meeting — with just me, the CEO, CIO, and CFO — I felt my chest tighten. First time in my life I had heart palpitations. Tears welled up. I faked a production issue and left the room.
I resigned two weeks later.
And Then It All Fell Apart
After I left, the project kept going — and kept unraveling.
The budget tripled.
The system was never released.
Blame flew in every direction — the vendor, the team, probably me too.
It didn’t matter. The real damage had already been done.
We had a team that believed in the work. We had working software. We had trust.
All of it destroyed — not by failure, but because we were succeeding in a way leadership didn’t understand or trust.
Unfortunately, this is not the only time an executive sabotaged one of my projects. It happened too often. This was just the most egregious — and the most painful.
Aftermath
I resigned two weeks later.
Six months after that, I moved to Hawaii and spent five years delivering Agile training. I used those years to share my experience, help others avoid the same mistakes, and remind myself why I ever believed in Agile in the first place.
I needed that time.
Time to heal, to reflect, and to reconnect with the work on my own terms.
It took five years before I felt ready to step back into a client environment again.
What’s the Advice?
After my last post, Al Shalloway asked what advice I’d give others. And in this case? I’m still not sure.
We educated the execs early. We got buy-in. We delivered results.
Maybe it was just bad luck.
Maybe I missed a red flag.
Maybe success only survives when it stays under the radar.
I guess this is the risk we take when we try to be change agents. We don’t just push process — we challenge comfort, power, and habit. I know I’m not alone in facing this kind of resistance. Some days, I wish I’d taken the simpler path — changed code, not people.
Thanks for sharing the burden I’ve carried for the last decade.
No regrets!
