I. ScrumBut là gì?

“ScrumBut” (ghép từ “Scrum, but” – Scrum, nhưng…) là thuật ngữ chỉ việc một nhóm tuyên bố áp dụng Scrum nhưng lại loại bỏ hoặc sửa đổi một số thành phần cốt lõi của Scrum. Theo Scrum.org, ScrumBut có nghĩa là “Scrum đã phơi bày một điểm yếu gây ra vấn đề, nhưng điểm yếu đó quá khó sửa nên nhóm đã thay đổi Scrum để che giấu nó. ScrumBut giữ lại vấn đề đó và điều chỉnh Scrum nhằm làm cho điểm yếu không còn lộ ra, không còn là cái gai với đội nữa”. Nói cách khác, khi gặp khó khăn với một quy tắc hay sự kiện của Scrum, thay vì giải quyết tận gốc, đội nhóm chọn cách “Chúng tôi làm Scrum, nhưng…” – bỏ qua hoặc tùy biến quy tắc đó – khiến Scrum bị “bẻ cong” và không còn nguyên vẹn.

Thuật ngữ ScrumBut được sử dụng trong cộng đồng Agile từ những năm 2000. Có tài liệu cho rằng Ken Schwaber – đồng sáng lập Scrum – đã dùng từ này để mô tả việc cố tình “bẻ luật” Scrum hòng né tránh sự thật đau đớn mà Scrum phơi bày. Chuyên gia Agile Mike Cohn cũng phổ biến khái niệm này; ông mô tả ScrumBut bằng những ví dụ như: “Chúng tôi theo Scrum nhưng… không họp đứng hàng ngày”, “…nhưng Sprint kéo dài 3 tháng”, “…nhưng [một ngoại lệ nào đó]”. Tựu trung, ScrumBut mang hàm ý tiêu cực, ám chỉ việc vận dụng Scrum nửa vời, thiếu các yếu tố then chốt, dẫn đến mất đi lợi ích vốn có của Scrum. Thậm chí Scrum Guide nhấn mạnh rằng các vai trò, sự kiện, tạo tác và quy tắc của Scrum là không thể thay đổi – nếu chỉ áp dụng một phần thì “không còn gọi là Scrum” đúng nghĩa.

Đọc thêm: https://www.scrum.org/resources/what-scrumbut

II. Những biểu hiện phổ biến của ScrumBut

Trong thực tế, ScrumBut thể hiện qua nhiều “triệu chứng” quen thuộc. Dưới đây là một số ví dụ điển hình mà Scrum.org đã chỉ ra:

