Những buổi họp nhìn lại (retrospective) tệ nhất mà tôi từng ngồi đều giống nhau ở một điểm: đội không đạt mục tiêu sprint (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 mục tiêu. 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 đội. 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.

Scrum Master khác quản lý dự án (project manager) thế nào

#

Hai vai trò này hay bị nhầm lẫn, một phần vì nhiều công ty giao cả hai cho cùng một người. Khác biệt cốt lõi nằm ở đây:

Bản thân Scrum không có vai trò quản lý dự án. Nhiều việc mà một người quản lý dự án thường làm được chia cho Product Owner, người quyết định làm cái gì và làm theo thứ tự nào, và các Nhà phát triển, những người lên kế hoạch làm như thế nào.

Điều gì thay đổi khi bạn thôi bám chặt vào kết quả

#

Đội 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 đội 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à đội 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 họp nhìn lại 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. Nếu vướng mắc là một điều mà chưa ai nắm rõ, họ sẽ đề xuất một spike có giới hạn thời gian để tìm hiểu cho ra.

Các bên liên quan 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 đội đã 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à đội 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 rà soát, kiểm thử và trình diễn (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 bảng điều khiển (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 đội mà tôi thấy đạt kết quả đều đặn là những đội 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ì”.