Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười người mới làm Scrum Master rằng "công việc hằng ngày của bạn là gì?", có lẽ tám người sẽ trả lời: "Tôi đi remove impediments cho team." Câu trả lời đó vừa đúng vừa sai một cách nguy hiểm. Đúng, vì xử lý impediments là một phần quan trọng trong accountability của Scrum Master. Sai, vì rất nhiều người hiểu nhầm rằng Scrum Master là người trực tiếp đi giải quyết mọi vướng mắc, biến mình thành một kiểu "người chạy việc vặt" cao cấp cho Developers.
Trong kỳ thi PSM I, chủ đề impediments xuất hiện dưới nhiều dạng câu hỏi tinh vi: Ai là người nhận diện impediment? Ai là người remove? Daily Scrum có phải nơi để báo cáo impediment cho Scrum Master không? Impediment khác gì với một công việc khó bình thường? Nếu bạn không phân biệt được những ranh giới này, bạn sẽ chọn sai đáp án "by the book" — và quan trọng hơn, bạn sẽ làm sai vai trò ngoài đời thực.
Bài học này tập trung trọn vẹn vào impediments: định nghĩa chính xác theo tư duy Scrum, cách phân loại, ai chịu trách nhiệm gì, và một quy trình thực tế để nhận diện cũng như loại bỏ chúng. Đây là kỹ năng "cơm áo gạo tiền" của nghề Scrum Master, vì một team bị chặn đường liên tục sẽ không bao giờ đạt được Sprint Goal, dù họ có giỏi đến đâu.
Khái niệm cốt lõi
Impediment là gì?
Impediment (vật cản, chướng ngại) là bất kỳ thứ gì làm chậm lại hoặc chặn đứng (block) Scrum Team trên con đường tiến tới Sprint Goal hoặc Product Goal. Định nghĩa nghe có vẻ đơn giản, nhưng từ khóa nằm ở chỗ: nó phải gây ảnh hưởng đến tiến độ tạo ra giá trị, chứ không đơn thuần là một việc khó.
Hãy phân biệt rõ. Một đoạn code khó viết, một bug hóc búa, một bài toán kỹ thuật phức tạp — đó là công việc bình thường mà Developers được kỳ vọng phải xử lý. Đó là lý do họ tồn tại. Còn impediment là thứ nằm ngoài khả năng tự xử lý thông thường, hoặc là rào cản mang tính hệ thống ngăn họ làm việc hiệu quả. Ví dụ: máy chủ test bị sập ba ngày không ai sửa, một phòng ban khác không chịu cấp quyền truy cập dữ liệu, hoặc một quy trình phê duyệt rườm rà của công ty buộc mỗi lần deploy phải chờ trưởng phòng IT ký tay.
Cách phân biệt thực dụng: nếu đó là việc team có thể tự giải quyết trong phạm vi của họ thì đó là công việc; nếu nó cần can thiệp từ bên ngoài, phá vỡ một rào cản tổ chức, hoặc làm team đình trệ mà tự họ không gỡ được, thì đó là impediment.
Phân loại impediments
Để xử lý hiệu quả, bạn nên nhìn impediments theo các tầng:
1. Impediment cấp độ Team (Team-level) — phần lớn liên quan con người và kỹ thuật nội bộ. Đây là những vướng mắc nằm trong hoặc rất gần phạm vi của Scrum Team: xung đột giữa các thành viên, thiếu kỹ năng (ví dụ cả team không ai biết viết automated test), một thành viên bị kéo đi làm việc khác liên tục, hay công cụ nội bộ chậm chạp. Nhiều impediment loại này team có thể tự gỡ nếu được Scrum Master huấn luyện (coach) đúng cách.
2. Impediment cấp độ Tổ chức (Organizational-level). Đây là rào cản đến từ cấu trúc, quy trình hay văn hóa của công ty: chính sách bảo mật quá cứng nhắc, phòng ban "silo" không phối hợp, ngân sách bị đóng băng, môi trường staging dùng chung bị tranh giành giữa nhiều team. Loại này thường vượt quá tầm tay của một thành viên Developer, và đây chính là nơi Scrum Master phải bước ra ngoài team để tác động lên tổ chức.
3. Impediment cấp độ bên ngoài (External). Phụ thuộc vào nhà cung cấp thứ ba, đối tác chậm trễ, hay giấy phép phần mềm chưa được mua. Những thứ này khó kiểm soát hoàn toàn nhưng vẫn cần được làm cho minh bạch (transparent) và quản lý chủ động.
Ai làm gì với impediments?
Đây là phần dễ sai nhất trong kỳ thi PSM I, nên hãy ghi nhớ thật kỹ:
- Developers chịu trách nhiệm nhận diện và tự giải quyết các impediment trong phạm vi của họ. Một team self-managing không ngồi chờ Scrum Master gỡ mọi thứ. Daily Scrum chính là dịp họ phát hiện các vướng mắc đang đe dọa Sprint Goal.
- Scrum Master chịu trách nhiệm "gây ra việc loại bỏ những impediment cản trở tiến độ của Scrum Team" (theo nguyên văn Scrum Guide: causing the removal of impediments). Lưu ý cụm "gây ra việc loại bỏ" (causing the removal), chứ không phải "đích thân loại bỏ mọi thứ". Scrum Master tập trung vào những rào cản mà team không tự xử lý được, đặc biệt là rào cản tổ chức.
- Product Owner cũng có thể giúp gỡ những impediment liên quan đến stakeholder, ưu tiên hay quyết định về sản phẩm.
Tình huống thực tế
Tình huống 1 — Môi trường staging dùng chung tại một fintech ở TP.HCM
Một công ty fintech ở Quận 1, TP.HCM (tạm gọi là VietPay) có 4 Scrum Team cùng phát triển trên một sản phẩm ví điện tử. Cả 4 team chia sẻ duy nhất một môi trường staging để kiểm thử trước khi release. Mỗi khi một team deploy bản build mới lên staging, ba team còn lại bị "đứng hình" vì dữ liệu test bị ghi đè, đôi khi mất nửa ngày làm việc.
Một Developer trong team A vẫn coi đây là "chuyện thường ngày" và âm thầm chịu đựng suốt nhiều Sprint. Đến khi Scrum Master của team A — chị Hương — để ý thấy velocity của team giảm dần và trong Retrospective ai cũng than phiền về staging, chị mới gọi tên nó đúng bản chất: đây là một impediment cấp tổ chức, không phải vấn đề riêng của một team.
Chị Hương không tự đi dựng server. Thay vào đó, chị làm cho vấn đề trở nên minh bạch: thu thập số liệu (mỗi tuần cả 4 team mất tổng cộng khoảng 60 giờ làm việc vì xung đột staging), rồi mang con số đó đến gặp Giám đốc Công nghệ. Trước con số 60 giờ/tuần — tương đương lương của gần hai kỹ sư — ban lãnh đạo nhanh chóng duyệt ngân sách dựng thêm môi trường staging riêng cho từng team.
Bài học: Impediment lớn nhất thường bị "bình thường hóa" đến mức không ai gọi tên nó nữa. Vai trò của Scrum Master là phát hiện, làm minh bạch bằng dữ liệu, và tác động lên đúng cấp có thẩm quyền — chứ không phải tự tay làm thay.
Tình huống 2 — Quyền truy cập dữ liệu bị kẹt giữa hai phòng ban
Tại một công ty thương mại điện tử ở Hà Nội, team phát triển tính năng gợi ý sản phẩm cần truy cập kho dữ liệu hành vi người dùng do phòng Data quản lý. Developer đã gửi yêu cầu cấp quyền nhưng phòng Data trả lời "đang xem xét" suốt hai tuần. Sprint Goal có nguy cơ đổ vỡ.
Trong Daily Scrum, một Developer nêu vấn đề này. Anh Scrum Master tên Tuấn không nói "để anh gửi email giục họ giúp em". Thay vào đó, anh hỏi cả team: "Theo mọi người, mình có cách nào tự gỡ phần nào việc này không?" Team nhận ra họ có thể dùng tạm một tập dữ liệu mẫu đã được ẩn danh để tiếp tục phát triển logic, song song đó vẫn cần quyền truy cập thật để hoàn thiện. Phần "song song cần quyền truy cập" — vốn phụ thuộc vào một phòng ban khác — chính là impediment mà Tuấn đứng ra xử lý.
Tuấn lên gặp trực tiếp trưởng phòng Data, làm rõ tác động đến Sprint Goal và ngày release, và phát hiện gốc rễ: phòng Data sợ rủi ro pháp lý nên không dám cấp quyền. Anh kết nối hai bên với phòng Pháp chế để xác định ranh giới dữ liệu được phép dùng. Quyền truy cập được cấp sau hai ngày.
Bài học: Hãy phân tách impediment thành phần "team tự gỡ được" và phần "cần can thiệp bên ngoài". Khi xử lý phần bên ngoài, đừng dừng ở triệu chứng (giục cho nhanh) mà hãy đào tới gốc rễ (vì sao họ chần chừ).
Tình huống 3 — "Impediment" hóa ra là một bài toán kỹ thuật bình thường
Một startup giáo dục ở Đà Nẵng có Scrum Master mới vào nghề tên Linh. Mỗi khi Developer gặp một bug khó hay một thư viện khó tích hợp, họ đều ghi vào "danh sách impediment" và kỳ vọng Linh giải quyết. Danh sách ngày càng dài, Linh ngày càng quá tải, còn team thì dần mất khả năng tự xử lý vấn đề kỹ thuật.
Một Scrum Master kỳ cựu được mời về làm mentor đã chỉ ra: phần lớn những thứ trong danh sách không phải impediment, mà là công việc kỹ thuật bình thường nằm trong năng lực của Developers. Bằng cách "ôm" hết những việc này, Linh vô tình tước đi quyền tự quản (self-management) của team và biến mình thành nút thắt cổ chai.
Sau khi điều chỉnh, Linh đặt ra một câu hỏi sàng lọc cho mọi thứ được nêu: "Đây là việc team có thể tự làm với kỹ năng và quyền hạn hiện có không?" Nếu có, đó là công việc, và Linh chỉ coach để team tự gỡ. Chỉ những thứ vượt ra ngoài mới được coi là impediment thực sự.
Bài học: Không phải mọi khó khăn đều là impediment. Một Scrum Master ôm hết mọi vướng mắc sẽ làm team yếu đi, đi ngược lại tinh thần self-managing của Scrum.
Hướng dẫn từng bước
Dưới đây là một quy trình thực tế để nhận diện và loại bỏ impediments một cách có hệ thống:
Bước 1 — Tạo môi trường để impediment được nói ra (Transparency). Impediment chỉ có thể được gỡ khi nó được nhìn thấy. Hãy xây dựng văn hóa an toàn để Developers dám nêu vướng mắc mà không sợ bị đánh giá. Daily Scrum là một điểm chạm tự nhiên để các vướng mắc đe dọa Sprint Goal lộ ra, nhưng đừng giới hạn ở đó.
Bước 2 — Sàng lọc: đây có thật sự là impediment không? Áp dụng câu hỏi: "Team có thể tự gỡ việc này với kỹ năng và quyền hạn hiện có không?" Nếu có, để team tự xử lý (bạn coach nếu cần). Nếu không, nó là impediment cần được quản lý.
Bước 3 — Phân loại và đánh giá mức độ ảnh hưởng. Xác định impediment thuộc cấp Team, Tổ chức hay External. Đánh giá nó ảnh hưởng thế nào đến Sprint Goal/Product Goal, và mức độ khẩn cấp. Một số impediment chặn đứng (blocker) cần xử lý ngay; một số chỉ làm chậm và có thể đưa vào kế hoạch dài hơi hơn.
Bước 4 — Làm cho impediment minh bạch và có thể theo dõi. Nhiều team dùng một "Impediment Backlog" hoặc một cột riêng trên bảng Scrum để hiển thị các impediment đang mở, ai đang xử lý và trạng thái. Việc này giúp không vướng mắc nào bị rơi vào quên lãng.
Bước 5 — Đào tới gốc rễ trước khi hành động. Đừng vội xử lý triệu chứng. Dùng kỹ thuật như "5 Whys" (hỏi "tại sao" nhiều lần) để hiểu nguyên nhân sâu xa. Như tình huống phòng Data ở trên: gốc rễ là nỗi sợ rủi ro pháp lý, không phải sự lười biếng.
Bước 6 — Hành động đúng vai. Với impediment cấp tổ chức, Scrum Master tác động lên tổ chức: thuyết phục bằng dữ liệu, kết nối đúng người, làm việc với lãnh đạo. Với impediment cấp team, ưu tiên coach để team tự gỡ, nuôi dưỡng năng lực tự quản.
Bước 7 — Theo dõi và rút kinh nghiệm. Sau khi gỡ xong, kiểm tra xem nó đã thực sự được giải quyết hay chỉ tạm lắng. Những impediment lặp đi lặp lại nên được đưa vào Sprint Retrospective để team tìm cách cải tiến quy trình, ngăn chúng tái diễn.
Lỗi thường gặp & mẹo
Lỗi 1 — Scrum Master tự ôm hết mọi impediment. Đây là cái bẫy phổ biến nhất. Khi bạn giải quyết thay mọi thứ, team mất khả năng tự quản và bạn thành nút thắt cổ chai. Mẹo: hãy hỏi "team có tự gỡ được không?" trước khi nhảy vào.
Lỗi 2 — Nhầm công việc khó với impediment. Một bug hóc búa hay một bài toán kỹ thuật phức tạp là công việc của Developers, không phải impediment. Đừng để danh sách impediment phình to vì những thứ vốn dĩ là trách nhiệm của team.
Lỗi 3 — Coi Daily Scrum là buổi báo cáo impediment cho Scrum Master. Daily Scrum là của Developers, để họ inspect tiến độ và adapt kế hoạch. Impediment có thể lộ ra ở đây, nhưng đây không phải phiên "báo cáo sếp". Đề thi PSM I rất hay gài bẫy ở điểm này.
Lỗi 4 — Chỉ xử lý triệu chứng. Giục cho nhanh, vá tạm rồi để đó. Impediment sẽ quay lại. Hãy đào gốc rễ.
Mẹo nhớ cho kỳ thi: Ghi nhớ cụm "causing the removal of impediments" — Scrum Master gây ra việc loại bỏ, không phải đích thân làm mọi thứ. Và Scrum Master xử lý những impediment cản trở tiến độ của Scrum Team, đặc biệt khi chúng vượt khỏi tầm tay team.
Mẹo thực hành: Duy trì một Impediment Backlog hiển thị công khai. Sự minh bạch này vừa giúp theo dõi, vừa tạo áp lực tích cực để mọi impediment được quan tâm.
Bài tập thực hành
- Phân loại nhanh. Với mỗi tình huống sau, hãy xác định đó là (a) công việc bình thường của Developers, (b) impediment cấp team, hay (c) impediment cấp tổ chức: (1) Một thư viện mã nguồn mở khó tích hợp; (2) Một thành viên team liên tục bị quản lý bộ phận khác kéo đi làm việc khác; (3) Quy trình duyệt deploy của công ty buộc chờ chữ ký tay trong 3 ngày; (4) Cả team không ai biết viết unit test.
- Đào gốc rễ. Chọn một vướng mắc thực tế trong công việc của bạn (hoặc tình huống staging ở Tình huống 1). Áp dụng kỹ thuật "5 Whys" để truy ra nguyên nhân gốc rễ. Viết ra chuỗi 5 câu "tại sao".
- Đóng vai. Một Developer trong Daily Scrum nói: "Em bị block vì chưa có quyền truy cập database từ phòng Data." Hãy viết ra phản hồi của bạn với tư cách Scrum Master, thể hiện được việc: (a) khuyến khích team tự gỡ phần làm được, và (b) nhận lấy phần cần can thiệp bên ngoài.
- Tự kiểm tra hiểu biết: Theo Scrum Guide, ai chịu trách nhiệm "causing the removal of impediments"? Và điều đó có đồng nghĩa với việc người đó phải đích thân giải quyết mọi vướng mắc không? Giải thích.
Tóm tắt
- Impediment là bất kỳ thứ gì làm chậm hoặc chặn đứng Scrum Team trên đường tới Sprint Goal hoặc Product Goal — khác với công việc khó bình thường, vốn là trách nhiệm của Developers.
- Impediments có thể chia theo cấp Team, Tổ chức và External; cách xử lý mỗi cấp khác nhau.
- Developers nhận diện và tự gỡ những gì trong tầm tay; Scrum Master chịu trách nhiệm "gây ra việc loại bỏ" (causing the removal) những impediment vượt khỏi tầm team, đặc biệt là rào cản tổ chức — chứ không phải đích thân làm mọi thứ.
- Quy trình thực tế: tạo minh bạch → sàng lọc → phân loại → theo dõi công khai → đào gốc rễ → hành động đúng vai → rút kinh nghiệm trong Retrospective.
- Tránh ba cái bẫy lớn: ôm hết mọi việc, nhầm việc khó với impediment, và chỉ xử lý triệu chứng.
- Cho kỳ thi PSM I: nhớ rằng Daily Scrum không phải buổi báo cáo impediment, và Scrum Master nuôi dưỡng năng lực tự quản của team thay vì làm thay.