従来の方法ではプロダクトリーダーが1人存在して、後はすべて作業メンバーであればよかった。だがスクラム開発の場合、プロダクトリーダーの他にメンバーへの仕事の割り振りやコーディング計画の作成、進捗管理、発生した障害を解決するスクラムマスターを1人定めなければいけないという現状がある。

　また、プロダクトリーダーにはプロジェクト全体の意味を定義する他に、業務の優先順位を決める役割が増えてしまう。プロジェクトリーダーが業務内容の指示や割り振りを決めて、各メンバーはその指示に従って業務を進めるだけでよかった。だが、スクラム開発の場合、プロジェクトリーダーの指示を待つだけでなく自律的に仕事を行うことが求めらるのだ。

　さらに自分が請け負った業務が小さなプロジェクトということになるため、メンバーにもより大きな責任やリスクが割り振られることになり、コーディングスキルの他にコミュニケーションスキルなど幅広いスキルが求めれるようになる。新しい開発方式の場合、業務ごとのプロジェクトになるため、今までのプロジェクトでは有効だったコンプライアンスや品質管理の方法が有効であることはまずない。

　ここを意識しないと、現場に品質管理が浸透できないことに悩んでしまうというギャップが生まれる。そのため品質管理の方法を新しいプロジェクトに適したものを探し出して実行する必要があり、さらに進捗管理についても各機能別とプロジェクト共通とで分けて行うなど独自の対応が必要になる。