Scrum có thể được nhìn nhận như là là một khuôn khổ lí thuyết và thực hành cho việc phát triển phần mềm, nhưng nó cũng có thể được nhìn nhận như là một khuôn khổ quản lí kiểu mới dành cho các tổ chức quản lí dựa vào tri thức (Knowledge-Based Management), cho các tổ chức sáng tạo tri thức (Knowledge-Creating Companies). Có người đã hào hứng tặng lời khen ngợi tốt nhất cho tác giả Scrum bằng một đề xuất giải Nobel cho lĩnh vực Quản lí (nhưng không có giải này :), xem tại đây: http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/). Triển khai các ý tưởng từ sư tổ ngành Quản lí Peter Drucker, đến Nonaka và Takeuchi, Scrum thực sự là một khung làm việc rất phù hợp với thời đại tri thức ngày nay.

Sức mạnh của Scrum Framework nằm trong cả cách tiếp cận, triết lí, cho đến cấu trúc và các biện pháp thực hành cụ thể. Ở bài này, tôi mổ xẻ cái thành phần cốt lõi nhất của Scrum để thấy được giá trị phổ quát của Scrum: BA CHÂN CỦA SCRUM.

Ba chân (hay ba trụ cột) của Scrum bao gồm Tính minh bạch, Sự thanh tra và Sự thích nghi. Đây là phần lõi đảm bảo cho phần hồn của Scrum, thiếu ba chân này Scrum không thể hoạt động. Mọi thiết kế, quy tắc, hoạt động của Nhóm Scrum về cơ bản là xoay quanh ba trụ cột đó. Bài này thử đi sâu phân tích kĩ các giá trị cốt lõi này để thấy được động lực cho sự thành công của một nhóm nằm ở đâu. Từ các phân tích này, ta cũng có thể rút ra được một số ý tưởng cho các lĩnh vực khác ngoài ngành phát triển phần mềm, nơi Scrum vẫn có giá trị thực hành và phát huy tính hiệu quả.

Theo đó, khung làm việc Scrum yêu cầu thông tin (vấn đề, giải pháp, sáng kiến) được minh bạch và thông suốt cho toàn bộ tổ chức, nhằm mang lại khả năng ra quyết định tối ưu nhất để giải quyết công việc, nhằm đạt hiệu quả cao nhất. Trong quá trình phát triển, Scrum luôn đảm bảo nhóm phát triển tích cực tìm kiếm thông tin (vấn đề, giải pháp, ý tưởng v.v.) thông qua cơ chế Thanh tra đều đặn và liên tục (trong Daily Scrum, Sơ kết Sprint, hay họp Retrospective); từ đó mở đường cho các chiến lược và hành động Thích nghi, nhằm thích ứng với các thay đổi (nội bộ hoặc từ bên ngoài), đạt năng suất tối ưu, mang lại lợi ích tối đa.

Minh bạch
Một tổ chức hiệu quả và phát triển bền vững cần phải minh bạch. Tài chính minh bạch, công việc minh bạch, quy trình minh bạch, đánh giá minh bạch, chiến lược minh bạch, hiệu quả minh bạch, vấn đề cũng phải được minh bạch. Thiếu minh bạch, tổ chức dễ dàng lầm đường lạc lối; khi gặp phải vấn đề không biết truy tìm ở đâu để tìm lối ra. Thiếu minh bạch, tổ chức dễ dàng bị lũng đoạn bởi cá nhân hoặc nhóm lợi ích, sớm muộn sẽ rơi vào khủng hoảng và suy tàn.
Minh bạch thường phải kèm thông suốt (thực ra hai từ này mang đủ nội hàm của chữ Transparency – chữ gốc của Scrum). Vì thiếu thông suốt, giá trị của minh bạch bị giảm xuống. Thông suốt tức là mọi người đều nắm được, từ cấp cao đến cấp thấp, từ phòng ban nọ tới vòng ban kia; khi có mục tiêu, mọi người đều hiểu nó là cái gì, theo cùng một cách thống nhất.

Vì nhiều lí do, thông tin cần có thể đang ẩn nấp dưới rất nhiều dạng  thức (các nghiên cứu thị trường, hiệu suất của đối thủ cạnh tranh, thông tin về thị trường, trạng thái sản xuất, v.v.) và cũng nằm ở rất nhiều ngõ ngách của tổ chức (ở người nào nó hiểu biết, ở mối quan hệ với ai đó, ở nghiên cứu của nhóm nào đó, hoặc ở một tài liệu đúc rút kinh nghiệm của những người tiền nhiệm v.v.). Các thông tin này được minh bạch sẽ tạo cơ hội cho “trí tuệ tập thể” phát huy tác dụng.

Thông thường ở một tổ chức kinh doanh, chỉ yếu tố tài chính được kiểm soát chặt chẽ nhất, nên dường như có xu hướng minh bạch nhất – đấy là nói đến những công ty “tử tế”. Còn các yếu tố khác có thể không được như vậy. Điều đó có thể ảnh hưởng đến hiệu quả chung. Một số ví dụ có thể kể đến như: quy trình được mô tả chi tiết, nhưng việc thực hiện quy trình đến đâu lại có thể không được đánh giá; hệ thống có KPI nhưng các hoạt động ít khi bám KPI, đẫn đến đây chỉ là các “chỉ báo chết” và không có giá trị trong thực tiễn hoạt động, v.v.

