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 đào tạo lấy chứng chỉ quốc tế Certified Scrum Master, 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:
Trong bài viết 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 sau 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 sau mỗi Sprint. (Hẳn bạn sẽ thấy kỳ lạ? Hãy đọc tiếp…)
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.
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 Scrum Master 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 nhớ hồi đáp sự giúp đỡ của Scrum Master này). Có thể chuyển địa điểm ra ngoài trời, thậm chí vừa đi 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. Sau đó trong buổi Cải tiến tiếp theo sẽ thảo luận nên bỏ kỹ thuật nào khỏi quy trình của nhóm. (Và, tất nhiên là không được phép “bỏ phiên 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 sách “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 trong 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 đó.
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 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 để bài viết 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 cũng chẳng có gì vui cả. Sau đó, tôi đưa cho một người nữa đọc. 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 cách để cải tiến, nhóm cần phải họp Cải tiến.
Cách để triển khai phiên Cải tiến sau mỗi Sprint hiệu quả
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:
Đâ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, nếu một nhóm rất muốn thoát khỏi họp Cải tiến thì 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 phiên 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 Scrum Master tốt thực sự nên phản biện lại 4 lý lẽ kể trên và khuyến khích nhóm họp Cải tiến sau mỗi Sprint. Nhưng khi nhóm làm theo Sprint 1 hay 2 tuần thì Scrum Master 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 có phiên 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 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à 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.
Tác giả: Mike Cohn – Founder của Mountain Goat Software
Dịch: Nguyễn Trung Tuyến
Tổ chức phiên cải tiến là một hoạt động đơn giản, dễ thực hiện và đáp ứng đầy đủ các nguyên tắc trên. Tuy nhiên, hoạt động này rất dễ bị làm sai và không phát huy được hiệu quả, nhất là với các cá nhân, tổ chức mới triển khai Agile/Scrum hoặc triển khai không bài bản.
Để giúp nhà quản lý dự án kiểm soát tiến độ, chi phí và tăng khả năng thích ứng với thay đổi hiệu quả, Học viện Agile đã xây dựng khóa đào tạo Quản trị dự án Agile (Agile Project Management) với sự dẫn dắt của các giảng viên giàu kinh nghiệm.
Khóa học này được xây dựng dựa trên khung kiến thức PMI-ACP của Project Management Institute, Scrum Framework trong quản trị dự án, cung cấp kiến thức về quản trị dự án theo Agile một cách bài bản, hệ thống, cùng với đó là các phương pháp và công cụ thực hành giúp triển khai dự án hiệu quả và tối ưu chi phí.
Khóa học Quản trị dự án Agile của Học viện Agile
Khóa học được thiết kế dành cho:
Khóa học sẽ giúp bạn:
Bài viết liên quan:
