Scrum Master phải làm gì khi Dev Team không tổ chức Daily Scrum thường xuyên?

Tuần trước tôi đã tham gia sự kiện  Transition to Agile – Demystify do PMI Vietnam Chapter tổ chức, sự kiện với sự góp mặt của rất nhiều anh chị em trong Cộng đồng quản lý dự án cũng như các trưởng bộ phận, Giám Đốc của các công ty trong nhiều lĩnh vực đến cùng chia sẻ kinh nghiệm về Agile. 

Trong phiên hỏi đáp có một câu hỏi rất hay được đưa ra: “Trong một dự án có 3 thành viên: 01 Senior, 01 junior và 01 Tester, dự án đã thống nhất tuân theo Scrum framework. Tuy nhiên khi vận hành, đồng chí Senior không muốn tổ chức buổi Daily Scrum, vì lý do anh ta đã biết hết tình hình của team, và trong team chỉ có 03 người ngồi gần nhau nên có thể chia sẻ thông tin cho nhau bất cứ lúc nào”. Vậy trong trường hợp này, việc tổ chức Daily Scrum có thực sự cần thiết và ta phải xử lý như thế nào nếu trong tổ chức của mình gặp trường hợp tương tự?

Có rất nhiều chuyên gia đưa ra cách xử lý của mình, có người nói “phải cử ông Senior này đi training lại để hiểu được mục đích ý nghĩa của Daily Scrum”, có người nói “dự án đó chỉ có 3 người, muốn thành công phải nghe theo ông Senior, vì làm cho ông ta thỏa mãn thì dự án mới thành công, và vì team này tự tổ chức nên họ tự biết tìm cách làm cho mình”. Có ý kiến khác là “Ta phải dùng Daily Scrum để hỏi tình trạng công việc của mọi người, vì nếu trong lúc họ đang code, test mà hỏi thì sẽ gây khó chịu” ….Ý kiến cá nhân của mỗi người khó có thể đánh giá được ai đúng ai sai, tuy nhiên tôi muốn chia sẻ góc nhìn của riêng mình về vấn đề này.

 

Hình minh hoạ Daily Scrum. Nguồn: Medium.com

Nếu bạn đã học chứng chỉ PSM1 hoặc PMI-ACP thì tình huống như trên không còn xa lạ, bạn sẽ gặp câu hỏi ôn thi như: “Dev team cảm thấy buổi Daily Scrum tốn thời gian nên muốn bỏ”, hoặc “Devteam chỉ muốn tổ chức buổi Daily Scrum vào thứ 3 và thứ 5 hàng tuần”, là Scrum Master bạn phải làm gì?

Câu trả lời chung cho cả 2 tình huống trên khi chúng ta được học đó là Scrum Master phải coaching và giải thích tầm quan trọng và lợi ích của Daily Scrum cho Dev Team hiểu, đồng thời hỗ trợ/facilitate họ thực hiện nếu cần thiết. Tôi cũng xin chia sẻ một vài thông tin như sau:

Nếu bạn đã đọc Scrum Guide, câu cuối cùng của phần Daily Scrum đó là: “Daily Stand up is a key inspect and adapt meeting”. Có nghĩa là trong 04 sự kiện của Scrum, Daily Scrum là sự kiện chính để thanh tra và thích nghi, nếu mất đi sự kiện này thì việc thanh tra và thích nghi sẽ không thường xuyên, cơ hội tìm ra rủi ro sẽ muộn hơn. Và sự kiện này không phải để junior báo cáo công việc cho Senior. Ngoài ra, ông Senior có thể biết được tình hình công việc của các member còn lại, tuy nhiên nếu không có buổi Daily Scrum, bạn Junior và Tester cũng khó có thể biết được tình hình công việc cũng như rào cản của nhau (nhiều người không tự nói rào cản của mình cho đến khi được hỏi), do đó tính minh bạch cũng bị ảnh hưởng. 

