Scrum Thất Bại: Bi kịch của một Quy trình bị Áp đặt và Hiểu sai

Khi Ban Giám đốc muốn "Agile", tuyển về một chuyên gia 20 năm kinh nghiệm, nhưng sau một năm, mọi thứ còn tệ hơn trước. Một câu chuyện về việc áp dụng máy móc một quy trình mà không thay đổi tư duy.

Sơ đồ mô tả sự thất bại của việc áp dụng Scrum máy móc trong một môi trường Waterfall

Lời Mở đầu: Người Gác đền Cô độc của Pháo đài Monolith

Trong thế giới phát triển phần mềm, Agile và Scrum được ví như những viên đạn bạc, là câu trả lời cho mọi vấn đề về tốc độ, sự linh hoạt và hiệu suất. Các công ty áp dụng và tuân thủ nghiêm ngặt phương pháp Agile gặt hái vô số lợi ích, trong đó lợi ích hàng đầu và được quan tâm nhất chính là sự hài lòng của khách hàng. Các dự án được thực thi theo Agile luôn đặt khách hàng làm trung tâm của mọi thứ.

Ban lãnh đạo của công ty tôi cũng bị cuốn vào giấc mơ đó. Họ muốn "Agile". Họ muốn marketing rằng chúng tôi là những người nhiệt thành với Agile. Nhưng sau một năm nỗ lực chuyển đổi, khách hàng (nội bộ) của chúng tôi không hề hạnh phúc hơn. Đó là lúc chúng tôi phải dừng lại và tự vấn: Liệu chúng tôi có đang mắc kẹt trong "Agile Giả" (Fake Agile)?

Câu chuyện của tôi bắt đầu từ nhiều năm trước, khi tôi kiên trì vận hành phòng IT theo mô hình Waterfall một cách có chủ đích. Rồi họ quyết định đã đến lúc phải thay đổi. Họ tuyển về một IT Manager mới, một người có 20 năm kinh nghiệm dày dạn, với một nhiệm vụ duy nhất: biến chúng tôi thành một tổ chức Agile/Scrum đúng nghĩa.

Một năm sau, khi vị manager đó rời đi, chúng tôi còn lại một mớ hỗn độn. Các buổi họp "stand-up" vẫn diễn ra, các "sprint" vẫn được lên kế hoạch, nhưng kết quả cuối cùng không khá hơn, thậm chí còn tệ hơn. Tốc độ không tăng, chất lượng không cải thiện, và sự thất vọng bao trùm. Chúng tôi đã áp dụng Scrum, và chúng tôi đã thất bại thảm hại.

Bài viết này là nỗ lực của tôi để mổ xẻ bi kịch đó. Tại sao một quy trình được cả thế giới ca ngợi lại thất bại tại công ty chúng tôi? Câu trả lời không nằm ở bản thân Scrum, mà nằm ở sự hiểu sai sâu sắc về bản chất của nó, và ở những vấn đề cố hữu trong văn hóa tổ chức mà không một quy trình nào có thể tự mình sửa chữa.

Phần I: Agile là một Tư duy, không phải một Quy trình Máy móc

Mỗi người thực sự am hiểu về phát triển Agile đều đồng ý rằng: trở nên Agile là một sự thay đổi về tư duy (mindset). Nó là sự sẵn lòng của cả một tổ chức trong việc kiến tạo sản phẩm dựa trên sự phản hồi liên tục từ người dùng cuối. Rất nhiều công ty tự nhận mình "Agile" thực chất chỉ là "Agile In Name Only" (AINO) – Agile trên danh nghĩa. Họ chỉ đơn thuần triển khai các quy trình và nghi lễ của Agile mà không thực sự thay đổi tư duy.

Ví dụ, nếu bạn đang dùng JIRA để quản lý dự án nhưng không có bất kỳ sự tham gia nào của người dùng cuối trong quá trình phát triển, đó là một dấu hiệu rõ ràng của Agile Giả.

Câu hỏi lớn nhất hiện ra trong đầu bạn lúc này chắc chắn là: Làm thế nào để Nhận diện Agile Giả?

Không có một công thức cố định nào, vì nó liên quan đến tư duy, nên cần phải quan sát văn hóa làm việc. Tuy nhiên, có những lá cờ đỏ rất rõ ràng:

Không có sự giao tiếp/phản hồi giữa đội ngũ phát triển và người dùng (không có báo cáo lỗi, không có đánh giá từ người dùng...). Người dùng cuối không hề tham gia vào các quy trình như nghiệm thu (UAT) hay lên kế hoạch cho phiên bản mới.
Thiếu sự phối hợp và giao tiếp giữa các bên liên quan như khách hàng, quản lý dự án, lập trình viên, thiết kế, và kiểm thử.
Không có văn hóa DevOps. Phụ thuộc hoàn toàn vào các quy trình thủ công thay vì kiểm thử tự động hay tích hợp/triển khai liên tục (CI/CD).
Ưu tiên việc "đáp ứng đủ yêu cầu" trong tài liệu hơn là "mang lại một thứ gì đó hữu ích" cho khách hàng.

