“Sồi có lẽ là loài cây khỏe nhất trong rừng, Liễu với khả năng thích nghi và cơ thể uyển chuyển. Nhưng khi đối mặt với hỏa hoạn và bão tố thì Liễu mới là loài sinh tồn sau cùng.” — Kara Barbieri

Bản chất của Scrum là linh hoạt: Một đội nhóm nhỏ có tính linh hoạt và khả năng thích ứng cao.

Hay nói cách khác: Scrum đòi hỏi mọi người phải linh hoạt trong nhiều tình huống. Linh hoạt trong tương tác của họ với những người khác để biết cách mang lại giá trị cao nhất. Linh hoạt trong các quy trình để họ có thể cải thiện chúng. Linh hoạt trong kế hoạch, vì vậy bạn có thể thực hiện theo kế hoạch tốt hơn khi có thêm nhiều thông tin mới đến.

Vậy câu hỏi tôi đặt ra cho bạn là: Nhóm Scrum của bạn linh hoạt đến mức nào? Và nếu nhóm của bạn không linh hoạt, thì liệu đội nhóm của bạn có đang thực sự “Doing Scrum”?

Lỗi thường gặp khiến nhóm Scrum mới thường trở nên kém linh hoạt hơn.

Hầu hết các nhóm mới bắt đầu với Scrum thường thiếu linh hoạt bởi vì họ cố gắng khởi đầu với một bước đi khá “an toàn” trong khi phải đối mặt với quá nhiều thay đổi, không chắc chắn và mang tính rủi ro. Bên cạnh đó là mô hình quản lý nhóm truyền thống lỗi thời với những quy tắc không cần thiết khiến cho thành viên nhóm cảm giác như họ bị kiểm soát từ trên xuống.

Khi bạn lựa chọn một bước đi an toàn, nó làm cho nhóm thiếu đi sự mạo hiểm cần thiết để tạo nên bước tiến mới. Đây là vấn đề bởi vì Scum là một Framework cho phép quy trình mới thực sự có hiệu quả xuất hiện. Bạn cần khám phá để tìm ra những gì hoạt động tốt nhất với hoàn cảnh và tình huống hiện tại, và điều này đòi hỏi bạn phải chấp nhận rủi ro.

“Often the difference between a successful man and a failure is not one’s better abilities or ideas, but the courage that one has to bet on his ideas, to take a calculated risk, and to act.” Maxwell Maltz

Thường thì sự khác biệt giữa người thành công và người thất bại không nằm ở việc ai có khả năng hay ý tưởng tốt hơn, mà ở lòng can đảm để đánh cược cho ý tưởng của mình, để có thể chấp nhận rủi ro đã được tính toán và hành động hướng về phía trước.

Điều cần làm nên thay đổi chính là bạn phải bước ra khỏi vùng “an toàn”. Nếu chỉ đứng trong cái giới hạn an toàn ấy, bạn sẽ chẳng có được sự đột phá nào mà chỉ là bạn làm được những thứ đã làm được trước đây với chỉ một chút biến chuyển.

Điều này có vẻ rất trừu tượng, nhưng cho phép tôi đưa ra một số ví dụ cụ thể về các đội nhóm chơi quá an toàn và thiếu đi sự linh hoạt.

Hãy thử xem nhóm của bạn có thực sự linh hoạt hay không với các tình huống khác nhau sau đây nhé:

Sprint Planning [Kế hoạch Sprint]

• “Chúng ta không thể cho thêm hạng mục này vào kế hoạch Sprint bởi vì nó nó chưa đáp ứng “Definition of Ready” mà chúng ta đã định nghĩa.”

• “Chúng ta không thể đưa hạng mục này vào kế hoạch Sprint bởi vì nó chưa có Story Points.”

Điều kiện tiên quyết để thêm hạng mục vào Sprint trong Scrum là: Hạng mục Product Backlog được dự báo là có thể hoàn thành trong Sprint đó. Story Points chỉ là tùy chọn và mang tính chất bổ sung mà thôi.

Refinement [Grooming]

• “Chúng ta không thể thảo luận vấn đề này trong Refinement Meeting, bởi vì nó cần phải được trải qua giai đoạn Pre-refinement trước đó.

• “User Story đang thiếu “Acceptance criteria”. Vì vậy vui lòng bổ sung thêm thêm Acceptance criteria để chúng ta có thể làm rõ vấn đề này trong phiên làm việc tiếp theo.”

Pre-refinement không phải là một khái niệm trong Scrum, ở đấy chỉ có Refinement (Hay còn gọi là làm mịn hạng mục Backlog). Team phát triển thường không dành nhiều hơn 10% thời gian của họ cho công việc này. Mặc dù tài liệu hướng dẫn Scrum nêu rõ rằng Product Backlog thường bao gồm các mô tả kiểm thử để chứng minh tính hoàn chỉnh khi một hạng mục được coi là “Done”. Nhưng thực sự thì Acceptance criteria là một hạng mục tùy chọn mà thôi…

Làm việc với các nhóm khác

• “Chúng tôi chỉ có thể giúp đỡ bạn khi đã nhận được sự đồng ý từ Scrum Master.”

• “Chúng ta không thể thêm hạng mục này vào Sprint, bởi vì chúng ta đã bắt đầu Sprint của mình rồi.”

