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ì”.

Buổi họp là phần dễ

#

Cấu trúc đơn giản đến mức gần như chẳng có gì để nói. Sau mỗi sprint hoặc mỗi giai đoạn dự án, cả đội ngồi lại với nhau và lần lượt trả lời ba câu hỏi:

1. Điều gì đã làm tốt?
2. Điều gì chưa ổn?
3. Mình có thể cải thiện gì?

Chỉ vậy thôi. Mấu chốt nằm ở vòng lặp phản hồi: đều đặn dừng lại, nhìn vào những gì đã thực sự diễn ra, rồi đưa những điều đó quay lại vào cách mình làm việc. Một đội không bao giờ chịu dừng lại thì sẽ chỉ lặp lại chính mình.

Buổi nhìn lại có ích khác buổi xả bực ở chỗ nào

#

Chủ yếu là ở sự thẳng thắn. Người ta chỉ dám nói ra vấn đề thật khi tin chắc rằng mình sẽ không bị làm khó vì điều đó, nên cảm giác an toàn trong phòng quan trọng hơn bất kỳ hình thức nào bạn chọn. Và những nhận xét sắc sảo nhất thường đến từ những người ít nói. Một buổi nhìn lại mà chỉ có mỗi trưởng nhóm nói thì thực chất là một buổi họp báo cáo tình hình, chỉ là rườm rà hơn.

Nửa còn lại là những gì diễn ra sau buổi thảo luận. Vấn đề nào đáng sửa thì trước khi ra khỏi phòng phải trở thành một đầu việc cần làm (action item), có tên người phụ trách và hạn chót rõ ràng. Rồi đến buổi nhìn lại tiếp theo, hãy mở đầu bằng cách xem lại các đầu việc lần trước. Đây là bước mà hầu hết các đội đều bỏ qua. Không gì giết chết buổi họp nhìn lại nhanh bằng việc mọi người lặng lẽ nhận ra mấy đầu việc đó chỉ để trang trí.

Khi có thể, hãy mang cả số liệu vào. Những ý kiến kiểu “sprint này có vẻ chậm” cứ bàn qua bàn lại mãi không đi đến đâu, trong khi một cái biểu đồ thường chốt được vấn đề ngay.

Những kiểu họp nhìn lại thất bại

#

Có ba kiểu tôi từng tận mắt chứng kiến. Một là buổi nhìn lại biến thành buổi đổ lỗi (hãy sửa quy trình, đừng nhắm vào con người). Hai là buổi nhìn lại dùng y nguyên một hình thức suốt cả năm, đến mức ai cũng tham gia như cái máy (hãy thay đổi cách làm). Ba là họp xong rồi thôi, chẳng ai theo sát việc gì cả. Như đã nói ở trên, kiểu thứ ba mới là kiểu chí mạng.

Nhân tiện, những điều này không chỉ áp dụng cho phần mềm. Chiến dịch tiếp thị, tổ chức sự kiện, dự án nghiên cứu, sản xuất: bất cứ công việc nào có chu kỳ lặp lại đều hưởng lợi từ cùng một vòng lặp này. Nhưng dù bạn họp nhìn lại ở đâu thì phép thử vẫn vậy: trước buổi tiếp theo, có điều gì thực sự thay đổi không? Nếu không, thì bạn chỉ đang nói suông mà thôi.