by Daniel Tousignant | May 15, 2025 | Agile
An Agile Retrospective on the Project That Broke Me (Part 2 of My 25-Year Look Back)
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!
by Daniel Tousignant | May 1, 2025 | Agile
This is the first of two 25-year retropsectives.
I have decided to step off the Agile certification path both in training and in consulting. What began as a passion for improving project performance somehow turned into selling certifications for other companies.
The new me:
No certifications to maintain. No frameworks to promote. No need to toe the line. Just decades of lived experience and a clear view of how far we’ve come—and how far we’ve strayed.
Before Agile, I spent a solid ten years as a traditional project manager. I managed scope, schedules, and stakeholders with the precision expected of someone holding a freshly minted PMP certification. Back then, project management meant command and control, and the PMBOK—180 pages of structured guidance—was gospel.
Then I got assigned to a project that didn’t follow any of that.
In June of 2000, I was asked to be the Program Manager over a Scrum project—a term I had never even heard used for a project before. Honestly, I thought “Scrum” was an acronym. Nobody had explained otherwise.
So they put me through a one-day Scrum Master training.
The instructor—one of Scrum’s original authors—jumped straight into the principles, the ceremonies, the roles. It was fast, high-level, and clearly aimed at getting people “ready enough” to be sent back into the wild. At one point, I raised my hand and asked, “How do you track and manage risks?”
His response:
“What are you? One of those PIMPS?”
He meant PMP, of course. And I happened to be one.
I didn’t ask any more questions after that.
That one-day training wasn’t just for me—it was the entire onboarding process for other team members, too. People were getting shuffled into Scrum teams with just a few hours of exposure and a glossary of terms. There was a kind of blind optimism in the air, like this was all going to just work because it was different. Because it was Agile.
Apparently, that was enough to prepare me to be the program manager over 13 Scrum teams.
Here’s an actual line from the SOW dated June 2000:
“The project management capability of the project teams varies. Adherence and compliance to project management standards is inconsistent. The project management process in place involves a ‘hybrid’ Scrum methodology which, though appropriate for focused efforts, is not robust enough to handle the complexities of a multi-project, multiple vendor program such as the development of the eBusiness platform.”
This was 25 years ago—one of the earliest documented Scrum projects—and already the red flags were all there. The same cracks we tried to ignore would go on to inspire layers of frameworks and certifications rolled out 10–15 years later to “fix” what was obvious on day one.
Still, despite the early warning signs, it worked better than what came before. We delivered. The team was engaged. Feedback came fast. For the first time in my career, the process didn’t feel like a tax on the work—it felt like it was supporting it.
Over the years, I worked on just about every flavor of Agile you could name. I ran RAD and JAD workshops before Agile was even formalized. I lived through early XP, pair programming, and continuous integration before CI/CD was trendy. I saw Scrum implemented faithfully—and brutally misapplied. I watched teams blend Agile with Lean, with Kanban, with Six Sigma. Sometimes it worked. Sometimes it crashed and burned. But I kept showing up, kept adapting, kept trying to make it make sense in the real world.
But Agile was never a silver bullet. A one-day class couldn't replace leadership, experience, or the reality of navigating complexity. Everyone who stuck with it learned that sooner or later: the basics were easy. The rest? Not so much.
Eventually, I burned out. After years of chasing velocity, running back-to-back Agile initiatives, I stepped away and turned toward my other passion—carpentry and construction. With my project management background and hands-on skills, I was wired for it. I could plan the work and swing the hammer. But even the best planning can’t beat bad timing. The market cooled. Agile was heating up. And I found myself pulled right back into the world I’d just left.
By then, Agile had exploded.
Not just Scrum and XP anymore—now there were frameworks everywhere: DSDM, Crystal, Lean Startup, SAFe, LeSS, Spotify, Nexus. Everyone was marketing their own flavor of agility. Certifications became a cottage industry. Tools promised “Agile in a box.” Enterprises bought big-ticket transformations thinking they were buying agility itself. Agile stopped being a mindset and became a brand. It wasn’t a rebellion anymore—it was the establishment.
I spent the next decade riding that wave.
First came the training boom. I crisscrossed the continent, delivering sessions on Scrum, Agile fundamentals, and every hybrid model clients could dream up. Classrooms, boardrooms, conference halls—if you had budget and a whiteboard, I probably showed up with sticky notes and a marker.
Then came coaching.
Everyone wanted an Agile coach. Teams, departments, entire orgs were hiring people to help them “go Agile,” and I was there—working side by side with engineers, product owners, managers, and execs. I helped teams navigate reality, not just frameworks. And eventually, I found myself coaching leadership more than anyone else—because that’s where change either stuck or got quietly undone.
It was exciting, exhausting, and illuminating. I saw Agile implemented with integrity. I also saw it faked, forced, or forgotten the moment a deadline slipped or a reorg hit.
That arc culminated, for me, in SAFe—the Scaled Agile Framework. It wasn’t the villain, but it was a monument to how far Agile had drifted from its roots. Designed to help large organizations adopt Agile at scale, it often had the opposite effect: reintroducing complexity, rigid roles, and heavy process under the banner of “agility.” In many ways, it was waterfall in Agile clothing—but with more ceremonies, more certifications, and even more slide decks.
Then COVID hit.
Suddenly, everything was remote. I took the opportunity to move back to Hawaii—which was always the plan, it just got fast-tracked. Agile, by then, was starting to lose its luster. I spent a few more years coaching, but my focus shifted. Less on frameworks, more on leadership. Less on processes, more on people—especially at the executive level, where real change either takes root or dies on the vine.
But as remote coaching opportunities began to dry up, so did my appetite for staying in the game. The passion was still there—but the energy to keep fighting the same battles wasn’t.
So I shifted.
I stepped away from frameworks, certification tracks, and out of the box transformation plans. I stopped chasing change for other people and started investing in change I could shape with my own hands.
Now, I only work with organizations and people that want to improve project performance. Period.
I have diversified and made more of my hobbies (construction and real estate) a part of my business portfolio.
I wake up with purpose and got to sleep content.
And maybe that’s why the story of Agile still sticks with me. Because at its best, it was about building something real. Grounded. Human.
But Agile started as a rebellion. And like most rebellions, it eventually got absorbed by the very system it set out to disrupt.
Looking back now, with the freedom to be blunt and the benefit of distance, there’s a lot to unpack.
No Regrets!
