https://cote.pizza/agile-executive/ 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. en-us Israel Gat and Coté https://cote.pizza/agile-executive/ Cote-TheAgileExecutive-001 Tue, 07 Apr 2009 00:00:00 +0000 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. 29:37 https://cote.pizza/agile-executive/ Cote-TheAgileExecutive-002 Thu, 07 May 2009 00:00:00 +0000 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. 30:20 https://cote.pizza/agile-executive/ Cote-TheAgileExecutive-004 Fri, 17 Jul 2009 00:00:00 +0000 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. 37:38 https://cote.pizza/agile-executive/ Cote-TheAgileExecutive-005 Tue, 28 Jul 2009 00:00:00 +0000 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. 54:22 https://cote.pizza/agile-executive/ Cote-TheAgileExecutive-006 Thu, 06 Aug 2009 00:00:00 +0000 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. 39:31 https://cote.pizza/agile-executive/ Cote-TheAgileExecutive-007 Tue, 25 Aug 2009 00:00:00 +0000 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. 48:04 https://cote.pizza/agile-executive/ Cote-TheAgileExecutive-008 Thu, 11 Feb 2010 00:00:00 +0000 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. 40:05