The Agile Executive

A Podcast on Agile in Large Organizations

Israel Gat and Coté

Eight episodes recorded between April 2009 and February 2010 for theagileexecutive.com, on applying agile inside large organizations. Guests include Clarke Ching, Dean Leffingwell, Jim Highsmith, Andrew Shafer and John Allspaw. Episodes four, six and seven are a mini-series on agile infrastructure recorded through the summer of 2009, before the word devops was in general use. RSS · archive.org

Episode titles and descriptions here were written by Claude from the episode transcripts on 2026-09-30. Dates, durations and the audio itself are the originals. The MP3s are remastered - loudness normalized with chapter marks embedded.

001

Theory of Constraints, Smaller Batches, and Selling Agile on Benefits, with Clarke Ching

2009-04-07 · 29:37 · mp3 · transcript · SRT · archive.org

Agile and Goldratt's theory of constraints overlap more than the agile literature admits: both start by breaking work into smaller batches, then look for whatever is slowing the flow. The case for smaller releases here is a cash argument rather than a quality one - forcing customers to rank every requirement up front shows how much of a backlog is genuinely low priority, with an agile rescue of a 150-person project as the worked example. Also a stretch on agile being harder work than waterfall rather than easier, a cereal-box analogy for selling benefits instead of ingredients, and the state of agile in Scotland against London.

22 chapters
  1. 0:00The First Episode, and Theory of Constraints
  2. 1:22Two Books, and Writing Them in a Recession
  3. 2:41Why Smaller Releases Need Less Cash
  4. 3:56Explaining Agile Without the Word "Agile"
  5. 5:11The Goal Rarely Comes Up in Agile Talk
  6. 6:26Agile Reduced to Two Things: Prioritize, and Deliver Small
  7. 7:57Why Smaller Chunks Cost Less
  8. 9:19An Agile Rescue of 150 People
  9. 10:39Cutting Scope by Ranking It
  10. 11:56Agile as a Promise You Can Keep
  11. 13:18Coaxing an Organization That Doesn't Want To
  12. 14:34Agile Is Harder Work, and Flossing
  13. 16:02The Cereal Box: Ingredients Versus Benefits
  14. 17:26Sell the Benefits, Then Admit the Work
  15. 18:43Getting Better Rather Than Getting Perfect
  16. 19:58When Builders' Goals Don't Match Customers'
  17. 21:19People Enjoying Their Work as the Actual Goal
  18. 22:41Minor Celebrity, and a Metaphor Hole
  19. 24:02The State of Agile in Scotland
  20. 25:20Quick Wins to Earn the Benefit of the Doubt
  21. 26:38Everyday Agile, and Making People Happier
  22. 27:53Where to Find Clarke Ching
002

RUP's Reputation, Agile in Maintenance Mode, and the PMO as Impediment, with Dean Leffingwell

2009-05-07 · 30:20 · mp3 · transcript · SRT · archive.org

An unusually frank post-mortem on the Rational Unified Process opens this one: RUP was tailorable in principle but shipped as a website too big to tailor, so it got used out of the box and misapplied as iterations inside a waterfall - and the blame lands on its authors, not its users. A RUP shop then turns out to be harder to move to agile than a waterfall shop, because it already iterates and hurts less. The rest is enterprise mechanics: agile on legacy code and maintenance releases, writing adapters for milestone gates instead of demanding their removal, and pulling IT operations in at release-planning boundaries.

23 chapters
  1. 0:00Enterprise Transition Work, and Where It Started
  2. 1:20Scaling Software Agility, and a Career Before It
  3. 2:43Requisite Into Rational, RUP, and the UML Authors
  4. 3:59RUP as a Box of Process Nobody Could Assemble
  5. 5:16Why That Was the Authors' Fault, Not the Users'
  6. 6:34A RUP Shop Is Harder to Move Than a Waterfall Shop
  7. 7:54Does Agile Work on Version 12 of Something?
  8. 9:21Scrum Fits Maintenance More Easily Than Greenfield
  9. 10:38Unsoldered Boards, and Moving Test Inventory Out
  10. 11:54Improving Code as You Touch It
  11. 13:13What Happens When Agile Hits the Rest of the Company
  12. 14:28How Much Depends on the Project Office
  13. 15:58Why "We're Agile, Drop Your Milestones" Loses
  14. 17:13Barbarians at the Gates
  15. 18:29Writing Adapters for Milestones You Cannot Remove
  16. 19:47Five Hundred People Take a Year or Two
  17. 21:02Operations People Discovering Agile
  18. 22:20Inviting IT to Release Planning
  19. 23:36IT Is an Easier Problem Than a Stiff PMO
  20. 24:53Communication as the Whole Mechanism
  21. 26:11Release Planning Is the Enterprise's Sprint
  22. 27:28Credibility Comes From Meeting Small Commitments
  23. 28:59The Feared Obstacle Is Rarely the Real One
