#1 Podcast: Goal Driven rather than Velocity Driven

Cùng nghe cuộc trò chuyện của PST Chee Hong Hsia và PST Khoa Đoàn về chủ đề rất thú vị: "Goal driven rather than velocity driven", Velocity có phải là Productivity không? Tại sao tập trung vào việc đo Velocity của Scrum Team sẽ dẫn đến nhiều vấn đề? Hãy khám phá cùng Scrum Việt bạn nhé.

About Chee Hong Hsia: He is an experienced Scrum consultant, ICF Coach, Certified Facilitator LEGO® SERIOUS PLAY® and Professional Scrum Trainer (PST) with Scrum.org.

Show Note:

Khoa Đoàn: Xin Chào mọi người, hôm nay chúng ta chào đón Chee Hong Hsia đến từ Hà Lan. Anh ấy là một trong những đồng nghiệp của tôi - một Professional Scrum Trainer từ Scrum.org.

Chee-Hong Hsia: Xin Chào, cảm ơn đã mời tôi tham dự kênh Radio Podcast.

Khoa Đoàn: Vâng, chúng tôi rất vui khi có anh tham dự.
Chee-Hong, anh có muốn chia sẻ đôi điều về bản thân trước khi chúng ta bắt đầu?

Chee-Hong Hsia: À, dĩ nhiên rồi. Tên tôi là Chee-Hong Hsia. Tôi là một Professional Scrum Trainer từ Scrum.org, còn là cố vấn và là người sáng lập của Scrum Traveller. Tôi bằt đầu cuộc hành trình với Scrum của mình năm 2007, khoảng 12 năm trước. Khởi đầu của tôi là một kỹ sư phần mềm, tại thời điểm đó công ty của tôi đang chuyển mình để áp dụng Agile. Đó là lúc tôi được biết về Scrum. Khi tôi học về Scrum và đọc Scrum Guide, tôi tìm thấy những giá trị và những nguyên tắc được thể hiện bằng một thứ ngôn ngữ mà tôi đang tìm kiếm trong công việc phát triển sản phẩm. Đồng thời tôi cũng tìm kiếm được điều mà tôi sẽ theo đuổi trong những một khoảng thời gian dài. Sau này, tôi thành lập công ty của mình, Scrum Traveller - nơi tôi kết hợp hai điều: Scrum và dịch chuyển, du lịch. Là một cố vấn, tôi làm việc với các khách hàng đa dạng đến từ nhiều lĩnh vực chuyên môn khác nhau: viễn thông, ngân hàng, bảo hiểm. Còn với vai trò là một Scrum Trainer, tôi thường du lịch vòng quanh thế giới và kết nối với những chuyên gia về Scrum và Scrum Trainer tại địa phương để dạy về Scrum và thưởng thức những món đặc sản tuyệt vời.

Khoa Đoàn: Mong anh sẽ tới Việt Nam vào một ngày không xa và chúng ta sẽ có dịp cùng tổ chức lớp học Scrum.

Chee-Hong Hsia: Chắc rồi!

Khoa Đoàn: Chee-Hong, tuần này chúng ta có một chủ đề khá thú vị về Velocity (tốc độ làm việc). Anh biết đấy, có khá nhiều người quan tâm về Velocity và so sánh nó với Productivity (Năng suất làm viêc). Và đôi khi họ tưởng Productivity chính là Velocity. Trong tình huống này, anh nghĩ gì về Velocity?

Chee-Hong Hsia: Điều thú vị ở đây là thật ra Velocity không phải là một phần của Scrum. Và nếu các bạn tìm trong tìm trong suốt Scrum Guide, bạn cũng không tìm thấy từ Velocity. Đây là một thứ đang được dùng trong khá nhiều công ty. Khi nghĩ đến Velocity, người ta nghĩ đến một chỉ số trung bình của số lượng công việc được thực hiện thành Increment trong Sprint. Nhưng bởi vì chúng ta đang làm việc trong một môi trường phức tạp: nhân viên bị bệnh, nghỉ phép, những yêu cầu kỹ thuật phức tạp. Có quá nhiều điều chúng ta không thể đoán trước và lên kế hoạch. Vì vậy số lượng công việc có thể hoàn thành trong Sprint không phải là bất biến. Vì vậy Velocity không phải là chỉ số đáng tin cậy để đo lường năng suất. Nó nên được sử dụng trong Planning cho sprints tiếp theo

Khoa Đoàn: Nếu Velocity không phải là một chỉ số để đo lường Productivity, vậy anh có thể chia sẻ một cách tốt hơn để đo lường?

