Starting an Agile Project from Scratch: A Complete, Real-World Preparation Guide (Part 2)
Nếu như ở phần đầu tiên, chúng ta đã cùng đi qua ba giai đoạn đầu tiên để khởi động dự án Agile - xác định tầm nhìn, xây dựng backlog, thiết lập môi trường kỹ thuật và đồng bộ tư duy team thông qua Sprint 0 và Kick-off - thì ở phần này, dự án Agile sẽ chính thức đi vào giai đoạn vận hành.
Đây là thời điểm mà các ceremony bắt đầu diễn ra hàng ngày như planning, standup, review và retrospective. Đây cũng là lúc mà backlog thực sự được đưa vào phân tích và thực hiện, chuyển thành những dòng code, test case, technical task. Và cũng là lúc mà chúng ta sẽ cảm nhận được các tình huống thực tế như:
Product Owner đưa ra change request và thay đổi priority.
Stakeholder feedback quá muộn hoặc không rõ ràng.
Dev team gặp các vấn đề conflict và output không đạt yêu cầu.
QA chưa test kịp hoặc staging không ổn định.
Agile không chỉ khởi động đúng, mà là duy trì được nhịp phát triển ổn định và liên tục cải tiến. Ở phần 2 này, chúng ta sẽ đi qua ba giai đoạn tiếp theo để đảm bảo dự án Agile không chỉ bắt đầu đúng mà phải có giá trị.
Phase 4 - Thiết lập quy trình Scrum & Vận hành Sprint đầu tiên
Các khái niệm cơ bản về Scrum
Phase 4 đánh dấu bước chuyển từ giai đoạn chuyển bị sang triển khai thực tế. Scrum Framework nếu vận hành đúng sẽ là công cụ hiệu quả giúp team duy trì nhịp độ ổn định và tạo ra giá trị liên tục.
Trong giai đoạn này, chúng ta cần đảm bảo một vài điều sau:
Thiết lập đầy đủ các Scrum ceremonies
Sprint đầu tiên được triển khai đúng nhịp
Team hiểu rõ vai trò, quy trình và nhịp độ
Có cơ chế để phản hồi và điều chỉnh sớm
Nếu các bạn chưa biết Scrum và Agile là gì, thì hãy xem lại bài viết Agile Project Management 101 của mình, trong đó sẽ giải thích chi tiết về Agile cũng như Scrum.
Nhắc lại một tí về Scrum Framework, chúng ta cần tập trung vào:
Phát triển theo các vòng lặp ngắn (Sprint)
Giao tiếp thường xuyên
Cải tiến liên tục thông qua feedback
Cấu trúc cơ bản của Scrum gồm:
Roles: Product Owner, Scrum Master, Development Team
Events: Sprint, Planning, Daily Standup, Review and Retrospective
Artifacts: Product Backlog, Sprint Backlog, Increment
Với các yếu tố và cấu trúc cơ bản của Scrum thì về mặt lý thuyết chúng ta có thể bắt tay vào làm ngay. Tuy nhiên, Scrum không phải là một bộ công thức thần kỳ mà bạn chỉ cần “bay vào làm theo” là sẽ hiệu quả. Thực tế, rất nhiều team gặp các vấn đề như:
Standup thành daily report: thay vì là buổi sync-up nhanh thì mọi người lần lượt báo cáo cho Scrum Master hay PM nghe.
Sprint Planning kéo dài 3 tiếng mà vẫn chưa hiểu mình sẽ làm gì.
Retrospective trở thành buổi xả stress chứ không ra được hành động cải tiến.
Backlog ngập tính năng nhưng không ai thấy giá trị.
Lý do vì Scrum bản chất chỉ là một framework - còn cách vận hành mới quyết định thành công, vậy hãy bắt đầu từ nhũng thiết lập cơ bản nhất.
Sprint length - đừng mặc định là 2 tuần
Mình không hiểu nổi khi hỏi sprint sẽ kéo dài trong bao lâu thì đa phần mọi người đều trả lời từ 2 tới 4 tuần, tại sao nó không phải là từ 1 đến 3 tuần? Thật ra, trước khi xác định cứng nhắc là sprint length nên kéo dài bao nhiêu, team nên tự hỏi:
Liệu feature có kịp test, review và demo trong 2 tuần?
Liệu team có đủ nhịp để ra tạo ra giá trị đều đặn hay không?
Với mình, không nhất thiết phải là 2 hoặc 4, đôi khi sẽ là 3 hoặc 5 và thậm chí sprint đầu tiên mình hay có xu hướng thiếp lập sprint length là 1 tuần. Vì có thể ở giai đoạn đầu team vẫn chưa quen velocity, chưa hiểu rõ DoD hoặc PO có thể chưa viết User Story đủ rõ ràng. Scrum là một quá trình Inspect và Adapt, mà muốn inspect được thì cần vòng lặp ngắn. Sprint ngắn sẽ giúp bạn nhanh chóng thấy planning có vấn đề gì không, team có commit đúng không và cách viết story có ổn không.
Hầu hết ở Sprint 1 đều rơi vào 1 trong 2 trạng thái:
Team tự tin và kéo quá nhiều story, nghĩ rằng sẽ làm hết được
Khi cả team đều gật đầu trong Planning nhưng thực ra chưa ai rõ task là gì
Mình còn nhớ, có đợt mình có một dự án triển khai con game, khi planning mọi người đều gật gù và cho rằng bản thân đã hiểu rõ hết toàn bộ task. Team Dev bay vào cắm đầu code liên tục nhưng kết quả chưa có gì chạy được và cuối cùng sau 2 tuần demo bằng ảnh Figma và đó gọi là “Done”.
Vì thế Sprint 1 không cần tốc độ, nó cần sự thẳng thắn và minh bạch ngay từ đầu.
Definition of Done (DoD) - chữ Done cần được làm rõ hơn bất kỳ tài liệu nào
Một mindset sai lầm trong quá trình triển khai đó là:
❌ “Code xong là done”
✅ “Code xong + code review + pass test + deploy staging + approved bởi QA”
Một trong những lý do mà backlog bị kẹt vì team không có DoD rõ ràng, dẫn tới việc mọi thứ đều xem như gần xong.
Đối với mình DoD rất quan trọng, nó cho thấy một User Story định nghĩa hoàn thành là như thế nào, và không chỉ PM hay SM nắm điều đó mà tất cả thành viên trong team cũng cần phải hiểu. Và nên thống nhất với nhau, nếu chưa đạt DoD thì sẽ không được chuyển sang review.
Sprint Planning nên giống buổi phản biện thay vì là một checklist
Để mình mô tả cho các bạn một Sprint Planning thường thấy ở các team. PO sẽ là người đọc các Story, Dev nhìn và estimate nhanh và ai cũng OK, và cuối cùng khi vào thực hiện thì sẽ hỏi lại rất nhiều, chỗ A chưa rõ, chỗ B chưa hiểu.
Thay vào đó, hãy biến Sprint Planning thành buổi phản biện tập thể. Ví dụ “As a user, I want to apply a discount code at checkout.”
Với Story trên, hãy thử đặt các câu hỏi như:
Nếu mã hết hạn thì sao?
Hệ thống validate sẽ ở FE hay BE?
Có cho nhập 2 mã hay không?
Có log lịch sử không?
Mỗi câu hỏi như vậy không chỉ làm rõ scope mà còn mở rộng tư duy kỹ thuật, product và UX. Với cá nhân mình, Sprint Planning tốt là khi Dev phải hỏi lại PO và PO sẽ trả lời “thật ra tôi chưa nghĩ tới case này” thì đó mới gọi là hiệu quả :D
Sprint Goal không phải là khẩu hiệu, mà là nguyên tắc để từ chối
Rất nhiều Sprint thất bại không phải vì technical mà vì team không biết reject khi PO nói “có story này, team làm luôn giúp được không?”
Quay lại câu chuyện Sprint Goal nên được viết dưới dạng giá trị đầu ra và cho người dùng cụ thể ví dụ thay vì viết “Hoàn thiện phần UI giỏ hàng” thì hãy viết là “User có thể thêm và xem giỏ hàng của mình mọi lúc.” Khi có Goal rõ, dev lead có thể nói “Story thanh toán chưa phục vụ cho goal này, chúng tea có thể đưa vào Sprint sau.” Một sprint không cần nhiều, nhưng phải tập trung và đạt được mục tiêu đề ra.
Daily Standup không phải là buổi cập nhật status
Có phải rằng team daily của bạn sẽ thường xuyên có mấy câu như “Hôm qua em fix bug, hôm nay vẫn fix tiếp bug” hay là “Chắc hôm nay em sẽ hoàn thành nốt cái phần hôm qua”. Okay xin chúc mừng, daily của bạn trở thành buổi cập nhật status vô nghĩa.
Thay vào đó hãy thay đổi theo hướng:
Em đang bị kẹt ở [việc này] vì [lý do này], mọi người có idea gì không?
Anh đang cần [A] giúp code review hoặc unblock task B.
Chúng ta nên sync riêng về [feature này] vì nó có conflict logic.
Daily không phải chỉ trả lời 3 câu hỏi mà nó nên là gỡ được vấn đề hoặc làm rõ được rủi ro.
Sprint Review không phải là nơi khoe kết quả mà là nơi kiểm nghiệm giả định
Scrum bảo phải demo và rất nhiều team chỉ chạy thử product → PO gật đầu → Xong.
Ở Sprint Review nên bắt đầu với những giả định, nếu người dùng xem được sản phẩm chi tiết, họ sẽ hiểu rõ ưu điểm. Hãy kiểm tra xem UI này có thực sự truyền tải được hay không?
Đây không chỉ là demo, mà hãy đặt câu hỏi như:
Có data/ feedback nào không?
Có cần pivot hoặc scope lại phần nào không?
Một buổi review tốt là nơi PO được gợi ý để viết lại backlog.
Mình sẽ tặng các bạn một checklist và bạn hãy thử nhìn lại xem liệu team đã từng đạt được những điều bên dưới chưa nhé.
Team đã nói không chắc ít nhất 1 lần trong Sprint Planning
Daily có ít nhất 1 lần unblock thực sự, không phải update status
Sprint Goal được dùng để từ chối 1 yêu cầu phát sinh
Review dẫn tới việc PO sửa lại backlog (thêm, bớt hoặc viết lại story)
Retro có ít nhất 1 hành động cải tiến cụ thể, ai làm, khi nào team xong.
Nếu team bạn chưa đạt được những điều trên, hãy thử thay đổi góc nhìn và tư duy – mình tin rằng điều đó sẽ tạo nên sự khác biệt rõ rệt trong cách vận hành.
Phase 5: Giao tiếp liên tục, quản lý thay đổi và kiểm soát kỳ vọng
Sau khi team đã thiết lập nền móng Sprint 0 và vận hành Sprint đầu tiên, thì bước tiếp theo không phải là tăng số lượng task, mà là làm chủ được nhịp độ phát triển và chất lượng giao tiếp trong team, đồng thời học cách quản lý thay đổi đến từ khách hàng.
Agile như chúng ta biết đó là sự linh hoạt, và chính vì điều đó mà bạn sẽ đối mặt với:
Feedback liên tục từ khách hàng
Thay đổi yêu cầu đột ngột
Những expectation không rõ ràng hoặc liên tục thay đổi
Nếu không có phương pháp và công cụ phù hợp, bạn rất dễ rơi vào tình trạng sửa tới, team chạy deadline triền miên, backlog càng lúc càng rối. Ở phase 5 này mình sẽ giúp bạn:
Nhận diện các hiểu lầm phổ biến về giao tiếp trong Agile
Biết cách chuyển hoá feedback thành giá trị thực
Học cách giữ PO khỏi việc thành requester
Và đặc biệt kiểm soát sự thay đổi mà không làm team kiệt sức
Giao tiếp giả tạo vs giao tiếp thật
Nhiều người nghĩ rằng mình giao tiếp tốt vì có Daily Standup mỗi ngày, nhưng vấn đề là có mặt nó sẽ khác với giao tiếp, nói chuyện sẽ khác với đồng cảm và report cũng sẽ khác với hiểu vấn đề.
Giao tiếp thật nghĩa là:
Team cảm thấy an toàn khi nói “tôi chưa rõ task này”
PO đủ tin tưởng để nói “tôi thấy hướng này chưa ổn”
Dev đủ thoải mái để chia sẻ “deadline này không khả thi”
Giao tiếp không nên chỉ là buổi họp mà nó là chất lượng của mối quan hệ. Mỗi PM, Scrum Master cần xây dựng môi trường đủ trust và transparency, nơi team có thể trao đổi thực sự, không phải chỉ gật đầu.
Với mình, luôn tạo sự thoải mái cho team, thường xuyên đưa ra nhưng câu chuyện đời thường với team → tăng bonding → giảm rào cản giao tiếp trong công việc.
Quản lý feedback như backlog
Một sai lầm phổ biến khi xem feedback là nhưng yêu cầu tức thời, có thì sửa không có thì thôi. Agile đề cao sự phản hồi liên tục, nhưng bạn cần đối xử với feedback như với backlog – tức là cần có sự sắp xếp và phân loại rõ ràng.
Đưa feedback vào backlog với định dạng rõ ràng như story, bug, suggestion,…
Gán độ ưu tiên & acceptance criteria
Có review định kỳ
Việc đánh giá độ ưu tiên rất quan trọng, nó sẽ giúp ta biết lúc nào nên ưu tiên, đôi khi các feedback chỉ đơn giản là client thấy chỗ đó không phù hợp và đưa ra, chúng ta hãy cứ lắng nghe và đưa vào backlog, đánh giá priority và có thể đưa vào sprint sau. Như mình có đề cập ở phía trên, cần hiểu sprint goal và đôi khi cần học cách từ chối. Từ chối ở đây không phải là không thực hiện mà vì độ ưu tiên thấp nên có thể đưa vào backlog và sẽ xử lý trong sprint sau, client vẫn cảm thấy họ được lắng nghe và team thì vẫn happy thực hiện theo sprint goal.
Làm sao để PO không trở thành Requester
PO rất dễ rơi vào trạng thái “request factory”: liên tục nảy ra ý tưởng mới, push team thực hiện liên tục, điều này có thể dẫn đến:
Dev quá tải
Backlog loạn
Không sprint nào kết thúc trọn vẹn
PM/ SM cần giúp PO chuyển hoá năng lượng sáng tạo này thành chiến lược sản phẩm. Ví dụ với các idea mới, hãy tạo “idea parking lot” - nơi ghi lại các ý tưởng chưa đủ rõ để đưa vào sprint. Dùng Impact vs Effort Matrix để ưu tiên và định kỳ tổ chức Backlog Grooming để giúp PO phân tích, gọt ý tưởng, từ request mơ hồ trở thành requirement rõ ràng và có thể thực thi.
Đừng biến Backlog thành danh sách cần làm mà hãy giữ nó đúng nghĩa là nơi lưu trữ những câu chuyện sản phẩm mà cả team đều hiểu.
Tổng Kết
Phase 4 giúp bạn chuyển từ nền tảng Sprint 0 sang một hệ thống vận hành Scrum đầy đủ. Đây là giao đoạn tưởng chừng như chỉ cần làm theo lý thuyết nhưng thực tế lại là lúc bạn cần lắng nghe team, tinh chỉnh quy trình và xây dựng khả năng thích ứng. Những điều nhỏ như định nghĩa “ready” cho backlog, hay sprint length chính là chìa khoá tạo ra sự khác biệt.
Phase 5 lại là bài kiểm tra về mức độ trưởng thành trong giao tiếp và quản lý kỳ vọng. Khi dự án bắt đầu thực hiện, bạn không chỉ đơn thuần là người điều phối task mà hãy trở thành người giữ nhịp độ phản hồi, chuyển hoá thay đổi giá trị và bảo vệ team khỏi những yêu cầu thiếu hệ thống.
Insight mình muốn rút ra ở giai đoạn này đó là “Agile không phải là làm nhanh - mà là học nhanh và phản ứng tốt với thay đổi.” Mình mong rằng với các chia sẻ trên, bạn sẽ build được Agile team đúng nghĩa chứ không chỉ Scrum theo giáo trình.
Mình sẽ còn 1 bài nữa, part 3 đó là phát hành MVP, lắng nghe phản hồi từ thị trường và điều chỉnh product theo từng sprint cùng với cách để quản lý rủi ro trong toàn bộ Agile Project - đúng tinh thần Agile. Hẹn gặp bạn ở phần tiếp theo trong tuần sau.