組織がアジャイルを導入すれば，プロジェクトマネージャの役割や行動に影響があるのが普通だ。スクラムは，プロジェクトマネージャをスクラムマスタや，あるいはプロダクトオーナにするかも知れない。プロジェクトマネージャの方もまた，その仕事の仕方や内容を，スクラムマスタやアジャルチームに合ったものに変えることは可能だ。
Jim Bird氏は，"agile - what’s a manager to do?"と題したブログ記事を書いた。その中で氏は，アジャイルプロジェクトはどのようにマネージメントされるのか，アジャイルチームにおけるプロジェクトマネージャの役割は何か，といったことを論じている。プロジェクト管理とマネージャから見たスクラムを，氏は次のように説明する。
スクラム(今日で言うアジャイルのほとんどはそれを意味しています)には，プロジェクトマネージャの居場所はありません – 管理責任はプロダクトオーナ，スクラムマスタ，そして開発チームに分担されているのです。
プロジェクトマネージャには次のような選択肢があります – スクラムマスタになるか(サーバントリーダの役割を受け入れて，効果的なアジャイルコーチとなるために学ぶことができるならば – そして，チームが彼らを受け入れるならば)，あるいはプロダクトオーナになるか(そのドメインに対する深い知識や，その他のスキルを持っているならば)，さもなくば，どこかで他の仕事を探すか。
Jimが説明するように，プロジェクトマネージャの役割を，スクラムマスタに変えることは可能だ。
プロジェクトマネージャがそのチームのスクラムマスタになるというのは，もっとも自然な流れのようにも思えますが，プロジェクトマスタが効果的なスクラムマスタになれるのか – そして，それが受け入れられるのか – については，多くの異論があります。責任や権限の変更を彼らが受け入れられるのか，チームや組織における役割が変わることに抵抗はないのか。
スクラムマスタは"プロセスオーナ"であり，コーチなのであって，プロジェクトマネージャではありません。彼らはチーム – そしてプロダクトオーナ – がアジャイルプロセスのフレームワークにおける作業方法と自身の役割，責任を理解するのを支援し，ミーティングやレビューを指導し，変革や葛藤を通じてチームメンバをコーチする役割なのです。
氏のブログ記事には，組織がアジャイルを適用する場合において，アジャイルチームにとって必要でありながら実施されていない，プロジェクト管理のアクティビティがいくつか説明されている。例えば，プロジェクトのセットアップや対外的なコミュニケーション，リスク管理といったものだ。
まず最初に，プロジェクトの開始に先立って - イテレーションゼロより前に，完了しておかなければならない作業があります。ステークホルダーの特定。 実施許可の獲得。プロジェクト予算や契約条件の交渉。組織機構に関する理解とナビゲーション。ガバナンスとコンプライアンス要件，制約，PMOが何を必要としているかの特定。人事やラインマネージャ，職務マネージャの協力の下でのチーム編成，優れた人材の発掘と獲得，彼らの作業に必要な作業場所とツールの確保。パートナ，サプライヤ，請負会社のラインアップ。契約やライセンスなどの法的事項。
開発チーム外にも，プロジェクトの状況を知る必要のある人々がたくさんいます - 大規模組織における大規模プロジェクトでは特にそうです。チームの外や社外など，外部の人々に対するコミュニケーション。経営陣やスポンサに情報を伝え，オンサイドに留め置くための，上位に対するコミュニケーション。タスクボードやバーンダウンなど，壁に貼られた大きな視覚的チャートは，チームにとって非常に有効です。しかし経営陣やPMO，その他のステークホルダが知りたいのは，それではありません。彼らはプロジェクト，プログラム，あるいはビジネス変革運動など，全体としての開発状況を知りたいのです。
正しく実行されたスクラム(と，慎重に組み入れられたXPエンジニアリングプラクティス)は，一般的なソフトウェア開発リスク - スコープ，スケジュール，要求仕様，技術的リスク - の多くを抑制する上で有効です。しかし管理の必要なリスクは他にもあります。プログラムリスクや政治的リスクのようなチーム外からのリスクの他，物流リスク，統合リスク，データ品質リスク，運用リスク，セキュリティリスク，金融リスク，法的リスク，戦略的リスクなどです。
アジャイルチームで作業している組織にも，プロジェクトマネージャの必要性は依然として存在する，とJimは言う。
アジャイルでは管理責任がチーム内に分散したり委譲されたりしますが，管理上の問題が消え去る訳ではありません。 誰か - PMOのプロジェクトマネージャ，あるいは必要な権限とスキルを持った者 - が対処しなければ，プロジェクトは拡張できませんし，チームの成功もおぼつかないのです。
"Project Manager to Scrum Master"と題したブログ記事ではRohit Ratan Mani氏が，ウォーターフォールからアジャイルへの移行がプロジェクトマネージャに与える影響を論じている。組織がアジャイル採用する時に何が起こるのか，氏は次のように説明する。
理想的なシナリオでは，SMは，アジャイルを理解する経営陣とのインターフェースとして，プロジェクトを推進するために，チームと共同で作業を始めるでしょう。しかし現実には，経営側から何度も質問されることになります。
- プロジェクト計画はどこにあるのか？
- リスク管理計画はどこにあるのか？
- クリティカルパスは何なのか？
- タスクの何パーセントが完了しているのか？
- プロジェクトのSカーブはどこにあるのか？
プロジェクト管理者はスクラムマスタの役割を果たす必要がある，と氏は示唆する。
SM(スクラムマスタ)は，新たなプロセスを古いプロセスにマッピングする方法を理解し，それを支援することによって，経営陣とのギャップを埋める役割を果たすことが可能だと，私は思います。この２重の役割を果たすには，SMの役割を理解することに加えて，従来的なPMアクティビティの知識が必要になります。SMはプロジェクト実施に対して，これまでとは異なる役割とアプローチを持っているので，従来のPMはSMの役割を担うべきではない，という意見を多く聞きます。 しかしながら私は，アジャイル採用を渇望するPMならば，SMの役割に適合して，スクラムチームと経営者の間のギャップを埋めることができると考えています。
Vidya Venkat氏は，スクラムマスタとプロジェクトマネージャは共存できる，という考えだ。氏のブログ記事 "Accommodating Project Manager in Scrum" には，スクラムマスタとプロジェクトマネージャが行うアクティビティのリストが２つ示されている。
スクラムマスタの役割
- スクラムプロセスの管理 - スクラムマスタはプロジェクトのリーダとして，プロセス実施の全期間に対して責任を持ちます。
- チームのダイナミクスと機能の保証 - 作業の実施には明確に定義された作業パラメータを持った，まとまりのあるチームが必要です。これはスクラムマスタが行うことです。
- 障害のメンテナンス - プロジェクトがスムーズに実行されることを保証し，それを取り巻くあらゆる障壁を除去します。
- スプリント計画 - プロジェクトには常に，目標の達成が求められます。スクラムマスタが重視すべき点のひとつは，計画を立案し，実践し，リリースすることです。
- 外部インターフェースとのコミュニケーション - 下位層にメッセージを伝達することは，スクラムマスタが常に意識しなくてはならない重要な側面です。
プロジェクトマネージャの役割
- プロジェクトの全面的な管理 - プロジェクトマネージャはプロジェクトのキャプテンとして，プロジェクトの全期間にわたって，エンドツーエンドの支援を行います。
- 目標設定の実施 - プロジェクトマネージャは成果を理解し，それが測定可能かつ現実的なものであることを保証しなければなりません。
- "チームの絆"の奨励 - プロジェクトマネージャはプロジェクト全体のマスタとして，自身のチームがよい協力関係を築いて，自らの能力を理解した作業の定義を行えるようにする必要があります。
- プロジェクトコミュニケーションの確保 - プロジェクトの主導者として明確なメッセージを最後まで維持するために，プロジェクト全体のコミュニケーションの責任をひとりで負います。
- 中心的存在 - そして最後に，プロジェクトマネージャはプロジェクトに関連する情報を共有し，発信する唯一の接点であり，重要な役割を担うものです。
"Surviving―and Thriving in―Your First Scrum Master Role”と題したAgile Atlasに関する記事には，プロジェクトマネージャのElizabeth Lloyd氏が，スクラムマスタを初めて務めた自身の経験が記されている。
スクラムマスタであることは，プロジェクトマネージャであることとは違いました。自分自身の自然な性向に逆らうため，意識的に努力することが何度も必要でした。 いくつかの振る舞いを意識的に忘れて，プロジェクトマネージャとしては利用していなかったものを，新たに取り入れなくてはならなかったのです。
そして氏は，スクラムマスタとなる前に知っておくべきだった事として，次の４つを紹介している。
- 自分の直感には必ずしも従わないこと(...) 私は一呼吸おいて，私の意図を解するプロジェクトマネージャ自身が起き上がるのを待つことにしました。その代わりに，チームが自ら決定を行うようにして，私自身はディスカッションの結果をコントロールするのではなく，障害を取り除くファシリテータとしての役割を務めるようにしたのです。
- スコープの優先順位を評価すること(...) 私は，真のスクラムマスタの役割に移行しなければならないことに気付きました。すなわち，チームをサポートし，ベロシティを正確に計算し，ブロックや障害を取り除き，そしてプロジェクトマネージャの設定した日付までにチームが達成するストーリポイントを予測するのです。スコープに関する懸念をエスカレートして，スクラム環境で作業することが成果物やタイムライン，その他のガバナンスに与える影響をステークホルダに理解させるのは，プロジェクトマネージャの役割です。
- 定義，定義，定義 (...) 何人かの仲間とレトロスペクティブで，スクラムマスタやチームの活性化について話し合ったとき，ストーリの実施準備ができたことを，チームが明確に知らないことに気付きました - “Readyの定義”がないのです。(...) そこで私たちは９点のポイントを合意しました。スプリント計画にその中のひとつでも不足するものがあれば，”ノー”と言うように，チームメンバそれぞれと約束したのです。
- “スクラム主義”を押し通すこと (...) [チームが] 作業に魅力を感じていなかった時には，彼らをバックアップしなければなりませんでした。それはつまり，プロダクトオーナに"ノー"を言うことでした。プロダクトオーナが当初の計画を明らかにする前に，私たちがたった一度，私たちの"スクラム主義"に固執したことで，オーナは計画以前の準備をすべて整えてくれたのです。