Chee-Hong Hsia: Đây là một câu hỏi hay. Chúng ta sẽ bàn về việc thay đổi Mindset ở đây hơn là việc đo lường. Bởi vì, là một người developer, tôi có thể làm việc với một năng suất rất tốt để đưa đến một sản phẩm "không" mang lại giá trị (Value) gì cho người dùng của tôi. Có lẽ chúng ta nên ngưng nghĩ đến việc đo lường năng suất, nhưng tập trung vào việc mang đến giá trị và đo lường về nợ (Technical Debt). Và sẽ tốt biết bao nếu cả Scrum Team đều cùng làm việc hướng về một mục đích (Goal) và liên tục mang đến giá trị cho khách hàng thông qua những Increment. Thay vì nghĩ về xu hướng về Velocity, chúng ta hãy nghĩ về xu hướng về Goal.

Khoa Đoàn: Vậy điểm mấu chốt ở đây là sự cộng tác trong Scrum Team, giữa Product Owner và Developer để đạt được Sprint Goal?

Chee-Hong Hsia: Đúng vậy!

Khoa Đoàn: Anh biết đó, chúng ta đề cập đến Goal và Sprint Goal, là điều tốt để hướng đến. Thế nhưng vẫn còn rất nhiều người thắc mắc làm sao để định nghĩa được một Sprint Goal. Hy vọng anh có thể chia sẻ cùng mọi người những cách tốt nhất, hiệu quả nhất trong việc định nghĩa một Sprint Goal dựa trên những kinh nghiệm thực tế của anh.

Chee-Hong Hsia: Trước khi chia sẻ về điều nay, tôi muốn nói tôi khá thích ý tưởng xem một Sprint như một Project (dự án) có độ dài không quá một tháng. Như một Project, Sprint có ngày bắt đầu và kết thúc rõ ràng và một mục đích chắc chắn. Mục đích, có thể là: “Tại sao chúng ta phải làm Sprint này?”, “Chúng ta đang cố gắng giải quyết vấn đề gì?”, thậm chí là “Chúng ta đang cố gắng cải thiện điều gì?”. Và tôi tin là người Product Owner phải được xem như một người CEO, là người có mindset doanh nhân, với tầm nhìn rõ ràng cho sản phẩm, chiến lược làm sao để đạt được mục tiêu cho sản phẩm.

Mục tiêu này không cần phải được viết ra một cách chi tiết, cũng không cần phải hoàn hảo và chỉnh chu. Nhưng người Product Owner ít nhất phải dùng nó để bắt đầu thảo luận với Developer. Điều này có thể diễn ra trong Backlog Refinement hoặc Sprint Planning. Nhưng từ khoá chính mà chúng ta cần phải nhớ ở đây là “Sự cộng tác”. Trong Product Planning, Product Owner có thể nói: “Team ơi, trong Sprint này chúng ta cùng hướng đến mục tiêu này” hoặc ít nhất là “Tôi tin là mục tiêu này mang lại giá trị cho người dùng.” Từ đó, Product Owner và Developer cùng làm việc với nhau tìm ra cách để đạt được mục tiêu. Trong khi họ cùng làm việc, Product Backlog có thể được thêm vào, xoá bớt đi hoặc thay đổi. Cuối cùng, Developer chọn một số lượng Product Backlog Items (PBIs) đủ để đạt được mục tiêu cho sản phẩm trong Sprint đó. Và chính tại thời điểm này, mục tiêu được trở thành Sprint Goal.

Khi tạo ra một Sprint Goal, chúng ta có thể đặt ra thêm vài tiêu chí: Sprint Goal phải rõ ràng, phải vừa đủ cho Sprint, phải đo lường được… Nhưng đó không phải là "viên đạn bạc" để giải quyết mọi tình huống khi tạo ra Sprint Goal. Mục tiêu mà người Product Owner đặt ra được xem là một input, cùng với những tiêu chí tôi đã nói trên, và cộng tác với cả Scrum Team để tìm ra cách làm sao đạt được mục tiêu đó. Hiện nay có khá nhiều template cho mọi người tham khảo.

Khoa Đoàn: Chúng ta lại quay trở lại tâm điểm chính là sự công tác của Scrum Team, làm việc cùng nhau để mang lại giá trị cho người dùng.

Chee-Hong Hsia: Khi trở thành giá trị, thực tế khó khăn ở đây chính là chúng ta không thể dùng công thức để đo đếm giá trị. Cho đến cuối ngày, chúng ta vẫn đang tạo nên giá trị dựa trên Assumption (điều mà chúng ta nghĩ là giá trị). Cách duy nhất để đo lường giá trị chính là đem sản phẩm của bạn vào thị trường càng sớm càng tốt. Và tại đó, giá trị sẽ được chứng tỏ.

Khoa Đoàn: Cảm ơn anh về những chia sẻ ngày hôm nay! Qua đó, mọi người sẽ cùng nhau hiểu rõ về Velocity, Productivity. Đồng thời cần tập trung vào Goal, Sprint Goal. Điều này hỗ trợ chúng ta có thể mang đến giá trị thực cho người dùng. Một lần nữa, cảm ơn Chee-Hong về những chi sẻ hữu ích của anh ngày hôm nay!