Scrum có thể được nhìn nhận như là một khuôn khổ lí thuyết và thực hành cho việc phát triển sản phẩm, nhưng nó cũng có thể được nhìn nhận như là một phương pháp 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). Đi từ ý tưởng từ sư tổ ngành Quản lí Peter Drucker, đến Ikujiro 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, và được Steve Denning đánh giá là một trong các phát kiến quan trọng nhất trong lĩnh vực quản trị hiện đại.
Sức mạnh của Scrum 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, chúng ta cùng tìm hiểu thành phần nằm trong lõi 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. Có thể nói, đây là phần lõi cùng với lí thuyết quản lí thực nghiệm tạo nên phần hồn của Scrum, cùng với các vai trò, sự kiện, quy trình, tạo tác và các quy tắc tạo nên khung xương cho 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 đó. Chúng ta 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ả.
Nói chung, 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ộ nhóm (hoặc cao hơn là mức độ tổ chức), nhằm mang lại khả năng ra quyết định tối ưu nhất để hoàn thành công việc, đạt hiệu quả cao nhất. Trong quá trình phát triển sản phẩm, 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…) thông qua cơ chế Thanh tra đều đặn và liên tục (trong Scrum Hằng ngày, Sơ kết Sprint, hay họp Cải tiến Sprint); 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 (Transparency)
Scrum giả định rằng 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ễ rơi vào tình huống rủi ro, ít khả năng thích ứng thiếu thông tin để ra quyết định chính xác. Thiếu minh bạch, tổ chức có thể bị phụ thuộc vào một vài cá nhân hoặc nhóm lợi ích, khó phát triển bền vững và trường tồn .
Minh bạch thường phải đi kèm với thông suốt (thực ra hai từ này mang đủ nội hàm trong 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 phò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 thiết 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ề khách hàng, trạng thái sản xuất…) và cũng nằm ở rất nhiều ngóc ngách của tổ chức (ở người nào đó có 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 …). 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, yếu tố tài chính thường được kiểm soát chặt chẽ nhất và dường như có xu hướng minh bạch nhấ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, dẫ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 (Inspection)
Không có thanh tra, không thể có minh bạch. QA (Quality Assurance) 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. Nhân viên 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 (vì đấy cũng không phải là nhiệm vụ của QA). Trong khi nếu như công tác thanh tra được đẩy cho người làm việc thực hiện, tức tự thanh tra, 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, và đặc biệt là đảm bảo chất lượng tự thân trong hoạt động của mình. Trong tiêu chuẩn ISO có mô tả một chức danh Giám đốc chất lượng (QMR), 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 đề. ISO cho đây là người rất quan trọng trong việc đảm bảo một hệ thống quản trị chất lượng hiệu quả. Tuy Scrum không định nghĩa rõ những vai trò như thế, nhưng vẫn đảm bảo những yêu cầu công việc của QA, QMR được thực hiện với các kĩ thuật thanh tra đặc thù.
Việc thanh tra có thể được thực hiện nhẹ nhàng trong các buổi họp của nhóm. Ở đó, 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 nghiệp vụ hoàn toàn bình đẳng trong cộng tác, đều có trách nhiệm báo cáo và giải trình cho nhau để đảm bảo thúc đẩy sự cộng tác đạt kết quả tối ưu. 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.
Thanh tra cần phải liên tục. Không có cơ chế thanh tra liên tục, thì í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. Cho nên, trong Scrum, việc thanh tra được thực hiện ở những sự kiện với tần suất dày đặc, phù hợp với yêu cầu thực tiễn: Scrum Hằng ngày để thanh tra tiến độ và vấn đề, thực hiện hằng ngày; Sơ kết Sprint để thanh tra tiến độ và chất lượng sản phẩm; Cải tiến Sprint để thanh tra về cách làm việc và đề xuất phương án cải tiến cùng với kế hoạch hành động; Cơ chế Định nghĩa Hoàn thành hoặc áp dụng “Điều kiện tiếp nhận” để giúp mỗi một người tự thanh tra chất lượng công việc của mình, được cá nhân thực hiện hằng ngày.
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ỉ.
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.
Thích nghi (Adaptation)
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. Với đặc điểm làm việc nhóm theo lối tự tổ chức (self-organizing), thì một nhóm không có khả năng thích nghi là một nhóm chưa trưởng thành.
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 có đá hay cũng chưa thể ăn mừng. Để 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ố liên quan nhiều nhất đến yếu tố con người trong ba chân của Scrum. Scrum có thể giúp ta phát lộ rất nhiều lỗ hổng trong hệ thống, rất nhiều vấn đề trong tổ chức; nhưng phải có (những) ai đó (đủ năng lực) có khả năng đứng ra giải quyết vấn đề đó. Nếu không, tổ chức của ta sẽ chẳng đi đến đâu cả.
Nói chung, nhiều người nhận xét là nếu bỏ chữ Scrum đi, thì cái gọi là “ba trụ cột của Scrum” có thể quan trọng và nhu cầu cấp thiết với bất kì doanh nghiệp tổ chức nào. Nhưng Scrum còn đi xa hơn thế khi được thiết kế với những biện pháp thực hành tương đối cụ thể để đảm bảo các trụ cột đó được thực thi và phát huy hiệu quả. 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.
