Những buổi retrospective tệ nhất mà tôi từng ngồi đều giống nhau ở một điểm: nhóm không đạt sprint goal, thế là cả tiếng đồng hồ biến thành một buổi truy xét xem vì sao lại trượt. Còn những buổi tốt nhất thì gần như chẳng nhắc gì đến goal. Chúng tôi nói về cách mình đã làm việc, cái gì đã cản trở, và lần sau sẽ thử làm khác đi ra sao. Khác biệt đó chính là cái mà người ta gọi là tư duy không phụ thuộc vào kết quả (outcome-independent mindset). Sau một thời gian tự mình điều phối sprint, tôi nghĩ đây là thái độ hữu ích nhất mà một Scrum Master có thể có.
Nói cho rõ: kết quả là quan trọng. Chẳng ai trả lương cho chúng ta để có một quy trình đẹp đẽ mà không làm ra được gì. Nhưng hoàn thành sprint là việc của nhóm. Còn việc của Scrum Master là cải thiện cỗ máy làm ra các sprint. Đó là hai việc khác nhau, và phần lớn những trục trặc xoay quanh Scrum mà tôi từng thấy đều bắt nguồn từ chuyện nhầm lẫn giữa hai việc này.
Điều gì thay đổi khi bạn thôi bám chặt vào kết quả
Nhóm có không gian để thật sự làm chủ công việc. Về lý thuyết, Scrum dựa trên những nhóm tự tổ chức, nhưng một Scrum Master lo sốt vó cho từng kết quả thì rốt cuộc sẽ đi lái mọi quyết định, và nhóm sẽ sớm nhận ra quyết định thật ra không nằm trong tay họ. Còn khi bạn tập trung vào quy trình, bạn có thể để mọi người thử nghiệm, thỉnh thoảng quyết định sai, rồi rút kinh nghiệm từ đó. Đó cũng là cách duy nhất để tinh thần làm chủ thật sự hình thành.
Các buổi retrospective trở nên thẳng thắn hơn. Khi câu hỏi đặt ra trong phòng là “sao mình không đạt con số?”, những câu trả lời thật sẽ lẩn đi hết. Còn khi câu hỏi là “cái gì làm mình chậm lại, và lần tới nên thử gì?”, mọi người sẽ chịu nói. Với những vướng mắc phát sinh giữa sprint cũng vậy: một Scrum Master bị ám ảnh bởi kết quả sẽ cuống lên vì hạn chót, còn người tập trung vào quy trình thì cứ thế bắt tay vào gỡ vướng mắc.
Stakeholder cũng bớt căng thẳng. Nếu thứ duy nhất bạn đem ra báo cáo là biểu đồ burndown, thì mỗi lần nó chững lại trông đều như thất bại. Nhưng nếu bạn kể thêm được nhóm đã học được gì và đang thích nghi ra sao, kỳ vọng của mọi người sẽ thực tế hơn, và nhóm cũng được che chắn khỏi rất nhiều áp lực mà nếu không thì sẽ đổ ập xuống giữa chừng sprint.
Nếu bạn đã lỡ bị ám ảnh bởi một kết quả nào đó
Tôi biết là nói thì dễ. Khi bạn đã dồn nhiều tâm huyết để một việc diễn ra theo đúng ý mình, thì câu “cứ tập trung vào quy trình thôi” nghe chẳng khác gì một câu khẩu hiệu dán trên tủ lạnh.
Có vài điều thật sự giúp được. Thứ nhất, đừng tự trách mình vì đã quan tâm. Muốn có kết quả là chuyện bình thường, và giả vờ là mình không muốn thì chẳng ích gì. Thứ hai, chuyển mục tiêu về kết quả thành những mục tiêu về quy trình mà bạn kiểm soát được: không phải “thắng cuộc thi” mà là “luyện tập 30 phút mỗi ngày”. Bạn không kiểm soát được bản phát hành có suôn sẻ hay không, nhưng bạn kiểm soát được việc nó đã được review, kiểm thử và demo sớm hay chưa. Thứ ba, để ý xem điều gì đang nuôi nỗi ám ảnh đó. Nếu một ngày bạn mở lại một cái dashboard hay xem giá cổ phiếu cả chục lần, hãy đặt ra vài khung giờ cố định để xem, ngoài giờ đó thì thôi. Và hãy ăn mừng những thành công nhỏ trên đường đi, vì cái mục tiêu xa xôi kia sẽ sẵn sàng nuốt trọn sự chú ý của bạn nếu bạn để nó làm vậy. Còn nếu nỗi ám ảnh thật sự ảnh hưởng tới giấc ngủ hay sinh hoạt hằng ngày của bạn, thì nên tìm đến chuyên gia để được hỗ trợ. Chẳng có gì phải ngại cả.
Kết quả vẫn quan trọng. Nhưng những nhóm mà tôi thấy đạt kết quả đều đặn là những nhóm có người chăm lo cho phần “làm thế nào”, chứ không chỉ phần “làm cái gì”.