• Bỏ họp Daily Scrum: “Chúng tôi dùng Scrum, nhưng họp hằng ngày tốn thời gian, nên chỉ họp mỗi tuần một lần.”. Đây là dấu hiệu đội cảm thấy họp mỗi ngày “quá nhiều” – thường do chưa phân chia công việc hiệu quả hoặc họp sai cách, biến Daily Scrum thành cuộc họp dài dòng, mất thời gian. Dần dần, nhóm bỏ bớt tần suất họp, đánh mất cơ hội đồng bộ hằng ngày và phát hiện sớm trở ngại.
• Không tổ chức Sprint Retrospective: “Chúng tôi theo Scrum, nhưng Sprint Retrospective tốn thời gian vô ích, nên chúng tôi bỏ qua luôn.”. Việc coi thường buổi hồi nghiệm khiến nhóm mất đi cơ hội cải tiến liên tục, các vấn đề nội tại không được giải quyết và có xu hướng lặp lại.
• Kéo dài hoặc thay đổi độ dài Sprint thất thường: “Chúng tôi làm Scrum, nhưng không thể hoàn thành chức năng trong một tháng, nên Sprint của chúng tôi dài 6 tuần.”. Việc tự ý kéo dài Sprint cho “dễ thở” thực chất làm mất đi tính nhịp nhàng và khả năng kiểm chứng, thích ứng nhanh của Scrum. Tương tự, nếu độ dài Sprint thay đổi liên tục, đội sẽ khó dự báo và cải thiện năng lực.
• Không tuân thủ Definition of Done: “Chúng tôi áp dụng Scrum, nhưng đôi khi sếp giao việc đột xuất, nên không phải lúc nào cũng kịp Done toàn bộ như đã định.”. Biểu hiện này cho thấy nhóm chấp nhận không hoàn tất mọi tiêu chí chất lượng trong mỗi Increment, thường do sức ép bên ngoài hoặc quy trình chưa tối ưu, dẫn đến chất lượng giảm sút và nợ kỹ thuật tích lũy.
• Thiếu Scrum Master hoặc Product Owner đúng nghĩa: Một ví dụ khác là Scrum thiếu vai trò quan trọng. Chẳng hạn, một số công ty bảo “nhóm tôi làm Scrum nhưng… không có Scrum Master (để tiết kiệm chi phí hoặc dùng quản lý dự án thay thế)”. Atlassian – công ty đứng sau Jira – khẳng định không có Scrum Master thì không thể gọi là Scrum “đúng chuẩn”, và những biến thể như vậy được xem là ScrumBut. Tương tự, nếu Product Owner bị thay bằng ủy ban hoặc không có quyền quyết định, nhóm sẽ thiếu định hướng sản phẩm rõ ràng – dấu hiệu ScrumBut rõ rệt.
• Nhóm không thực sự đa chức năng: Ví dụ: “Chúng tôi làm Scrum, nhưng nhóm dev của tôi chỉ code, còn phần kiểm thử do nhóm QA khác làm ở Sprint sau”. Đây là dạng “mini Waterfall” trá hình: công việc vẫn theo tuyến tính (phân tích -> phát triển -> kiểm thử tách biệt) thay vì tích hợp trong một Sprint. Kết quả là Sprint không tạo được Increment hoàn chỉnh, và nhóm mất đi tính liên chức năng vốn là nguyên tắc của Scrum.

Ngoài các biểu hiện trên, còn nhiều anti-pattern khác như: không có Sprint Goal rõ ràng, thường xuyên thêm/xóa việc giữa chừng Sprint, không Refinement backlog, Sprint Review chỉ trình chiếu nội bộ thay vì nhận phản hồi khách hàng, v.v. Bất cứ sai lệch nào làm suy yếu nguyên tắc Scrum đều có thể xem là ScrumBut.

III. Nguyên nhân các nhóm rơi vào ScrumBut

Vì sao các nhóm lại trượt vào “vũng lầy” ScrumBut? Có nhiều nguyên nhân dẫn đến việc này:

• Thiếu hiểu biết hoặc hiểu lầm về Scrum: Scrum tuy gọn nhẹ và dễ hiểu lý thuyết, nhưng khó tinh thông khi áp dụng thực tế. Nhiều nhóm đọc chưa kỹ Scrum Guide hoặc bỏ qua một số phần, dẫn đến vận dụng sai lệch. Hiểu sai về bản chất Agile (ví dụ: nghĩ rằng Scrum cứng nhắc, không cho phép linh hoạt) cũng khiến họ tuỳ tiện bẻ cong Scrum.
• Văn hóa tổ chức và lãnh đạo: Đôi khi quản lý cấp cao không hiểu hết vai trò của từng thành phần Scrum nên cố tình đơn giản hóa cho “đỡ rườm rà” – ví dụ bỏ họp retro, hay không trao quyền cho đội tự tổ chức. Một số lãnh đạo coi một vài thực hành Scrum là thứ yếu có thể cắt giảm, trong khi thực tế các vai trò, sự kiện, tạo tác Scrum liên kết chặt chẽ để cùng đạt mục tiêu giá trị. Sức ép từ khách hàng hoặc sếp cũng có thể buộc nhóm phá vỡ kỷ luật Scrum (như nhảy việc đột xuất vào Sprint).
• Áp dụng Scrum không đúng bối cảnh: Scrum thiết kế cho việc phát triển sản phẩm phức tạp. Nếu dùng Scrum cho dự án quá nhỏ hoặc công việc không phù hợp, nhóm dễ cảm thấy một số nghi thức “quá nặng” rồi cắt bỏ bớt. Scrum không phải giải pháp vạn năng – dùng không đúng chỗ sẽ dẫn tới ScrumBut (ví dụ: dự án chỉ chỉnh sửa vài trang web tĩnh có thể không cần đủ mọi ceremony).
• Ngại đối mặt với vấn đề khó khăn: Một đặc điểm cốt lõi của Scrum là làm lộ rõ các vướng mắc (minh bạch để cải tiến). Tuy nhiên, khi vấn đề lộ ra mà nhóm không đủ khả năng hoặc dũng khí xử lý, họ sẽ bị cám dỗ “né tránh đau đớn” bằng cách loại bỏ luôn thực hành Scrum liên quan. Scrum.org nhận định: ScrumBut thường xuất hiện khi Scrum bộc lộ một bất cập nhưng đội “chịu thua” không khắc phục được, đành thay đổi Scrum để che đi điểm yếu đó. Ví dụ, nếu nhóm liên tục không hoàn thành công việc mỗi Sprint, thay vì học cách chia nhỏ và lập kế hoạch tốt hơn, họ có thể tăng thời gian Sprint lên hoặc bỏ qua Sprint Goal – một kiểu “tránh né” vấn đề năng lực.
• Thiếu kiên trì và kỷ luật Scrum: Scrum đòi hỏi tính kỷ luật cao trong việc tuân thủ các cam kết, giá trị (Tập trung, Cởi mở, Cam kết, Tôn trọng, Can đảm). Nếu đội thiếu cam kết cải tiến liên tục, các buổi retrospective chỉ nêu vấn đề nhưng không thực sự hành động, thì dần dần Scrum cũng mất hiệu lực. Sự “dễ dãi” (như ScrumMaster của ví dụ dưới thừa nhận “một lần cho qua kéo theo nhiều lần khác”) sẽ tích tụ các sai lệch nhỏ thành ScrumBut lớn.

Tóm lại, ScrumBut thường báo hiệu một điểm yếu hoặc hạn chế của đội/tổ chức. Thay vì giải quyết gốc rễ (đòi hỏi kiến thức, thời gian, sự thay đổi), người ta chọn giải pháp nhanh là bỏ qua phần Scrum làm lộ vấn đề đó. Đây là cách xử lý triệu chứng thay vì chữa bệnh, lâu dài sẽ gây hại.

IV.Tác hại của ScrumBut

ScrumBut được ví như một phiên bản Scrum “loãng” (diluted Scrum) và tất nhiên là mang lại hệ quả tiêu cực. Việc chỉ áp dụng một phần Scrum, bỏ qua những thành phần “khó nhằn”, sẽ làm suy yếu các lợi ích mà Scrum mang lại. Một số tác hại và rủi ro chính gồm:

