Scrum yêu cầu nhóm phải thực hiện một buổi Cải tiến ở cuối mỗi Sprint. Còn trong hầu hết các khóa Certified ScrumMaster, tôi luôn bị hỏi liệu điều này có thực sự cần thiết không.
Thường thì câu hỏi của mọi người xoay quanh vài lý do:
- Nhóm của tôi làm quá tốt, chúng tôi hiếm khi cần phải cải tiến gì, vì vậy chúng tôi không muốn làm.
- Chúng tôi thấy các buổi Cải tiến buồn tẻ, vì vậy chúng tôi không muốn làm.
- Chúng tôi quá bận với các công việc thực sự (hoặc các buổi Cải tiến mất quá nhiều thời gian), vì vậy chúng tôi không muốn làm.
- Chỉ đơn giản là chúng tôi không thích các buổi Cải tiến, vì vậy chúng tôi không muốn làm.
Trong bài blog này, tôi muốn phản biện nhanh các lý do trên và giải thích tại sao bạn nên làm một phiên Cải tiến mỗi Sprint. Sau đó, Tôi sẽ kết thúc bài viết bằng cách nói rằng có thể — chỉ là có thể — bạn thực sự không cần Cải tiến mỗi Sprint. (Hẳn bạn sẽ thấy kỳ lạ? Hãy đọc tiếp…)
Nhóm quá tốt nên không cần họp Cải tiến
Nhóm bạn có thực sự quá tốt đến nỗi không thể tốt hơn được nữa? Tôi đã làm việc với nhiều nhóm Scrum trong hơn 10 năm, làm Cải tiến mỗi 2 tuần, và họ vẫn có thể tìm ra cách để cải tiến. Có rất ít khả năng nhóm bạn tốt đến nỗi không thể tìm được điểm nào đáng để cải tiến thêm.
Họp Cải tiến quá buồn tẻ
Không ai nói rằng một phiên Cải tiến cần phải thú vị như bộ phim Hollywood ăn khách mới nhất. Nhưng có những việc bạn có thể làm giúp không khí dễ chịu hơn.
Ví dụ, có thể đổi gió bằng cách mời ScrumMaster từ một nhóm khác sang trợ giúp buổi Cải tiến của bạn. Phong cách mới sẽ giúp cải thiện không khí. (Hãy chắc chắn hoàn trả lại sự giúp đỡ của ScrumMaster này). Có thể chuyển địa điểm ra ngoài trời, thậm chí vừa bộ vừa họp cải tiến.
Thử một nội dung hoàn toàn mới cho phiên Cải tiến. Ví dụ, nhiều nhóm thường tìm kĩ thuật mới để áp dụng trong phiên Cải tiến. Khi đó trong buổi Cải tiến tiếp theo để thảo luận nên bỏ kĩ thuật nào khỏi qui trình của nhóm. (Và, tất nhiên là không được phép “bỏ phiên Cải tiến”).
Geoff Watts và Paul Goddard đưa ra mười nội dung khác nhau cho phiên Cải tiến trong Khóa học về Cải tiến của họ. Bạn có thể tham khảo để giúp buổi Cải tiến không quá buồn tẻ.
Nhóm quá bận để họp Cải tiến
Nếu một nhóm nói rằng quá bận không có thời gian để tiến bộ hơn thì nhóm đó có tầm nhìn quá ngắn.
Trong cuốn “7 thói quen hiệu quả”, Stephen Covey đã đưa ra hình tượng một người tiều phu dùng 1 cái rìu đốn cây nhiều ngày liền. Cuối cùng cái rìu bị cùn. Nhưng với tư duy ngắn hạn, người tiều phu chẳng bao giờ dừng lại để mài lưỡi rìu.
Một nhóm Scrum với tầm nhìn ngắn hạn kiểu như vậy sẽ không bao giờ dành ra 30 phút trong thời gian biểu để tìm kiếm các cải tiến. Thay vào đó họ đặt quá nhiều giá trị vào chút ít mã nguồn được viết ra trong 30 phút đó.
Nhóm không thích họp Cải tiến
Lý do này là một phiên bản khác của lý do: Họp cải tiến buồn tẻ. Tôi tách riêng ra bởi vì lý do này đã vượt trên việc họp cải tiến buồn tẻ hay việc một số thành viên nhóm thấy nhàm chán. Họ nói thẳng luôn là họ không thích họp Cải tiến.
Có thể nói, những thành viên này là quá tệ, bởi vì mọi người trong nhóm đều là người chuyên nghiệp. Mà người chuyên nghiệp thì làm tất cả mọi phần của công việc chứ không chỉ những phần mà họ muốn làm.
Ngay khi tôi viết xong bài viết này, tôi cần viết lại 1 lần để làm nó tốt hơn. Điều đó không có gì vui. Sau đó tôi cần đọc soát lỗi. Điều này chả có gì vui cả. Sau đó tôi đưa cho một người nữa đọc nó. Và sau đó tôi phải chấp nhận hoặc từ chối các thay đổi từ người đó. Việc này cũng không có gì vui cả.
Không phải mọi phần trong công việc của chúng ta đều vui vẻ. Dù vài thành viên nhóm không thích họp Cải tiến, nhưng nếu nó giúp nhóm tìm được những cách để cải tiến, nhóm cần phải họp Cải tiến.
Các trường hợp không cần họp Cải tiến sau mỗi Sprint
Vậy khi nào thì không cần họp Cải tiến sau mỗi Sprint? Khi nhóm của bạn:
- Thực sự tốt.
- Mất quá nhiều công sức để làm cho buổi Cải tiến không buồn tẻ.
- Quá bận rộn để đầu tư vào những cải tiến không có giá trị ngay lập tức.
- Đã hiểu rõ giá trị của sự chuyên nghiệp khi không chỉ làm những phần việc thoải mái nhất mà làm tất cả các phần việc.
… và nếu họ làm theo những Sprint ngắn, thì nhóm có thể họp Cải tiến ít đi.
Đây là lý do tại sao. Quy tắc chung của Scrum là chạy Sprint 4 tuần hoặc ít hơn. Vì vậy một nhóm mà rất muốn thoát khỏi họp Cải tiến có thể áp dụng Sprint 4 tuần.
Có một nhóm đã chọn Sprint 1 tuần do nhiều lý do khác nhau. Nhưng nhóm ghét cay ghét đắng họp Cải tiến đến nỗi quyết định chuyển sang Sprint 4 tuần để chỉ phải họp Cải tiến ít hơn.
Đây là một quyết định tồi tệ, trừ khi nhóm có lý do khác ngoài việc muốn họp Cải tiến ít hơn.
Do vậy, một ScrumMaster tốt thực sự nên phản biện lại 4 lý lẽ phía trên và khuyến khích nhóm họp Cải tiến mỗi Sprint. Nhưng khi nhóm làm theo Sprint 1 hay 2 tuần thì ScrumMaster có thể linh động chấp nhận nhóm họp Cải tiến cách tuần.
Tôi thì luôn cố thuyết phục nhóm không nên làm vậy mà nên họp Cải tiến sau mỗi Sprint. Nhưng nếu một nhóm thực sự đạt được hiệu suất cực, cực kỳ cao và làm theo Sprint ngắn (thường là một tuần), tôi sẵn lòng chấp nhận đề nghị của họ và cho họ họp Cải tiến cách tuần. Và với phần lớn các nhóm, làm như vậy vẫn thường xuyên hơn một nhóm họp Cải tiến mỗi 4 tuần.
Bài viết của Mike Cohn- Founder of Mountain Goat Software,
Nguồn: Mountain Goat
Dịch: Nguyễn Trung Tuyến