Trước khi vị manager mới đến, tôi đã lựa chọn Waterfall một cách có chủ đích, không phải vì tôi lạc hậu. Đó là một quyết định thực dụng, dựa trên việc chẩn đoán chính xác "căn bệnh" của môi trường làm việc lúc bấy giờ, một môi trường hoàn toàn đối nghịch với các giá trị Agile.

Môi trường của chúng tôi có 3 đặc điểm "bất di bất dịch":

"Product Owner Bóng ma": Tuyên ngôn Agile đặt Product Owner (PO) làm trung tâm. Ở công ty tôi, vai trò này do chính CEO nắm giữ. Bà có tầm nhìn, nhưng lại thường xuyên vắng mặt. Việc chờ đợi một câu trả lời có thể mất hàng tuần. Trong bối cảnh đó, Waterfall, với việc "đóng băng" yêu cầu từ đầu, lại là cách duy nhất để đội ngũ có thể làm việc mà không bị gián đoạn.

"Nhà tù Hợp đồng": Ban Giám đốc (BOD) của chúng tôi muốn phạm vi, thời gian và chi phí cố định ngay từ đầu, và KPI của IT được tính dựa trên các hợp đồng nội bộ. Đây chính là bản chất của hợp đồng Waterfall, hoàn toàn trái ngược với sự linh hoạt về phạm vi của Agile.

"Người dùng Thầm lặng": Agile sống bằng vòng lặp phản hồi. Nhưng người dùng của chúng tôi – các phòng ban nội bộ – lại từ chối tham gia. Họ quá bận để tham gia demo, và các phản hồi thường đến một cách tiêu cực, dưới dạng những lời phàn nàn trong các nhóm chat riêng, thay vì góp ý mang tính xây dựng.

Trong một môi trường như vậy, Waterfall không phải là lựa chọn lý tưởng, mà là lựa chọn bắt buộc và ít tồi tệ nhất. Nó cho đội ngũ một bộ yêu cầu rõ ràng để bám vào, giảm thiểu sự phụ thuộc vào các bên liên quan vốn không sẵn sàng hợp tác.

Phần II: Màn kịch Scrum – Khi Hình thức Thay thế cho Bản chất

Khi vị manager mới với 20 năm kinh nghiệm Scrum đến, ông mang theo các nghi lễ: Sprint Planning, Daily Stand-up, Sprint Review, Retrospective. Bảng Kanban được thay thế bằng bảng Scrum. Về mặt hình thức, chúng tôi trông rất "Agile". Nhưng chỉ sau vài tháng, những vết nứt bắt đầu xuất hiện. Màn kịch Scrum đang được diễn ra, nhưng vở kịch thực sự vẫn là Waterfall.

Sprint Planning trở thành Buổi giao việc Áp đặt: Thay vì cả team cùng nhau thảo luận, các buổi họp này biến thành nơi BOD đưa ra một danh sách "gạch đầu dòng" và hỏi: "Sprint này xong được không?".
Daily Stand-up trở thành Buổi báo cáo Tình trạng: Thay vì là nơi team tự đồng bộ, các buổi họp 15 phút biến thành nơi mỗi thành viên báo cáo cho manager. Sự hợp tác không tăng, chỉ có sự giám sát vi mô tăng lên.
Sprint Review bị Bỏ qua: Vì Product Owner vắng mặt, các buổi demo cuối Sprint thường xuyên bị hủy hoặc chỉ diễn ra hình thức. Vòng lặp phản hồi bị phá vỡ.
"Sản phẩm Chạy được" trở thành "Tính năng Chắp vá": Áp lực phải "hoàn thành" một cái gì đó vào cuối mỗi Sprint, kết hợp với các yêu cầu mơ hồ, đã tạo ra một văn hóa làm việc chắp vá, khiến "nợ kỹ thuật" ngày càng chồng chất.

Sau một năm, chúng tôi chỉ đơn giản là đang thực hành Waterfall trong những chu kỳ hai tuần. Vị manager mới, dù có kinh nghiệm, đã thất bại trong việc thay đổi những vấn đề cốt lõi. Ông chỉ thay đổi được các nghi lễ, không thay đổi được "tôn giáo".

Phần III: Tự vấn – Bộ câu hỏi để Chẩn đoán "Bệnh Agile Giả"

Nếu câu chuyện của chúng tôi nghe có vẻ quen thuộc, bạn có thể sử dụng bộ câu hỏi dưới đây để tự chẩn đoán văn hóa phát triển trong tổ chức của mình. Nếu bạn là một tổ chức Agile thực thụ, câu trả lời cho hầu hết các câu hỏi này phải là "Có".