003

Agile Roots, Agile Operations, & Agile Clouds

2009-06-19

The audio is lost. The title and description below are the original post's own words.

After having some coffee here in Austin, Israel Gat and I braved the Texas heat a little while longer to record a conversation about the recent Agile Roots conference, how Agile has spread in recent years, and some of the potentials that cloud computing plus Agile might bring. We go over the Agile Roots conference that Israel was currently at: one of the themes, Israel says, was a sort of retrospective on the Agile...

004

Agile Infrastructure, Always Ship Trunk, and ITIL as the Data Center's Waterfall, with Andrew Shafer

2009-07-17 · 37:38 · mp3 · transcript · SRT · archive.org

Recorded a year before anyone called it devops, this one asks what stands between agile and the IT department. The diagnosis is structural rather than cultural: change causes outages, operations wears the pager, so operations adopts heavyweight process to slow change down. The baseline capability proposed is rebuilding any server from bare metal - if you threw it out the window, could you get it back - with Puppet rebuilding sixty machines against two days of manual work. Then shipping one trunk rather than a build per large customer, feature flags as knobs during an incident, and whether ITIL is to the data center what waterfall was to development.

29 chapters
  1. 0:00Picking Up From a Coffee Shop in Austin
  2. 1:18What Stands Between Agile and IT
  3. 2:38Deployment as the Economics Problem
  4. 3:54Bigger Than Deployment, and Why Ops Resists Change
  5. 5:18Could You Rebuild That Server From Scratch?
  6. 6:56Building the Infrastructure Like the Application
  7. 8:13The JVM Upgrade Nobody Could Justify
  8. 9:31Why They Call Them Non-Functional Requirements
  9. 10:51One Trunk Versus a Build Per Top Customer
  10. 12:08Reaching the Same Conclusion From Different Data
  11. 13:26Feature Flags as Knobs During a Bad Deploy
  12. 14:41Does the Humdrum IT Department Do Any of This?
  13. 15:57Change Is Endemic, So What Is Ops For?
  14. 17:27One Percent More Risk Against the Business Benefit
  15. 18:50Ops Exists to Enable the Business, Not Keep Boxes Up
  16. 20:10Deja Vu: Rigid Deployment Plans as Rigid Project Plans
  17. 21:25Business IT Alignment, or Wasting Cash
  18. 22:47Automate the Infrastructure First
  19. 24:06Sixty Machines With Puppet Against Two Days by Hand
  20. 25:22Is ITIL the Waterfall of the Data Center?
  21. 26:54Easy to Demonize, But Nobody Fully Implements It
  22. 28:13Map Only as Much Into a CMDB as You Need
  23. 29:32One Change Process for Every Kind of Cloud
  24. 30:49How Much Choice Is Too Much Choice
  25. 32:12Tools Enable Process, Habits Defeat It
  26. 33:27"There's No Way We Can Talk to Our Dev Teams"
  27. 34:42Habits That Have to Die Hard
  28. 36:00Telling the Organization What IT Can Now Do
  29. 37:18Social Engineering Next Time
005

Bits Versus Atoms, Release Planning, and Measuring Value Instead of Cost, with Jim Highsmith

2009-07-28 · 54:22 · mp3 · transcript · SRT · archive.org

Built around the second edition of Agile Project Management, and the best line in it is about measurement: a fuzzy measure of something that matters beats a precise measure of something that does not, which is how cost and schedule crowd out value. The answer to "we don't have time to calculate value" is that we don't have time to calculate cost either. Around that sit the book's four additions - scaling teams up against out, governance when hardware is in the mix, release planning as more than bookends on a run of iterations, and metrics. Also bits against atoms, and virtual co-location on a 600-person team.