Thanh tra – thích nghi – minh bạch là 03 trụ cột của Scrum, về cơ bản trong tình uống trên, tất cả các trụ cột đã bị vi phạm. Hơn nữa, cá nhân tôi thấy trong 05 giá trị của Scrum (Courage, Openness, Respect, Commitment, Focus) thì 03 giá trị đầu tiên cũng bị vi phạm.

Về sự thành công của dự án, dĩ nhiên, với dự án có 03 người như vậy, thật khó có thể so sánh sự thành công của dự án nếu họ đang áp dụng mô hình truyền thống và sau khi họ đã chuyển đổi sang Agile. Hay nói cách khác, nếu họ vẫn áp dụng mô hình truyền thống, thì dự án có thể vẫn chạy mượt mà như vốn dĩ nó vẫn chạy; vậy liệu ta có nên thay đổi cách làm việc để áp dụng mô hình hiện đại hơn?

Sự thành công của dự án đối với đại đa số chúng ta, đó chính là sản phẩm bàn giao đúng hạn với chất lượng tốt và chi phí trong mức cho phép. Tuy nhiên một kết quả vô hình ít tổ chức nào để ý đó chính là kinh nghiệm và tri thức của cá nhân/ tổ chức thu được sau mỗi dự án. Tri thức ở đây không chỉ là các kỹ năng về kỹ thuật như code, test … mà kiến thức về quy trình, cách quản lý dự án, kiến thức về Agile/Scrum và khả năng áp dụng kiến thức chuẩn và sự tùy biến để áp dụng vào dự án thực tế. Do đó ở tình huống trên dự án có thể sẽ bàn giao sản phẩm tốt cho khách hàng, tuy nhiên cách làm việc của team không tận dụng tối đa được lợi ích mang lại từ mô hình hiện đại. 

Hơn nữa, việc truyền đạt Mindset về Agile của các thành việc trong tổ chức là vô cùng quan trọng, nhất là từ Senior cho các Junior. Nếu các senior luôn lấy kinh nghiệm của mình để phá vỡ các rules, thì các junior cũng có xu hướng phá vỡ các rules đó mặc dù chưa đủ kinh nghiệm. Đây chính là hiện tượng vô cùng nguy hiểm vì nó có nguy cơ tạo ra làn sóng không tốt cho công ty, và mindset của toàn bộ nhân viên khó có thể thay đổi nếu đã có những thói quen như vậy. Một trong những sức mạnh của Agile đó chính là chia sẻ thông tin chia sẻ và việc truyền đạt kinh nghiệm của các thành viên trong dự án mà mô hình truyền thống không thể có được.

Trong nhiều trường hợp không tuân thủ các Rule của Scrum, nhiều người làm khác đi và lấy lý do là đang làm ScrumBut, tuy nhiên dù Scrum framework có được sửa đổi như thế nào, thì cái CORE của nó vẫn phải giữ lại, CORE ở đây là các vai trò (PO, SM, Devteam), các sự kiện (Daily, Planning, Review, Retro) và các tạo tác Scrum, và đặc biệt, 03 trụ cột và 05 giá trị luôn phải được giữ vững. Trong trường hợp làm khác đi, họ phải giải thích được vì sao không thể áp dụng được Scrum chuẩn, tác hại là gì và cách làm khác đi sẽ có ích lợi gì? 

Hi vọng, qua bài viết này, mọi người cho dù muốn phá quy trình/rules, muốn làm khác đi đều có thể giải thích được vì sao làm vậy một cách hợp lý, và chỉ làm khác đi khi ta đang ở mức Ri, hoặc ít nhất là ở mức Ha trong “Shu-Ha-Ri”. Còn khi ta vẫn đang loay hoay ở mức Shu mà vẫn muốn cải tiến, retro liên tục và tìm nhiều cách để làm khác đi, thì đó chính là các hoạt động “cải lùi” chứ không còn cải tiến nữa. 

Trần Hữu Tấn