• Hiệu suất và quy trình kém hiệu quả: Bởi vì thiếu những cơ chế chuẩn của Scrum để kiểm soát và cải tiến, nhóm ScrumBut thường gặp trở ngại lặp đi lặp lại. Ví dụ, bỏ họp Daily nghĩa là vấn đề tích tụ không được giải quyết nhanh, lỗi lặp lại lỗi, tiến độ chậm mà không rõ nguyên nhân. Bỏ Sprint Retrospective dẫn đến đội dẫm chân tại chỗ, không tối ưu được quy trình làm việc.
• Giảm tính minh bạch: Scrum nhấn mạnh minh bạch (transparency) về công việc và tiến độ. Khi ScrumBut, nhiều thông tin không còn được hiển thị công khai hoặc cập nhật thường xuyên. Ví dụ, không họp đều đặn, không cập nhật Sprint backlog, hoặc định nghĩa “Hoàn thành” bị nới lỏng – tất cả làm mờ đi bức tranh thật về trạng thái dự án, khiến quản lý rủi ro kém hơn. ScrumBut về bản chất “che giấu” vấn đề thay vì phơi bày, nên đội lẫn stakeholder đều mất đi sự minh bạch cần thiết.
• Suy giảm cam kết và tinh thần cải tiến: Khi các nguyên tắc Scrum bị xem nhẹ, tinh thần kỷ luật và cam kết của đội cũng suy giảm. Ví dụ, nếu nhóm quen với việc không hoàn thành Sprint mà không ai nhắc nhở, họ sẽ chai lỳ với thất bại, không còn phấn đấu cải thiện năng lực. Việc “Scrum nhưng bỏ qua cải tiến” đi ngược với triết lý Inspect & Adapt, dẫn tới một đội ì ạch, thiếu động lực vươn lên.
• Ảnh hưởng giá trị cốt lõi Scrum: Scrum dựa trên 5 giá trị: Tập trung, Can đảm, Cởi mở, Tôn trọng, Cam kết. ScrumBut thường bào mòn những giá trị này. Chẳng hạn, bỏ qua cam kết “Hoàn thành thật sự” (định nghĩa Done) có thể khiến đội đánh mất sự Tôn trọng với chất lượng, hoặc việc né tránh hồi nghiệm cho thấy thiếu Can đảm nhìn nhận sai sót. Lâu dần, văn hóa đội nhóm sẽ lệch lạc, mất niềm tin vào quy trình Agile.
• Kết quả sản phẩm kém chất lượng và giá trị: Tất cả các yếu tố trên cuối cùng dẫn đến sản phẩm giao kém hơn mong đợi. Thiếu kiểm thử sớm, thiếu Done chuẩn => chất lượng giảm, nhiều lỗi lọt ra ngoài. Thiếu tương tác khách hàng (do Sprint Review hình thức) => sản phẩm lệch hướng giá trị thực. Chu kỳ phản hồi dài (do Sprint kéo dài hoặc không họp thường xuyên) => chậm thích nghi thị trường. Nhiều tổ chức sau một thời gian làm ScrumBut sẽ kết luận sai lầm rằng “Scrum/Agile không hiệu quả”, trong khi nguyên nhân là họ chưa thực sự làm đúng Scrum.

Nói ngắn gọn, ScrumBut “lợi bất cập hại”: đội tưởng rằng bớt đi vài nghi thức sẽ nhanh hơn hoặc đỡ tốn công. Nhưng thực tế, việc đó gây hậu quả nghiêm trọng về dài hạn: quy trình kém hiệu quả, chất lượng thấp, đội ngũ không cải tiến và đánh mất những lợi ích vốn có của Scrum. ScrumBut phá vỡ tính toàn vẹn của Scrum, khiến Scrum không còn phát huy được ưu điểm như thiết kế ban đầu.

V. Thực hành Scrum “đúng chuẩn” để tránh ScrumBut

Vậy làm thế nào để tránh rơi vào bẫy ScrumBut? Câu trả lời cốt lõi là: hãy thực hành Scrum một cách kỷ luật và trọn vẹn, đồng thời sử dụng những phương pháp bổ trợ thay vì tùy tiện thay đổi Scrum. Dưới đây là một số hướng dẫn chi tiết:

• Tuân thủ đầy đủ các vai trò, sự kiện, tạo tác Scrum như trong Scrum Guide: Đảm bảo nhóm có đủ ba vai trò Scrum Master, Product Owner, Developers với trách nhiệm rõ ràng. Scrum Master cần được trao quyền dẫn dắt quy trình Scrum, gỡ impediment; Product Owner phải có tiếng nói quyết định backlog. Tổ chức không nên cắt bỏ hay gộp các vai trò này – nếu không, như đã nói, đó không còn là Scrum đúng nghĩa. Tương tự, mọi sự kiện Scrum (Sprint Planning, Daily Scrum, Sprint Review, Retrospective) nên được thực hiện đầy đủ và đúng mục đích, không rút ngắn hoặc bỏ qua tùy tiện. Sprint nên có độ dài cố định (1-4 tuần) phù hợp và không đổi liên tục. Việc tuân thủ “đủ bộ” này giúp nhóm nhận được toàn bộ lợi ích của Scrum, vì mỗi thành phần đều phục vụ một mục đích nhất định.
• Nâng cao hiểu biết và ý thức về Scrum trong đội ngũ: Mỗi thành viên nên nắm vững nguyên lý Agile và Scrum Guide, hiểu tại sao cần vai trò/sự kiện đó. Hãy nhớ câu nói nổi tiếng: “Scrum rất đơn giản, nhưng làm Scrum thì không dễ”. Đội ngũ cần khiêm tốn học hỏi, đừng tự ý bỏ luật chỉ vì chưa hiểu thấu. Nếu có thể, hãy đào tạo hoặc nhờ cố vấn Agile để giúp cả team thấm nhuần tư tưởng Agile, tránh hiểu sai dẫn đến làm sai.
• Dũng cảm đối mặt và giải quyết tận gốc vấn đề: Thay vì “giấu bụi dưới thảm” bằng ScrumBut, nhóm hãy dùng chính Scrum để cải thiện. Mỗi khi Scrum phơi bày một điểm yếu (không kịp tiến độ, chất lượng kém, họp kém hiệu quả…), hãy coi đó là cơ hội để học và sửa. Ví dụ, nếu Daily Scrum đang dài dòng, hãy học cách đứng họp, tập trung vào kế hoạch 24 giờ tới thay vì bỏ họp. Nếu đội khó hoàn thành Sprint, có thể cần chẻ nhỏ user story, ước lượng lại hoặc giúp đỡ chéo thay vì tăng thời gian Sprint. Tinh thần Kaizen (cải tiến liên tục) cần được đề cao: vấn đề lộ ra phải được bàn cách giải quyết, đưa vào action items sau mỗi Retrospective và theo dõi đến khi hoàn thành.
• Đảm bảo “Definition of Done” rõ ràng và luôn được tuân thủ: Definition of Done (Định nghĩa Hoàn thành) giúp giữ chất lượng và tính hoàn thiện của sản phẩm mỗi Sprint. Đội nên cùng nhau xây dựng một DoD chặt chẽ, bao gồm các tiêu chí về chức năng lẫn phi chức năng (đã qua kiểm thử chức năng, hiệu năng, tài liệu cập nhật, v.v.). Quan trọng hơn, đừng thỏa hiệp với DoD – mọi PBI đưa vào Sprint phải đạt DoD mới gọi là “Hoàn thành”. Nếu ban đầu chưa thể đáp ứng hết (ví dụ tự động hóa test cần thời gian), có thể tạm chấp nhận thiếu sót như một ngoại lệ ngắn hạn nhưng phải lập kế hoạch cải thiện sớm nhất. Việc luôn bám sát DoD giúp tránh được ScrumBut về chất lượng, không để lại nợ mà ẩn dưới tấm thảm.
• Thực hành kỹ thuật “Shift-Left” – đưa kiểm thử và chất lượng về sớm: Một trong những sai lầm ScrumBut thường gặp là để khâu kiểm thử/trải nghiệm người dùng sang cuối mỗi Sprint hoặc cuối dự án (gần giống Waterfall). Để tránh điều này, hãy áp dụng tư duy Shift-Left: dịch chuyển các hoạt động đảm bảo chất lượng sớm của dòng thời gian dự án. Nói cách khác, kiểm thử sớm và thường xuyên ngay từ khi thiết kế và phát triển chứ không đợi tới giai đoạn cuối. Bảng dưới đây tóm tắt sự khác biệt giữa cách làm Waterfall truyền thống và cách tiếp cận Shift-Left trong Agile/Scrum:

