前回のDevOps Cafe Podcats(エピソード47)は，QCon London 2014 DevOpsトラックのプレビューだった。トラックのホストと講演者のほとんどが参加して，DevOps CafeのホストであるDamon Edwards氏, John Wills氏と議論していた。トラックのホストであるManuel Pais, Shane Hasite両氏による各セッションの選択理由の説明に続いて，それぞれの講演者が自身の講演について紹介した。その後は科学的手法の重要性について，あるいはアジャイルの"Done"の定義をDevOpsにどのように適応すべきかなど，さまざまな話題が議論された。
Manuelによると，QConはどちらかといえば開発者指向のカンファレンスなので，DevOpsが何を意味するのか，どのような違いを生み出すのかといった説明を通じて，開発指向の人々との橋渡しを支援するようなトラックにしたいというのが講演者たちの考えだ。セッションがさまざまな視点 – 文化的側面からビジネス視点まで – からDevOpsを捉える一方で，いくつかのケーススタディがトピックそのものに具体性を与える。
Daniel Schauenberg氏の講演"Development, Deployment & Collaboration at Etsy"では，本物のDevOps文化が根付いて継続的デリバリと組み合わされたとき，そこにどれほどの効果が期待できるか，という話題を取り上げる。講演ではEtsyのスタック構築方法 – 予想に反しているかも知れないが，クラウドではなく，モノシリックなアプリケーション形式を採用している – について紹介する予定だ。講演の中心はEtsyにおけるアプローチ開発やデプロイメント，インシデント対応，目標を共有するコラボレーション，といったものになる。
Damon Edwards氏の"Dev 'Programming' Ops For DevOps Success""という講演では，DevOpsの文化面に注目する。ゼロからDevOps文化を構築することのできる組織もあるが，そのような幸運に恵まれない場合の方が多い。氏の言うように，"企業とは成功の結果"なのだ。多くの企業には多数のアプリケーション遺産があり，長年に渡って独自の文化が築き上げられている。講演では，この状況を打開するための二面アプローチを取り上げる。第１のアプローチでは，変化を引き起こし，開発(Dev)と運用(Ops)のギャップを埋めるためのヒントやトリックに注目する。第２の方法では，運用チームがどのように行動すべきか，というモデル構築の必要性に着目する。DevOpsのアプローチを説明する上で，オペレーション・アズ・ア・サービスということばが使われることがある。運用活動をチケットや要求/対応キューを通じて管理される対象としてではなく，もっと計画的な方法で，自己完結的に実施されるサービスとして捉えるアプローチだ。
Dave Farley氏が講演する"The process, Technology & Practice of Continuous Delivery"では，継続的デリバリとDevOpsに共通する特徴やツーリング，コラボレーションの必要性，フィードバックループの短縮といった話題を取り上げる予定だ。アジャイルの有用性はフィードバックループの短さにあると氏は考える。それによって促進される迅速かつ継続的な学習ループは，DevOpsの提唱するものと同じだ。DevOps Cafeでの氏は，DevOpsと継続的デリバリの関連性を描きあげている。氏はこれを"人類史上最高の"科学的手法と呼ぶ。講演では実際のプロジェクトを例として，彼らが継続的デリバリを達成するために用いてきた方法や，それがなぜ，どのように有効であるのか，ということを説明したいと考えている。
Robert Benefield氏の"Instrumenting Your Business For Success with DevOps"では，DevOpsにビジネス面での価値を見出すために運用チームが行うべきことについて取り上げる。経営側が現実の世界で起きていることを理解し，その状況認識をいかに差別化要因とすることができるためには，優れたインストルメンテーションが鍵である，と氏は考える。 さらに氏は，ビジネス的な表現方法の重要性についても言及している。"1日100デプロイメント"は意味がない，経営側が知りたいのは，ビジネス上のイベントに対する応答がどれほど早いか，という点なのだ。
Ola Ellnestam氏はポッドキャストには出席できなかったので，代わりにShaneが氏の講演"DevOps at a small International Bank - Contiguous Improvement over Continuous Delivery"について説明した。この講演は銀行という，法規が厳密かつ複雑でコンプライアンスが重要な状況において，DevOpsがどのように適用できるかのケーススタディとなる予定だ。氏が従事するスウェーデン銀行では，物事に取り組む場合において，付加価値の向上と同時にその実行安全性が重要視される。そのプロセスにおいて生み出された"継続的改善 (Contiguous Improvement)"ということばには，"改善の必要なものだけを改善する"という意図が含まれている。講演では数多くのストーリを取り上げて，その基本的な原則と価値，背景にあるビジネス，実施された技術的選択といった点に注目する予定だ。
ポッドキャストの最後の３分の１は，フィードバックループやアジャイルにおけるDoneの定義など，より一般的な話題に触れていた。
DevOpsプラクティス成功の鍵が迅速なフィードバックとそれに伴う検証可能性にあるというのは，誰もが同意するところだ。それはまた科学的手法のプロセス – 仮説の立案，実験の実施, 仮説の証明あるいは反証 – とも関連する。このサイクルの速度を限界まで速めると同時に，それを継続することが必要だ。
アジャイルの"Done"の定義についても議論された。 この定義には誤解があるのではないか，開発が完了して経営側に承認されれば作業終了と開発チームが考えているのではないか，運用面が忘れられているのではないか，という懸念がある。特にサービスの世界においては，完全に終了(Done)というのはあり得ないことだ。 Damonはさらに， “WaterScrumFall"についても言及した。これは開発チームがアジャイルであるにも関わらず，その上流と下流，つまり経営陣と運用側が従来の業務スタイルを踏襲している状況を表すことばだ。DevOpsはこの思考ラインを打破し，参画者すべてが同じ価値の流れに身を置くために生まれたものなのだ。