Today, I’m going to talk about two different companies I’ve worked with—one that took a slow and measured approach to agile adoption, and another that took a rapid, all-at-once approach. We’ll look at the results of both and what lessons can be learned.
Before I dive in, a quick introduction—my name is Paul Wynia. I’ve worked full-time for several companies and also run my own consulting firm, working primarily with larger-scale organizations. While I’ll focus on two specific case studies today, my experience spans multiple industries, giving me insight into why some companies successfully adopt an agile mindset while others flounder and turn "agile" into a dirty word.
The Companies: Irdeto and Teradata
The two companies I’ll be discussing are:
- Irdeto: A content delivery and security company.
- Teradata: A database and analytics company.
Both companies have been around for decades—50 years for Irdeto and 40 years for Teradata—which is unusual in today’s fast-moving digital landscape. They are both global, with teams distributed across multiple locations. They each had long development cycles—two years for Irdeto and 18 months for Teradata—which was one of the key drivers for their agile transformations. Facing disruption in their industries, they needed to increase their rate of delivery.
Why Agile Fails in Some Organizations
We’ve all seen it happen—projects hit roadblocks, teams struggle, and "agile" gets a bad reputation. The number one reason? Culture. Many organizations attempt to adopt agile without addressing the underlying cultural shifts needed for it to succeed.
You may be familiar with the culture iceberg—the idea that visible cultural traits (like process changes) are just the tip of the iceberg, while the real challenges lie beneath the surface. Culture eats strategy for breakfast, and if it’s not addressed, agile transformations run aground.
Case Study #1: The Slow Rollout at Irdeto
Irdeto took a slow, evidence-based approach to agile adoption, ensuring strong senior-level engagement and addressing cultural issues as they arose.
Starting Small
The agile transformation at Irdeto was driven by Henrik, the SVP of Product. (For privacy, this isn’t actually Henrik—this is just a handsome guy in a suit.) Henrik had seen agile work well at previous companies and wanted to bring it to Irdeto.
He worked with the CEO to launch a pilot project in Seattle with two teams focused on DRM solutions. They initially hired a Scrum Master—who was fired within two days. Then they brought me in. Lucky me!
The Pilot Approach
We started with the basics—two-week cycles, structured planning, reviews, and retrospectives. We followed a disciplined approach while continuously inspecting and adapting.
After six months, the pilot was a success. We saw increases in productivity, reductions in cycle time, and other key improvements. Based on this success, Henrik decided to expand agile to additional teams, starting with the Dutch headquarters.
Scaling Up
Rather than rolling out agile company-wide, we followed the same pilot approach at the headquarters—starting with a single product group of about five or six teams. Again, after six months, we saw success and expanded further.
Over the next two years, I traveled across the globe, working with teams in Paris, India, Beijing, and even Mankato, Minnesota (not quite as exotic as Paris, but still part of the journey). In each location, we spent months building communities of practice, identifying Scrum Masters, training Product Owners, and ensuring each office was ready before scaling further.
Results
In San Diego, we took a project originally estimated at two years and completed it in six months. It was Irdeto’s first true end-to-end agile project, spanning five locations and two external vendors. The first customer deployment generated a $10 million ROI. Henrik was pleased, and agile was viewed as a success.
Case Study #2: The Rapid Rollout at Teradata
Teradata took the opposite approach—implementing agile across the entire organization at once. The rollout was led by Sarah (not actually Sarah, but again, we’re protecting identities). She oversaw 150 teams across seven locations and wanted them all to go agile immediately.
Challenges of Rapid Rollout
Key issues with this approach included:
- Only two internal coaches for 150 teams.
- Scrum Masters and Product Owners acting as proxies rather than fully trained practitioners.
- Little attention to culture.
- Agile quickly became a "dirty word" within the company.
Flawed Metrics
To measure agile adoption, they used a maturity model assessment. Teams were given numerical scores (e.g., 4.2, 3.6, 2.6), but these numbers provided no real insight. Managers simply used them to target "underperforming" teams, increasing pressure without support.
When I joined, leadership asked me to achieve a 10-20% increase in all teams' scores over the next year. But what did that even mean? Nobody could define what success looked like.
Turning Things Around
Recognizing the problems, I introduced several improvements:
- Big-room planning.
- Targeted training.
- More direct coaching (though still only six coaches for 150 teams).
- Leadership coaching to engage executives.
We also scrapped the old health check model and replaced it with a team-driven health check—no scores, no manager oversight, just honest self-assessment. This shifted the focus from external judgment to internal improvement.
Starting a Lighthouse Project
We launched a lighthouse project—a dedicated three-month agile implementation for two teams, with intensive coaching and executive engagement. While we couldn’t replicate this across all 150 teams, it allowed us to establish best practices tailored to Teradata’s culture.
Fast vs. Slow: The Verdict
So, which approach works better?
I won’t say that fast rollouts are impossible, but they require significantly more support—more coaches, stronger leadership engagement, and a deep understanding of company culture.
Key lessons:
- Don’t ignore culture. The culture iceberg will sink you if you don’t address what lies beneath.
- Ensure leadership engagement. Executives must show up to demos, participate in planning, and model agile behaviors.
- Use evidence-based approaches. Track real progress, not arbitrary metrics.
- Take your time. Agile transformations aren’t about speed—they’re about sustainability.
We don’t want a Titanic-style agile transformation. We want a successful, sustainable journey. So, my recommendation? Take it slow, pay attention to culture, and make sure you’re actually moving the needle.
Thank you.