Dành cho Quản lý Dự án/Trưởng nhóm:

Đội ngũ có thực sự bàn giao một phần sản phẩm chạy được cho người dùng sau mỗi chu kỳ không? Họ có thu thập được phản hồi cần thiết không?
Dự án có một "Hiến chương Sản phẩm" (Product Charter) rõ ràng không? Tất cả thành viên có hiểu về nó không?
Đội ngũ có được phép cập nhật yêu cầu dựa trên phản hồi thu thập được từ người dùng không?
Đội ngũ có được phép cập nhật quy trình làm việc của chính họ dựa trên những gì họ học được không?

Dành cho Đội ngũ Phát triển:

Mức độ tự động hóa trong các quy trình phát triển, bảo mật, kiểm thử và triển khai là bao nhiêu?
Người dùng cuối là ai? Đội ngũ phát triển tương tác với họ như thế nào và qua kênh nào?
Những công cụ nào đang được sử dụng để kiểm thử chất lượng code?

Dành cho Người dùng Cuối (End Users):

Phương thức giao tiếp của bạn với đội ngũ phát triển là gì?
Bạn có thường xuyên tham gia các buổi thảo luận để chia sẻ về các tính năng bạn muốn có không?
Làm thế nào bạn chia sẻ phản hồi (feedback) với đội ngũ phát triển?
Bạn có được dùng thử các phiên bản mẫu (prototype) của các tính năng mới không?
Mất bao lâu để một tính năng bạn đề xuất xuất hiện trong ứng dụng?

Phần IV: Cội rễ của Thất bại – Hãy luôn ghi nhớ các Giá trị Cốt lõi

Thất bại của Scrum tại công ty tôi đến từ sự thiếu hiểu biết sâu sắc về bản chất của việc phát triển phần mềm từ chính Ban Giám đốc – những người muốn có "trái ngọt" của Agile mà không sẵn lòng tuân theo các giá trị cốt lõi của nó.

Hiểu sai về "Lỗi" (Bug): Họ xem lỗi như một sự yếu kém, một thứ không nên tồn tại, thay vì là một phần tất yếu của quá trình sáng tạo.
Hiểu sai về "Rủi ro" và "Thay đổi": Họ muốn có quyền thay đổi yêu cầu liên tục (đặc tính Agile), nhưng lại không chấp nhận sự thay đổi về thời gian và chi phí đi kèm. Họ muốn khóa cứng chi phí và deadline (bản chất Waterfall) nhưng lại không muốn bị ràng buộc bởi phạm vi đã chốt.
Hiểu sai về "Kế hoạch": Họ đưa ra những yêu cầu chỉ với vài gạch đầu dòng và mong đợi một cam kết chính xác về thời gian, không hiểu rằng việc biến một "ý tưởng" thành "kế hoạch" đòi hỏi một quá trình phân tích tốn kém.

Tuyên ngôn Agile nhắc nhở chúng ta bốn giá trị cơ bản:

Cá nhân và sự tương tác hơn là quy trình và công cụ.

Sản phẩm chạy được hơn là tài liệu đầy đủ.

Hợp tác với khách hàng hơn là đàm phán hợp đồng.

Phản ứng với sự thay đổi hơn là bám sát một kế hoạch.

Công ty chúng tôi đã làm ngược lại gần như tất cả. Chúng tôi đã tôn sùng các công cụ (JIRA, ClickUp) và các nghi lễ (stand-up, sprint) nhưng lại phớt lờ sự tương tác. Chúng tôi bị ám ảnh bởi các hợp đồng và deadline cố định, và xem sự thay đổi như một mối đe dọa. Và quan trọng nhất, chúng tôi đã loại bỏ khách hàng/người dùng cuối ra khỏi vòng lặp phát triển.

Kết luận: Không thể Chữa bệnh bằng cách Thay đổi Tên gọi

Câu chuyện của chúng tôi là một lời cảnh báo: Agile không phải là một quy trình có thể "cài đặt" là chạy. Nó là một sự thay đổi về tư duy và văn hóa, và sự thay đổi đó phải bắt đầu từ cấp cao nhất. Áp dụng các nghi lễ của Scrum mà không có tư duy Agile cũng giống như việc mặc áo blouse trắng và tự gọi mình là bác sĩ. Về hình thức thì có vẻ đúng, nhưng không thể chữa được bệnh. Ở công ty tôi, chúng tôi đã mặc chiếc áo Scrum trong một năm, nhưng "căn bệnh" Monolith của chúng tôi, cả về kỹ thuật và văn hóa, vẫn còn đó, thậm chí còn trở nên trầm trọng hơn.

Bài viết được trình bày và chia sẻ bởi TVD Media. Một quy trình phát triển hiệu quả là nền tảng, nhưng nó cần được thể hiện qua một sản phẩm chất lượng. Khám phá dịch vụ Thiết kế và phát triển website chuyên nghiệp của chúng tôi.