2010年8月に、BABOKのアジャイル拡張（Agile Extention)のドラフト版が公開された。アジャイルにおけるビジネスアナリストがリエゾン（橋渡し役）として有効に機能するには、動作するソフトウェアを実現する開発チームへ継続的に寄り添い、貢献しなければならない。そのため、アジャイルでのビジネスアナリストは、資料作成や分析の技術だけでなく、ソフトウェアの実現に関わる技能を備えることが必要となるだろう。これは逆に、開発チームがビジネスアナリシススキルを備えるべきだということも、また示唆している。
アジャイルチームでのスクラムマスタはフルタイムで行う役割か，あるいはパートタイムの役割か，という論争がここ数ヶ月間，コミュニティ内で多くの議論を巻き起こしている。その結果としてコミュニティは「スクラムマスタ宣言」を作り上げた。
Tony Wong氏(プロジェクトマネジメントのブラックベルト)は個人の生産性にとって実践的なポイントをいくつか挙げている。この記事では、これらをいかにソフトウェア開発に適用するかを考え、彼のリストと他のリストを比べる。
スクラムコミュニティのリーダーであるJim Coplien氏は、かんばんに代わるものとしてワンピース連続フローを提案する。氏は、クロスファンクショナルチームは前段階から作業項目か降ってくるのを待つサブチームの集まりではなく、単一ユニットとして一緒に働くべきだと考えている。かんばんの実践者達は、クロスファンクショナルチームの実現が困難である場合、ワンピース連続フローフレームワークがより有効であることを見出した。
Forrester社リサーチ部門ディレクタ兼ヴァイスプレジデントであるDave West氏は、「ウォータ・スクラム・フォール（Water-Scrum-Fall）」が今日のITでは当たり前になっていると主張する。 Forrester社の調査は質問を投げかける：一体誰が本当に純粋なスクラムを実行しているというのか？
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?
スクラムは3つの役割しか定義しない。それはプロダクトオーナとスクラムマスタとチームだ。ここにはマネージャは存在しない。Pete Deemer氏はスクラムを適用したときにマネージャが受ける影響や、マネージャの役割をどのように再定義するのがいいのか(職務内容記述書のサンプルを含む)、マネージャをスクラムマスタに任命することなどを考察する。
個人がマルチタスクで仕事をした場合、非効率で遅くなることは今ではよく知られている。アジャイル/スクラムチームであれば、実行しなければならないプロジェクトの数が鍵となる。アジャイルはチームは一度に一つのチームに従事するべきで、そうでなければ破たんする、と示している。Roger Browns氏はなぜこのようなことが起こるのか、掘り下げて解説している。
Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。
スクラムとかんばんはアジャイルソフトウェア開発たらしめる二つの香味料だ。 - スクラムとかんばんはどのように関係しているのか?パートIは、かんばんとスクラムの類似点と相違点を描くことで、理解のための比較を行っている。比較を行っているが、決してどちらの方が優れているか、審判を下しているわけではない。よいツール、悪いツールというのではなく、ただ、どういう時にどのように、どのツールを使うのが、よい決定か、それとも、悪い決定かを示している。パートIIは、スクラムを使っていた開発組織が運用サポートチームにかんばんを導入していったケーススタディを描く。
Agileを始めるときは、とても分かりにくいです。一体どこから手をつければいいのでしょう？この物語はそんな皆様の一助になれば幸いです。本書は、スウェーデンにある、とある40人ほどの会社で、どのようにAgileとXPを実行したか、プロセス改善を行ったかを記しています。