Scrum Master không phải là người quyết định mọi thứ, và cũng không phải là người làm việc như một người gác cổng (Goal Keeper) cho nhóm. Các nhóm có thể trao đổi trực tiếp với nhau và các hạng mục có thể được bổ sung hoặc xóa bỏ ra khỏi Sprint, miễn là nó không gây ảnh hưởng nguy hiểm đến Sprint Goal là được.

Vì vậy, câu hỏi chính tôi muốn thảo luận vẫn là: Tại sao các nhóm vẫn thường phản ứng như thế thay vì linh hoạt hơn?

Tại sao một số nhóm không linh hoạt hơn?

“Nếu thất bại không phải là một sự lựa chọn thì thành công cũng vậy.” — Seth Godin

Để trở nên linh hoạt hơn, nhóm cần phải thay đổi cách thức làm việc làm việc của họ.

Để thay đổi phong cách làm việc thì họ cần phải chấp nhận rủi ro.

Và chấp nhận rủi ro, nhóm cần cảm thấy “đủ an toàn” để chấp nhận những rủi ro này.

Cái cảm giác “an toàn” đủ để có thể chấp nhận rủi ro này được gọi là sự an toàn về mặt tâm lý. Các nhóm đã trải nghiệm điều này thì các thành viên trong nhóm thường có tư duy:

“Cảm thấy an toàn để chấp nhận rủi ro và chấp nhận bị phê bình trước mặt nhau.”

Nếu không có tâm lý an toàn thì sẽ không có rủi ro nào cả. Nếu không có rủi ro nào cả có nghĩa là sẽ không có sự thay đổi thực sự nào hết, và nếu không có có thay đổi thực sự thì nhóm Scrum của bạn sẽ không bao giờ trở nên linh hoạt. Nhóm như vậy thì chỉ cố gắng tìm cách phù hợp với những gì họ đã làm trước đây để cho đúng khuôn khổ Scrum.

An toàn tâm lý được xác định là thành phần quan trọng của các nhóm hiệu suất cao tại Google trong dự án Aristotle. Sự an toàn về tâm lý cũng tạo nền tảng cho khuôn mẫu để mô tả các giai đoạn khác nhau của các đội nhóm hiệu suất cao: Model ‘The Five Dysfunctions of a Team’ bởi Patrick Lencioni. An toàn về mặt tâm lý được coi là nền tảng của Model này.

Điều quan trọng mà tôi cũng muốn đề cập tới là: Ở ngoài kia có nhiều nhóm hiệu suất cao và chấp nhận rủi ro hơn là chỉ an toàn về mặt tâm lý. Nhưng an toàn về mặt tâm lý tạo nên nền tảng của một đội nhóm hiệu suất cao. Thử nghĩ xem nếu các bạn không đủ tin tưởng để dựa vào nhau thì làm sao bạn có thể trở thành một đội nhóm có hiệu suất cao?

Linh hoạt đòi hỏi sự an toàn về mặt tâm lý

Scrum yêu cầu đội nhóm của bạn phải linh hoạt.

Nếu không linh hoạt, nhóm sẽ không tìm được cách để mang lại nhiều giá trị nhất và sẽ không thể tìm ra quy trình làm việc tốt nhất. Và cũng sẽ không tìm ra kế hoạch tốt nhất khi có tiếp nhận những thông tin mới đến..

Hầu hết các nhóm mới bắt đầu với Scrum thường trở nên kém linh hoạt hơn. Các nhóm Scrum mới cố gắng chọn cách đi an toàn khi đối mặt với quá nhiều thay đổi không chắc chắn và mang tính rủi ro. Các nhóm này thường dùng phong cách làm việc đã lỗi thời, họ đặt những quy tắc quen thuộc và không cần thiết lên TOP và kết quả là gây cho những thành viên có cảm giác như là họ đang bị kiểm soát..

Hướng đi an toàn thường mang lại sự chắc chắn nhưng lại không tạo nên sự thay đổi thực sự. Đây là một vấn đề bởi vì Scrum là một khuôn khổ quy trình cho phép quy trình làm việc mới hiệu quả thực sự xuất hiện, và điều này đòi hỏi cần phải chấp nhận rủi ro.

An toàn về mặt tâm lý ➡ Chấp nhận rủi ro ➡ Thay đổi cách thức ➡ Linh hoạt

Để các nhóm Scrum chấp nhận rủi ro, họ cần phải cảm thấy an toàn về mặt tâm lý. Điều này cho phép chấp nhận rủi ro để dẫn đến những thay đổi thực sự đối với quy tình làm việc và cho phép linh hoạt và phản ứng với sự thay đổi, từ đó mới có thể hoạt động hiệu quả và đạt được những bước tiến mới.

Nói tóm lại: Nếu nhóm của các bạn không linh hoạt, có nghĩa là nhóm của bạn đang không áp dụng Scrum!!!

Thank you for reading. Vui lòng Share nếu bạn thích bản dịch này và hãy chia sẻ suy nghĩ của bạn nhé! Hy vọng bạn cũng thích những bài dịch khác của tôi.

Nguồn: https://medium.com/serious-scrum/if-you-are-not-flexible-you-are-not-doing-scrum-ebf41f47d151