Khi nói về Daily Scrum, ta sẽ nghĩ ngay tới từ đầu tiên, chính là "stand up", nó có lẽ là event nổi tiếng nhất khi chúng ta nói về Scrum. Đây là sự kiện kéo dài không quá 15 phút, trong đó Scrum team kiểm tra kế hoạch cho sprint hiện tại và xem kế hoạch này có còn khả thi hay không. Nó chỉ là thế, không hơn, không kém. Tuy nhiên, có rất nhiều điều sai lầm trong sự kiện 15 phút này. Cùng tìm hiểu thôi.

Tra cứu status của member

Thật không may, đây là vấn đề to bự đầu tiên của hầu hết các team Scrum. Thông thường hầu hết các Product Owner (PO) hay Scrum Master là những người nghe thấy những gì team đã làm hôm qua và những gì họ sẽ làm trong ngày hôm nay. Đặc biệt đối với các vai trò này, không ai trong số họ có một vai trò tích cực trong một cuộc Daily Scrum cả. Mục đích của Daily Scrum là cho dev team cùng nhau kiểm tra cho dù kế hoạch họ đã thực hiện trong Sprint hiện tại là vẫn còn. Bằng cách chia sẻ thông tin có liên quan có thể ảnh hưởng đến tiến độ, team sẽ xác định nhu cầu điều chỉnh kế hoạch của họ. Điều này phụ thuộc vào Scrum Master để hướng dẫn team làm thế nào để có thể thực hiện được việc này. Nếu cần thay đổi kế hoạch, chỉ cần involve PO để thảo luận lại là được. Dưới đây là một số nguyên nhân của hành vi này:

Rule ba câu hỏi

Để có được thông tin được chia sẻ, nhiều team sử dụng ba câu hỏi sau:

• Bạn đã làm gì hôm qua để giúp team đạt được Sprint Goal?
• Bạn sẽ làm gì hôm nay để giúp team đạt được Sprint Goal?
• Có bất cứ trở ngại nào không? Nếu có, tóm tắt ngắn gọn

Mục đích của ba câu hỏi này là chia sẻ thông tin có liên quan đến việc kiểm tra số liệu còn lại của Sprint và xác minh xem liệu team chúng ta vẫn đang đi đúng hướng hay không. Không hơn không kém. Ba câu hỏi này không bắt buộc và những gì tôi thường thấy sau khi tất cả mọi người đã trả lời ba câu hỏi này, team sẽ chủ động kết thúc bài Daily Scrum. Tuy nhiên, bạn chưa làm xong đâu! Trên thực tế, bạn chỉ vừa mới bắt đầu! Bây giờ bạn đã chia sẻ thông tin và bạn có thể thấy, như một team, ta sẽ phải điều chỉnh nếu có vấn đề. Nó không phải là về việc trả lời ba câu hỏi. Đó là những gì bạn cần phải làm với thông tin được chia sẻ. Nếu không có gì đặc biệt để báo cáo và mọi thứ diễn ra suôn sẻ, thì Daily Scrum chỉ được thực hiện chỉ trong vài phút!

Scrum Master làm việc quá chăm chỉ

Nếu như là một Scrum Master, bạn làm tốt công việc của mình, bạn không có nhiều việc phải làm. Tuy nhiên, những Scrum Master không được đào tạo đúng là rất bận rộn. Trong Scrum hàng ngày, Scrum Master không có vai trò tích cực. Vì vậy, nếu bạn là một Scrum Master hành động như là người điều tiết, điều phối viên theo kiểu ra lệnh cho team member cần phải làm những việc gì, và bạn cũng làm nốt việc move ticket (ở đây ý nói là update status của task/user story), thì rõ ràng là bạn đang không làm tốt công việc của mình. Mọi người có thể tự tổ chức những thứ đó.

Là một Scrum Master, bạn phải hướng dẫn cho team hiểu về mục đích của Daily Scrum (kiểm tra nếu cần phải điều chỉnh lại thời gian) và làm thế nào họ có thể làm điều này trong không quá 15 phút. Scrum Master chăm chỉ thường gây ra nhiều vấn đề hơn nhiều so với những gì tôi đề cập ở đây. Vì vậy, là một Scrum Master, hãy lấy một tách cà phê và để cho team tự tổ chức Daily Scrum trong 15 phút này.

Bỏ qua yêu cầu sự trợ giúp của team member

Khi một team với một Scrum Master quá nhanh trong mọi việc, các câu hỏi với yêu cầu trợ giúp (không được nói ra) thường bị bỏ qua bởi Scrum Master và cả bởi dev team. Một ví dụ nhỏ trong một cuộc Daily Scrum khi một thành viên mới trong team đã nói. Đây là những gì đã xảy ra:

Team member: Hôm nay, tôi muốn làm việc này (chỉ vào task trên Sprint Board), nhưng tôi không chắc cách tiếp cận nó. Phần còn lại của team, bao gồm cả Scrum Master: [...] Team member: Tôi đã bỏ ra khá nhiều thời gian cho task này nhưng tôi có nghi ngờ về việc đây là cách tiếp cận đúng. Phần còn lại của team, bao gồm cả Scrum Master: [........] Team member: Sẽ ổn hơn nếu có ai đó trong team cùng nghiên cứu task này với tôi. Phần còn lại của team, bao gồm cả Scrum Master: [................] Scrum Master: Okay? Vậy được rồi, tiếp theo. Ai nhỉ, Hiếu nhé?

Vào thời điểm đó, chúng ta đã phải đối mặt với đội với những gì đã xảy ra. Có người hỏi ba lần một yêu cầu giúp đỡ. Nó không được xây dựng như là một câu hỏi, nhưng nó thực sự là một yêu cầu giúp đỡ và không ai trả lời. Đây là một bài học khó cho team, điều đó không giúp lẫn nhau và Scrum Master quá bận rộn để quản lý 15 phút và ghi chú thay vì nghe những gì đã xảy ra ở đây. Những lúc như thế này mới chính là lúc Scrum Master thể hiện được vai trò dẫn dắt team của mình, bằng cách phân tích vấn đề của team member đang gặp phải, và yêu cầu các team member khác (hoặc chính bản thân Scrum Master) cùng với member kia để giải quyết vấn đề này ngay trong hôm nay.

Thiếu minh bạch

Nhiều team sử dụng bảng vật lý (Sprint Board), nhưng những gì thường thiếu là kiểm tra burndown chart, một practice giúp team theo dõi lượng công việc còn lại và cách team đang tiến triển để hoàn thành công việc của họ. Các team sử dụng một công cụ như JIRA thì sẽ có chức năng này theo ý của họ, nhưng điều này hiếm khi được kiểm tra. Những gì các team này thường làm, ngoài việc chỉ xử lý ba câu hỏi cho việc cập nhật trạng thái, mỗi cá nhân kiểm tra task riêng của mình thay vì kiểm tra feature mà team đang cố gắng deliver. Chắc chắn một điều là JIRA có filter cho phép ta có thể sort Sprint Backlog cho mỗi thành viên trong team và các task mà người này dự định làm việc.

Nếu team mất tập trung vào các tính năng hoàn thiện, điều này cũng có nghĩa là ít thảo luận thú vị hơn trong một Daily Scrum bởi vì họ đang quan tâm đến sự tập trung cá nhân. Đồng thời, team sẽ không dễ minh bạch về công việc bạn đóng góp cho Sprint Goal. Một lần nữa, với vai trò là một Scrum Master, bạn phải cùng team đối đầu với hành vi này, bằng cách đơn giản là điều chỉnh cách chúng ta đưa ra thông tin, chúng ta có thể tạo một cuộc thảo luận khác. Mục đích cuối cùng của mọi thảo luận là để team chúng ta có thể hoàn thành Sprint Goal mà có ít sự điều chỉnh nhất; đồng thời minh bạch hơn trong đóng góp của từng member trong từng Sprint.

Days Off and Working From Home

Cuối cùng, chúng ta đi đến tình huống mà một đồng nghiệp có một ngày nghỉ hoặc làm việc ở nhà. Điều này thường tạo ra những vấn đề không cần thiết trong một team. Hãy để tôi nói trước: bạn có thể làm việc bán thời gian hoặc làm việc tại nhà khi làm việc trong một team Scrum. Tuy nhiên, cả team sẽ phải thỏa thuận làm thế nào để đối phó với nó. Thông thường ta sẽ gặp các member trong team trong các cuộc Daily Scrum để biết rằng đồng nghiệp của mình có một ngày off, hoặc cô ấy/anh ấy làm việc ở nhà mà không chia sẻ thông tin này. Sau đó, ta cố gắng tìm hiểu xem status hiện tại của task mà đồng nghiệp off hay làm việc ở nhà này đang giữ là như thế nào, và cùng lúc này hai đồng nghiệp khác đang cần task nào đó để tiếp tục (free man). Đôi khi có team không biết làm thế nào để vượt qua điều này, trong khi giải pháp là đơn giản.

Tình huống 1: Đồng nghiệp làm việc ở nhà. Tuyệt vời, vì vậy họ có thể gọi bằng cách sử dụng Skype hoặc điện thoại. Do đó, vẫn có thông tin được chia sẻ và việc di chuyển task trên Scrum Board của họ có thể được thực hiện bởi một người nào khác từ team.

Tình huống 2: Đồng nghiệp có một ngày nghỉ. Trong trường hợp đó, team quyết định cùng nhau rằng họ không nhận một task quan trọng mà không chắc chắn rằng nó có thể được hoàn thành. Hoặc, đồng nghiệp đó phải đảm bảo rằng vào cuối ngày, ít nhất một người trong team biết những gì đã được thực hiện được. Bằng cách này, thông tin luôn được biết đến trong team và đồng nghiệp không bị quấy rầy trong ngày.

Điều này không liên quan gì đến vai trò của Scrum Master hoặc sử dụng Scrum tốt. Đây đơn giản chỉ là chuyên nghiệp!