Thanh tra

Không có thanh tra, không có minh bạch. QA ra đời là để đảm bảo công tác thanh tra về quy trình và các chỉ số. Nhưng thế thôi chưa đủ. Thanh tra còn được hiểu rộng hơn thế. Thanh tra là công tác cần phải được thực hiện bởi chính người tác nghiệp chứ không phải bởi bên thứ ba. QA thường không mấy khi biết vấn đề là gì, ít khi có tác động trực tiếp và có thể tạo ra động lực cho nhân viên. Trong khi nếu như công tác thanh tra được chính người làm việc thực hiện, thì sẽ tạo thói quen truy tìm vấn đề, tích cực thúc đẩy tiến trình công việc. Trong ISO có chức danh Giám đốc chất lượng, là người thay thế lãnh đạo, chịu trách nhiệm về tất cả các vấn đề về chất lượng của công ty. Thường đây là người không đứng dưới các “giám đốc” khác, để có thể có “tiếng nói” khi phát hiện vấn đề. Đây là người rất quan trọng. Trong Scrum không có người như thế, nhưng vẫn đảm bảo được những công việc của QA, QMR được thực hiện.
Công tác thanh tra có thể được thực hiện rất hiệu quả trong các buổi họp của nhóm, của trung tâm, của bộ phận hoặc của head office. Ở đó thông tin, vấn đề được mang ra mổ xẻ, phân tích và tìm kiếm giải pháp. Các đơn vị tham gia quy trình hoàn toàn bình đẳng trong công tác, đều phải “báo cáo” cho nhau. Khi đó sẽ không có cơ hội  để người làm kém (dù là lãnh đạo hay nhân viên quèn) lấp liếm các thất bại,  ảnh hưởng tới hiệu quả chung.

Không có cơ chế thanh tra liên tục, ít khi các vấn đề được phát lộ, hoặc khi phát hiện ra vấn đề thì nó dễ dàng bị rơi vào cảnh “để lâu hóa bùn”, vì không có cơ chế gì đảm bảo vấn đề đó phải được giải quyết triệt để, có phản hồi rõ ràng và kết quả phải tới được các nơi cần biết.

Khi thanh tra không kết hợp với minh bạch thì kết luận thanh tra cũng không giúp gì cho tổ chức cả. Vấn đề được phát hiện mà mọi người (đặc biệt là người có trách nhiệm) không biết, hoặc không ai đứng ra giải quyết thì việc thanh tra cũng chỉ phí thì giờ, hao tâm tổn sức.

Thanh tra phải liên tục và đều đặn, và phải bám đuổi tích cực. Việc hôm trước phát hiện có sai sót, hôm nay đã giải quyết chưa? Nếu không có sự bám đuổi ấy, thanh tra chỉ là trò hề. Chỉ là làm vì cho có quy trình. Khi đó, quy trình cũng không có, sự cải tiến càng là thứ xa xỉ.

Thích nghi
Trên cơ sở thông tin đầy đủ và minh bạch, ta sẽ huy động được “sức mạnh của toàn dân”. Phương án thích nghi sẽ đi “từ dưới lên”, “từ trên xuống”, “từ bên cạnh” – rất hiệu quả, và bền vững. Trên cơ sở minh bạch thông tin, việc ra quyết định sẽ có chất lượng hơn; nhờ minh bạch về “vấn đề”, tổ chức biết được “chỗ ngứa” để “gãi”; nhờ minh bạch về “năng lực” và “best practice”, tổ chức biết mình phải phát huy cái gì, có lợi thế cạnh tranh gì; v.v.

Thích nghi giống như “tiền đạo” trong đội bóng “Ba trụ cột”. Không ghi bàn thì dù đội bóng hay cũng không thể ăn mừng.Vì thế, để có được sự hiệu quả và tiến bộ, nhất thiết phải có hành động thích nghi tốt.

Trong khi Khung làm việc Scrum giúp cho nhóm có thể đảm bảo thông tin minh bạch, thanh tra tốt (qua các công cụ, sự kiện và các quy tắc được thiết kế rất hiệu quả) thì yếu tố thích nghi đòi hỏi nhóm phải tự mình ra quyết định. Đây là yếu tố “người” nhất trong ba chân của Scrum. Scrum có thể giúp bạn phát lộ rất nhiều lỗ hổng trong hệ thống, rất nhiều vấn đề trong tổ chức của bạn; nhưng phải có (những) ai đó (tài năng) có khả năng đứng ra giải quyết vấn đề đó. Nếu không, tổ chức của bạn sẽ chẳng đi đến đâu cả.

Trong khi Ba trụ cột của Scrum có thể quan trọng với bất kì doanh nghiệp tổ chức nào, thì Scrum Framework lại có một cách cụ thể để đảm bảo các trụ cột đó được duy trì. Chúng ta hoàn toàn có thể trích ra từ đó các ý tưởng để có thể thúc đẩy các yếu tố minh bạch thông tin, thanh tra  và thích nghi ở các loại hình công việc khác, không chỉ phát triển phần mềm.