Từ những năm đầu đi làm, Py đã nghe đến khái niệm “Agile”. Thời điểm đó, Py vẫn chưa có nhiều định hình rõ ràng về kỹ năng gọi là “quản lý dự án” (project management). Agile khi ấy nghe như một thứ gì đó hơi “xa” – vừa chuyên môn, vừa mơ hồ. Và đến hiện tại, khi qua vài năm tìm hiểu và thực hành Agile thì Py thường nhắc đến từ khóa này như một món quà bất ngờ mà nghề product mang lại. Hơn cả ý nghĩa về mặt chuyên môn, “Agile” là một lựa chọn để trải nghiệm cuộc sống.
Lý thuyết
Đối với Py, cách tốt nhất để hiểu một khái niệm vẫn luôn là… đọc. Với những khái niệm mới, Py thường bắt đầu từ việc tìm hiểu các khía cạnh cơ bản: định nghĩa, bối cảnh ra đời, các từ khóa liên quan. Sau đó sẽ tìm đọc thêm các chia sẻ từ những “người trong ngành” – để thấy cách khái niệm ấy được hiểu và áp dụng ra sao trong thực tế.
Trong bài viết này, Py sử dụng khái niệm Agile Methodology1 theo định nghĩa phổ biến sau:
Agile Methodology is a way to manage projects by breaking them into smaller parts. It focuses on working together and making constant improvements.
Tạm dịch: Phương pháp Agile là một cách quản lý dự án bằng cách chia nhỏ công việc thành nhiều phần nhỏ hơn. Trọng tâm của nó là làm việc cùng nhau và liên tục cải thiện qua từng chặng.
Và với Scrum2, Py chọn định nghĩa:
Scrum is a type of Agile framework. Scrum is a management framework that teams use to self-organize tasks and work towards a common goal.
Tạm dịch: Scrum là một framework để thực hành Agile. Đây là một mô hình quản lý mà các nhóm sử dụng để tự tổ chức công việc và cùng nhau hướng tới một mục tiêu chung.
Dĩ nhiên, đây chỉ là hai trong rất nhiều cách diễn giải về Agile – một triết lý, và Scrum – một công cụ để hiện thực hoá triết lý đó. Py thường hay nói vui: nếu ví Agile như một “tôn giáo”, thì Scrum là “cuốn kinh” – tức là Agile là thứ để hiểu, để ngấm, còn Scrum là từng bước để thực hiện. Hay cũng có thể so sánh mối quan hệ này như giữa mindset và toolset.
Nếu bạn muốn hiểu thêm về bối cảnh ra đời của Agile, thử tìm hiểu về khái niệm VUCA3 – một thế giới đầy biến động, không chắc chắn, phức tạp và mơ hồ – nơi mà Agile được sinh ra để giúp con người thích nghi và phản ứng tốt hơn với những thay đổi liên tục.
Thật ra, có rất nhiều điều cần tìm hiểu – thậm chí cần nhớ nằm lòng – khi nói về Agile và Scrum. Nên với những phần mang tính lý thuyết, Py có đính kèm một vài nguồn tham khảo mà Py từng đọc qua. Nếu bạn thấy hứng thú, có thể tìm thêm quyển Cẩm nang Scrum – một quyển sách dễ tiếp cận, bao quát cả phần lý thuyết lẫn cách triển khai Scrum trong thực tế.
Còn ở bài blog này, Py chỉ chọn đề cập đến hai khái niệm cơ bản nhất – để đảm bảo chúng ta đang chia sẻ cùng một “ngữ cảnh” – và dành phần lớn không gian để viết về những gì Py từng trải qua trong hành trình sống và làm việc cùng Agile/Scrum.
Thực hành
Vì Agile cũng chỉ là một khái niệm – cách hiểu và cách áp dụng ở mỗi công ty, mỗi team đều có thể khác nhau. Có nơi áp dụng rất bài bản, có nơi linh hoạt tới mức… hơi quá đà. Nên việc đánh giá một team đã “Agile” chưa thường không có thước đo cố định. Đôi khi, phải mất vài tháng, thậm chí vài năm mới thấy được tác động thật sự của Agile.
Bên cạnh đó, trong bài viết này Py cũng sẽ không đề cập đến diễn giải lý thuyết của Agile/Scrum mà chỉ nói lên suy nghĩ của mình, nên mong bạn sẽ dành thời gian xem qua video này để điểm qua nhanh các điểm kiến thức cần đó. Còn phần chia sẻ này không mang tính quy chuẩn, chỉ hy vọng sẽ góp thêm góc nhìn khác để cùng hiểu và thực hành Agile hiệu quả:
1. Mục tiêu là tối thượng
Một điều Py rút ra được sau nhiều sprint: vì Agile – hay cụ thể là Scrum – cho phép dễ dàng thay đổi những phần đã được thống nhất từ trước, nên mục tiêu trở thành điều cực kỳ quan trọng. Dù trong bất kỳ giai đoạn nào, bối cảnh nào, mọi việc được thực hiện trong sprint đều cần xoay quanh một điểm chung – sprint goal. Và qua nhiều sprint, những gì mình đang phát triển cũng phải từng bước tiến gần đến một đích lớn hơn – product goal.
Kể cả trong những cuộc họp nhỏ – từ planning, grooming cho đến retrospective – việc xác định rõ mục tiêu ngay từ đầu giúp team không sa đà vào tranh luận lan man, mà tập trung vào điều quan trọng nhất. Những tactics rất nhỏ như đặt tên meeting theo nội dung chính, gửi trước agenda, hoặc thậm chí ghim mục tiêu vào đầu mỗi board task – về lâu dài, sẽ hình thành một thói quen làm việc có định hướng.
Với Py, Agile không dạy mình chạy “tùy hứng” – nó dạy mình luôn có đích đến, nhưng sẵn sàng đổi đường để đến đó nhanh hơn, hiệu quả hơn.
2. Minh bạch là lựa chọn
Hiển nhiên, scrum team cần biết rõ mục tiêu mà cả nhóm đang theo đuổi. Nhưng không chỉ dừng lại ở đó – team cũng nên được chia sẻ về những yếu tố xung quanh có thể ảnh hưởng đến khả năng hoàn thành mục tiêu: thay đổi từ phía business, rủi ro kỹ thuật, hay cả những khúc mắc trong nội bộ. Tuy nhiên, vì scrum team thường gồm nhiều vai trò chuyên môn khác nhau – PO, Dev, QC… – nên mỗi người sẽ có “cảm” khác nhau về mức độ ảnh hưởng của một vấn đề. Điều này dễ dẫn đến tình trạng “người biết – người không”, hoặc nghiêm trọng hơn là “biết không giống nhau”.
Để tránh những kiểu “mis-” như vậy (miscommunication, misunderstanding…), thì cách hữu hiệu nhất – theo trải nghiệm của Py – là over communication. Đặc biệt trong vài sprint đầu tiên của một dự án, việc chia sẻ nhiều hơn mức cần thiết một chút chưa bao giờ là thừa. Như việc PO nói rõ lý do vì sao ưu tiên task A hơn task B, hay Dev chủ động nhắc về ảnh hưởng của một thay đổi nhỏ trong API, hay gửi meeting notes sau mỗi cuộc họp có các decision và action quan trọng – những điều tưởng chừng nhỏ nhặt, lại góp phần giữ nhịp cho cả team.
Qua những buổi retrospective, cả team cũng có thể cùng ngồi lại phân loại: thông tin nào nên chia sẻ, thông tin nào không cần thiết; kênh nào là hiệu quả nhất khi cần cập nhật thay đổi. Vì minh bạch không chỉ là chia sẻ – mà là chia sẻ có chủ đích.
Minh bạch, suy cho cùng, là một lựa chọn. Lựa chọn tin tưởng rằng: khi mọi người cùng nhìn về một hướng, và cùng nhìn thấy những thứ đang cản đường – thì khả năng về đích sẽ cao hơn.
3. Kỷ luật để tự do
Agile hướng về sự linh hoạt – nhưng Scrum, framework phổ biến nhất để thực hành Agile, lại có những “quy tắc” tưởng như khá cứng. Ví dụ như: phải có sprint – chu kỳ làm việc cố định; phải có các buổi họp được thiết kế rõ ràng như Sprint Planning, Sprint Review, Sprint Retrospective, hay Daily Stand-up Meeting (DSM). Thoạt nghe có vẻ mâu thuẫn: một bên khuyến khích thay đổi, một bên lại đặt ra khuôn khổ. Nhưng thực ra, chính những cấu trúc tưởng như “bắt buộc” ấy lại là thứ tạo nên sự tự do đúng nghĩa.
Việc tuân thủ những nguyên tắc đã được đồng thuận không chỉ giúp team vận hành trơn tru, mà còn âm thầm bồi đắp sức bền. Qua những buổi họp có mục tiêu, team sẽ dần hình thành thói quen làm việc có định hướng. Sau một thời gian quen với nhịp sprint hai tuần, các thành viên cũng có thể tự ước lượng năng lực của mình – biết đâu là “vừa đủ” để cam kết, và đâu là “quá sức” cần từ chối. Đây đều là nền tảng để đón nhận thay đổi, khi luôn phải giữa đầu lạnh để biết mình đang cần làm gì và có thể làm gì.
Agile (1) sẽ tạm dừng ở đây – với những gì gắn liền với nghề product, với quy trình, với các khái niệm như Scrum hay sprint. Nhưng với Py, Agile chưa bao giờ chỉ dừng ở vai trò một phương pháp làm việc. Dành hơn 8 tiếng mỗi ngày trong môi trường Agile, ít nhiều gì “triết lý” này cũng đã âm thầm ảnh hưởng đến cách Py tiếp cận và giải quyết nhiều vấn đề khác trong cuộc sống. Và đó là Agile (2), khi Agile được áp dụng ngoài khuôn khổ product development
- GeeksforGeeks. (n.d.). What is Agile methodology? GeeksforGeeks. Retrieved July 20, 2025, from https://www.geeksforgeeks.org/software-testing/what-is-agile-methodology/
- GeeksforGeeks. (n.d.). Scrum – Software Development. GeeksforGeeks. Retrieved July 20, 2025, from https://www.geeksforgeeks.org/software-engineering/scrum-software-development/
- Bennett, N., & Lemoine, G. J. (2014, January). What VUCA really means for you. Harvard Business Review. https://hbr.org/2014/01/what-vuca-really-means-for-you
Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.
Chúc bạn nhiều may mắn và bình an.
Anpy
Leave a Reply