Áp dụng Shift-Left trong Scrum có nghĩa là: tester tham gia ngay từ Sprint Planning, cùng developer viết kịch bản test; áp dụng kỹ thuật như Test-Driven Development, tích hợp liên tục (CI); kiểm thử tự động chạy hằng ngày. Như vậy, chất lượng được đảm bảo ngay trong quá trình thay vì dồn cuối. So sánh trên cho thấy: khi chuyển từ Waterfall sang Shift-Left, nhóm sẽ bắt lỗi sớm hơn, giảm chi phí sửa lỗi và nâng cao độ tin cậy của phần mềm. Đây chính là cách để tránh kiểu ScrumBut “nước đôi” – làm Scrum nhưng vẫn theo tư duy Waterfall. Hãy đảm bảo mỗi Sprint tạo ra sản phẩm “Hoàn thành” thật sự, có chất lượng sẵn sàng phát hành.

• Thêm chứ đừng bớt – thực hành “ScrumAnd”: Scrum rất linh hoạt cho phép đội bổ sung những thực hành tốt khác miễn là không phá vỡ các nguyên tắc cơ bản (cách tiếp cận được cộng đồng gọi là “ScrumAnd”). Ví dụ, một nhóm Scrum có thể thêm Kanban để quản lý luồng công việc hàng ngày (Scrum và Kanban), hoặc thêm các thực hành Extreme Programming (pair programming, code review, CI/CD) để nâng cao chất lượng. Những bổ sung này không mâu thuẫn mà còn hỗ trợ Scrum, giúp đội làm việc hiệu quả hơn. Ngược lại, tránh việc tùy tiện cắt giảm Scrum khi chưa thực sự hiểu rõ hậu quả. Như chuyên gia Cory Foy từng cảnh báo: “Khi chưa đủ kinh nghiệm, nếu vội vàng cắt xén thì không chỉ hại cho đội của bạn mà còn làm tổn hại cả ngành phần mềm”. Vì vậy, hãy tuân thủ Scrum một thời gian đủ lâu để hiểu giá trị của từng thành phần trước khi nghĩ đến việc điều chỉnh. Nếu cần, hãy trao đổi với Coach Agile hoặc cộng đồng để tìm giải pháp thay thế an toàn (ví dụ dùng Scrum với Kanban cho trường hợp đặc biệt, thay vì tự ý bỏ Sprint như ví dụ ở trên).
• Giám sát và ngăn ngừa dấu hiệu ScrumBut sớm: Scrum Master nên đóng vai trò “người gác cổng” quy trình. Luôn tự hỏi: “Chúng ta có đang nói ‘Chúng ta Scrum nhưng…’ ở điểm nào không?”. Nếu thấy bắt đầu có câu chuyện kiểu “Thôi khỏi họp retro lần này nhé” hoặc “team mình Scrum nhưng không cần SM đâu”… thì đó là dấu hiệu cảnh báo. Hãy nhanh chóng đưa vấn đề ra ánh sáng – ví dụ nhắc nhở trong retro hoặc trao đổi riêng với team – trước khi thói quen xấu thành tiêu chuẩn ngầm. Văn hóa cởi mở (một giá trị Scrum) rất quan trọng: mọi người phải cảm thấy thoải mái chỉ ra “đây có phải ScrumBut không?” khi thấy quy trình có dấu hiệu chệch hướng.

Tóm lại, cách tốt nhất để tránh ScrumBut là hiểu đúng và làm đúng Scrum ngay từ đầu. Điều này không có nghĩa Scrum là cứng nhắc – bạn vẫn có thể linh hoạt cải tiến, nhưng hãy cải tiến trên nền tảng tôn trọng các nguyên lý đã được kiểm chứng của Scrum. Khi đội đã thành thục, có thể tinh chỉnh cho phù hợp bối cảnh, nhưng nên dựa trên hiểu biết sâu sắc và dựa trên dữ liệu thay vì cảm tính. Và một khi đã nhận ra mình lỡ sa đà vào ScrumBut, can đảm “làm mới” Scrum – quay lại căn bản, huấn luyện lại đội và cam kết thay đổi.