2010年8月に、BABOKのアジャイル拡張（Agile Extention)のドラフト版が公開された。アジャイルにおけるビジネスアナリストがリエゾン（橋渡し役）として有効に機能するには、動作するソフトウェアを実現する開発チームへ継続的に寄り添い、貢献しなければならない。そのため、アジャイルでのビジネスアナリストは、資料作成や分析の技術だけでなく、ソフトウェアの実現に関わる技能を備えることが必要となるだろう。これは逆に、開発チームがビジネスアナリシススキルを備えるべきだということも、また示唆している。
以前からプロダクトオーナの中には，２つの項目にそれぞれ単独で期待できる経済的利益を１対１比較することによって，バックログの優先順位を設定しているものがあった。これに対して成功を収めたアジャイルチームには，リスクや依存関係，さらにバックログ項目間の複雑な相互作用を考慮した，全体論的なアプローチの採用がしばしば見受けられる。
アジャイルコミュニティが2012年以降受け入れるべき，もっとも重要なものは何か？ 先日の YOW! Austraria Software Developer Conference に参加する機会を得た InfoQ では，多数のアジャイル講演者たちが一同に会するこの機会を活かして，この質問に対する彼らの考えを聞くことにした。
Forrester社リサーチ部門ディレクタ兼ヴァイスプレジデントであるDave West氏は、「ウォータ・スクラム・フォール（Water-Scrum-Fall）」が今日のITでは当たり前になっていると主張する。 Forrester社の調査は質問を投げかける：一体誰が本当に純粋なスクラムを実行しているというのか？
アーキテクトがアジャイルとアーキテクチャのプラクティスを1つにまとめて、機敏にビジネスとアーキテクチャの両方を実現しつつ、実際的にこれら2つの優先順位のバランスをとる方法について、James Madison氏が論じています。
Developers often talk about Technical Debt saying its slowing your projects down. What are they really saying? What measures can you take to reduce it before it cripples your projects?
非伝統的な環境でアジャイルを実践しようとする試みが直面する問題は、アジャイルの原則が適用できないことでも、フィードバックのサイクルが始めからうまくいかないことでもない。アジャイルのスイート・スポットの外では、アジャイルの技術を適用するにはさらなる障壁があり、コストがかかること。これが、彼らが直面した問題だ。これらの障害物はアジャイル自体の適用を妨げるものではないが、アジャイル適用のコストを引き上げる。
Agile 2008で行われたこのプレゼンテーションで、平鍋健児氏がトヨタの新車開発プロセスについて語った。 平鍋氏が、トヨタの元チーフエンジニア、片山信昭氏と出会った経験から得た知識と、彼から学んだ教訓を披露する。
JAOO '07 で「今時、ユニットテストを実施してないコードを納品するのは無責任な開発者だ」というBob Martin氏の主張について、議論が起こった。 このInfoQビデオは、BobとJim Coplien氏がこれに関連する話や、いくつかの他の話題について議論する様子を納めたものだ。TDDと契約による設計(Design by Contract)の比較や、システムとビジネスドメインモデルを調和させるためには、事前にどれくらいのアーキテクチャ設計をしておかなければならないのか、などが議論されている。（翻訳：近藤 修平 - (株)永和システムマネジメント）
スクラムとかんばんはアジャイルソフトウェア開発たらしめる二つの香味料だ。 - スクラムとかんばんはどのように関係しているのか?パートIは、かんばんとスクラムの類似点と相違点を描くことで、理解のための比較を行っている。比較を行っているが、決してどちらの方が優れているか、審判を下しているわけではない。よいツール、悪いツールというのではなく、ただ、どういう時にどのように、どのツールを使うのが、よい決定か、それとも、悪い決定かを示している。パートIIは、スクラムを使っていた開発組織が運用サポートチームにかんばんを導入していったケーススタディを描く。
Agileを始めるときは、とても分かりにくいです。一体どこから手をつければいいのでしょう？この物語はそんな皆様の一助になれば幸いです。本書は、スウェーデンにある、とある40人ほどの会社で、どのようにAgileとXPを実行したか、プロセス改善を行ったかを記しています。