41 chapters
  1. 0:00Introductions
  2. 1:23Rapid Development, and Finding Scrum, DSDM and XP
  3. 2:42Where Adaptive Software Development Came From
  4. 3:58When a Method Gets Defined by Its Tool
  5. 5:21Management Agility and Technical Agility Need Different Tools
  6. 6:40Agile in Different Geographies
  7. 7:56Impediments You Can Beat, Barriers You Cannot
  8. 9:12Above the Team Level, Into the Rest of the Business
  9. 10:29The Four Additions to the Second Edition
  10. 11:46Be Adaptable, But Conform to This Narrow Plan
  11. 13:10Bits and Atoms, and Titanium Ion Chambers
  12. 14:25Agile as a Highly Disciplined Approach
  13. 15:42Flexible Product Development in Hardware
  14. 16:59An Agile Project Inside Waterfall Phase Gates
  15. 18:23Synchronization Points and Dependency Management
  16. 19:40Release Planning as More Than Obligatory Bookends
  17. 20:58Budgets, Training and Marketing Have to Land Somewhere
  18. 22:18Losing the Release in the Iterations
  19. 23:38Circling Rather Than Progressing
  20. 24:55Different Levels of Product Involvement
  21. 26:16Scaling Up Against Scaling Out
  22. 27:36Decisions, Collaboration, and Organizational Design
  23. 28:51Teams Need Input Into the Decisions
  24. 30:12Being Somebody Else's Customer
  25. 31:29"Must Be Robust and Enterprise-Grade"
  26. 32:52Virtual Co-location on a 600-Person Team
  27. 34:14What Distribution Adds Over Size
  28. 35:38Separable Architecture, Relationships, Complexity
  29. 36:55Spending the Expensive Modes Where They Matter
  30. 38:16Value First, Then Quality and Technical Debt
  31. 39:33Fuzzy Measures of Important Things
  32. 40:52The Value Cost Ratio
  33. 42:20Collecting the Data to Assess Value at All
  34. 43:37Product Management Beyond Feature Counts
  35. 44:55No Time for Value, No Time for Cost
  36. 46:19Customers Shifting From Traditional Measures to Value
  37. 47:36What It Takes to Establish Agile in Bigger Companies
  38. 48:58Looking Back at the Road Traversed
  39. 50:14From Rogue Project Teams to 600-Person Transitions
  40. 51:36Where the Community Is Still Resistant
  41. 52:52Kindle Editions and What an E-book Could Add
006

Bottom-Up Change, Dunning-Kruger, and Who Counts as "Us", with Andrew Shafer

2009-08-06 · 39:31 · mp3 · transcript · SRT · archive.org

Part two on agile infrastructure turns to why the change does not take, and the ratio offered is 20 percent top-down against 80 percent bottom-up - the anecdote behind it being a development director who explained they had not gone agile because the previous executive would not allow it. Wanting to do better is treated as already present and mostly suppressible: set a target that breaks the laws of physics and there is nothing left to tap. It gets less comfortable from there, with a stretch on incompetence existing at every level, the Dunning-Kruger effect as why the feedback never lands, and how the urge to belong makes drawing the line around "us" bloody.

32 chapters
  1. 0:00Continuing on Agile Beyond Operations
  2. 1:18Delivering More Software, and Then What
  3. 2:33First Steps to Make IT More Agile
  4. 3:50Sysadmins Adopting the Practices Already
  5. 5:05Twenty Percent Top-Down, Eighty Percent Bottom-Up
  6. 6:22What Actually Motivates People to Change
  7. 7:39The Window of Opportunity When You Arrive
  8. 8:54Leading People to Water
  9. 9:29Know-How Is No Longer the Missing Piece
  10. 10:13Targets That Break the Laws of Physics
  11. 11:31What Bottom-Up and Top-Down Have in Common
  12. 12:46Making the Iterations Add Up to Something
  13. 14:08Lisa Crispin at the Salt Lake City Roundtable
  14. 15:23Does This Feature Pass, or Do We Make Money
  15. 16:42What Individuals Get From Business Context
  16. 17:59The Fifth Dysfunction: Not Focusing on Results
  17. 19:14Fewer Leaks, and Less Arguing About Whose Leak
  18. 20:30There Is Only Us
  19. 21:45"We Need More Appreciation of Each Other Here"
  20. 23:18Skill Sets Against Organizational Structure
  21. 24:37The Monkey Wrench: Incompetence at Every Level
  22. 25:53The Urge to Belong, and Carrying People Too Long
  23. 27:11Why Drawing the Line Is Always Bloody
  24. 28:28The Dunning-Kruger Effect
  25. 29:46A StarCraft Player With No Feedback
  26. 31:07Faster Feedback Cycles as the Corrective
  27. 32:22The Elevator You Are In, and the Other Elevators
  28. 33:42Calibrating Against a Broader Context
  29. 35:07Blogs, Mailing Lists, IRC and Twitter in 2009
  30. 36:27Safety to Admit You Are Not Good at Something
  31. 37:42Past the Motherhood and Apple Pie
  32. 38:59Meta-Analysis Against Navel-Gazing
007

Configuration Drift, Dark Launches, and Infrastructure in the Same Repository, with Andrew Shafer

2009-08-25 · 48:04 · mp3 · transcript · SRT · archive.org

The concrete half of the mini-series, opening on configuration drift: two supposedly identical servers rarely are, and by a hundred web servers the odds are zero, which is where the confusion and the downtime come from. The fix is putting infrastructure configuration in the same repository as the application, at which point operations looks exactly like software development, because it is just code. Then a run of practices - always ship trunk, why 20 percent of users only tells you about 20 percent of the load, dark launching work nobody can see yet, test-driven infrastructure, and synchronizing every clock to UTC.

