The story of how a small team gradually become a Whole Team

https://agiletestingdays.com/2023/session/thrusting-trust-a-skin-deep-whole-team-approach/

Transcript

1. The Story of how a small team gradually become a “Whole Team.” Dev QA Mgt Whole team Biz QA Dev Jumpei Ito Thrusting trust: A skin-deep Whole-team approach Agile Testing Days 2023 小さなチームが徐々に Whole Teamへと発展した話
2. 最初は開発チーム主導のプロジェクトだった Initially, the project was development team driven. 課題（Issue） 十分なテストができておらず、品質の問題を抱えていた。 品質についてよくQAチームとコンフリクトを起こしていた。 The product was not being tested adequately and was having quality issues. Conflicts often arose with the QA team about quality. Dev QA 品質問題 Quality issues
3. Dev QA Dev QA Dev QA Whole team Quality Goal チーム間に壁があり、テストの不十分 性や不具合の修正方針についてよく衝 突していた。 There was the wall between the teams and often had conflicts about inadequate testing and policies for fixing defects. 相手への理解が深まり、お互いに尊重 するようになった。徐々に納得感を共 感しWhole teamになっていった。 Teams began to understand and respect each other better. Gradually, they began to build co-confidence in quality and became a Whole team. プロダクトの品質ゴールを明確にし、 できるものと、できないものの透明性 を確保してきた。衝突は減り、徐々に 壁はなくなってきた。 Product quality goals have been clarified and transparency has been maintained on what can be done and cannot be done. Conflicts have decreased and the wall have gradually disappeared. QAチームが入った The QA team joined.
4. QA QAチームが入った The QA team joined. 改善（Kaizen） プロダクトの品質ゴールが明確になり、開発チームと QAチームとで品質に対する納得感の共感を持つよう になった。 The quality goal of the product became clear, and the development team and the QA team began to build co-confidence in quality. Dev Whole team
5. プロダクトリリース時に要件違いがある Mismatches in requirements at the time of product release. QA Dev Biz 要件違い Out of requirements 課題（Issue） リリースしたプロダクトの要件が間違っていたことにより ビジネスへの影響があった。 The requirements of the released product were incorrect, which affected the business.
6. Biz ビジネスチームが入った The business team joined. 改善（Kaizen） 定期的に要件のイメージをすり合わせて、ビジネスに対す るゴールをチーム間で納得感を共感する。 Regularly review the requirements picture and build co- confidence in the business goals among teams. QA Dev Whole team
7. プロダクトリスクに対して経営が受け入れられない Product risk is not acceptable to management. Dev プロダクトリスクが許容できない Product risk is unacceptable. 課題（Issue） 開発、QA、ビジネスチーム内ではプロダクトに対するリ スクが透明化されており、納得感を得ている。しかし経営 ゴールに対する阻害になるため経営サイドでは受け入れら れない。 The risks to the product are transparent and acceptable to the development, QA, and business teams. However, it is not accepted by the management side because it is an obstacle to the management goal. Mgt. QA Biz
8. 経営が入った The management joined 改善（Kaizen） プロダクトリスクが発生したときから経営に情報共有し、 プロダクトで回避策を得るなり、ビジネス戦略を変更する なり、早めの対応をする。また経営ゴールを明確にするこ とによって全員で納得感を共感できる。 Information on product risks should be shared with management from the time they occur, so that early feedback can be taken, such as taking measures to avoid product risks or changing business strategies. In addition, by clarifying the management goal, everyone can build co- confidence in management. Biz QA Dev Mgt Whole team
9. Dev Whole team QA Whole team Mgt Whole team Biz Dev Dev QA Biz QA Dev 課題が出る度に他チームとのゴールを共有することによって、 徐々にお互いに理解を深め尊重するようになり、Whole teamに なっていった。Devチームのメンバーはゴールを意識するように なり、価値生産に対する質量が増えた。 By sharing goals with other teams each time an issue arose, they gradually came to understand and respect each other and became a whole team. Development team members became more goal- oriented, and their mass production of value increased.