36 chapters
  1. 0:00Third Part of the Mini-Series
  2. 1:19Narrowing Down to Practices and Technologies
  3. 2:38Configuration Drift, and Why It Reaches Certainty
  4. 3:55Wary of the Label "Agile"
  5. 5:12Scaling Up, Scaling Out, and Scaling Downstream
  6. 6:28Half the Story Is Borrowing From Software
  7. 7:58Fusion of Worldviews, Not Assimilation
  8. 9:18A Culture of Learning in Every Role
  9. 10:38Why Is IT So Brittle?
  10. 11:55Forced to Change With Information Missing
  11. 13:13The Wall of Confusion
  12. 14:34The Hero Cycle
  13. 16:05People Learn to Game Any Measurement System
  14. 17:26Non-Functional Requirements Lost in the Backlog
  15. 18:47Putting Data Center People on the Team
  16. 20:10Problems Melting Away When Dev and Ops Pair
  17. 21:25Not Preventive Medicine, Just Healthy Living
  18. 22:50Version Control as a Shared Resource
  19. 24:07Versioning What You Would Otherwise Retype
  20. 25:27Once It Is in Version Control, It Is Software Development
  21. 26:44One Repository for Application and Configuration
  22. 28:03Always Ship Trunk
  23. 29:20Twenty Percent of Users, Twenty Percent of the Impact
  24. 30:36Dark Launching Work Nobody Can See
  25. 31:55Under the GUI, in Production
  26. 33:14Why It Passed in Test and Failed Live
  27. 34:32Every Component, Including the Database
  28. 35:48Stored Procedures, and Why Nobody Likes DBAs
  29. 37:16Building the Whole System From Bare Metal
  30. 38:37Test-Driven Infrastructure
  31. 39:52A CMDB That Enables Change Instead of Impeding It
  32. 41:09Synchronize Every Clock, and Use UTC
  33. 42:26Synchronizing Across Data Centers and the Cloud
  34. 43:42Rebuilding as a Habit Gives You Scaling and Testing
  35. 44:58Continuous Training for When Things Go Wrong
  36. 46:17Where the Presentation Will Go Deeper
008

Everybody Owns Availability, Continuous Deployment, and the Dessert Tray, with John Allspaw

2010-02-11 · 40:05 · mp3 · transcript · SRT · archive.org

The argument here is that culture comes first and the tools follow, against the engineering instinct on both sides of the fence to pick tools and then bend the culture around them. Flickr is the worked example, and the interesting claim is that nothing had to be changed - it grew that way, because the person writing the operations tools was also writing the public-facing code and arrived with no preconception that a load-balancing problem starts with a vendor quote. "Everybody owns availability" is the slogan. Deployment is treated as the boundary object where this becomes real: developers pushing their own code, and a deploy of five changes from three people moving both time-to-detect and time-to-resolve.

30 chapters
  1. 0:00Introductions, Reductive Labs and Flickr
  2. 1:15Growing an Operations Team Through Accelerated Growth
  3. 2:33Below the Gloss of High-Scale Web
  4. 3:55Culture First, and Everything Else Follows
  5. 5:11If Only One Group Sits at the Table, You Lose
  6. 6:35Why Traditional IT Ended Up Somewhere Else
  7. 7:50Two PHP Developers and No Preconceptions
  8. 9:12Tools Written by Someone With a Developer Mindset
  9. 10:31Nothing Had to Be Changed, It Started That Way
  10. 11:52It Is 2010, There Is No Excuse for Ignorance
  11. 13:08The Glass-Half-Full Case for Cultural Change
  12. 14:29Everybody Owns Availability
  13. 15:48Eight Data Centers and Nobody Touching a Server
  14. 17:03Boundary Objects, and Deployment as the Obvious One
  15. 18:18Five Changes From Three People
  16. 19:42Change Management as the Art of Changing Nothing
  17. 21:00Velocity as the Center of Gravity
  18. 22:22Not an Excuse to Be a Cowboy
  19. 23:43Role Reversal, and the Pendulum Swinging Back
  20. 24:58The Dessert Tray
  21. 26:25Knowing When to Turn the Volume Up
  22. 27:49The Goal Is Not Having Incidents
  23. 29:10Every Application Needs Its Own Metrics
  24. 30:25Everyone's Job Is to Enable the Business
  25. 31:43The First OpsCamp in Austin
  26. 33:03What Is Coming Up at Velocity
  27. 34:26Operational Concerns Are Not Going Away
  28. 35:46Using Infrastructure as a Service for What It Is
  29. 37:15Databases, Persistence and Large-Volume LAMP
  30. 38:39Match the Service to the Capacity You Need

🍕 Get more pizza.