Product Owner là tên gọi mới/ khác của Business Analyst?
Tôi không hiểu sự hiểu lầm này đến từ đâu, nhưng càng ngày tôi càng nhận thấy nhiều người hiểu lầm về hai vai trò này. Đơn giản, Product Owner (PO) là một vai trò trong Scrum team, và nó chẳng có liên quan hay lịch sử gì từ Business Analyst cả.
Tôi không hiểu sự hiểu lầm này đến từ đâu, nhưng càng ngày tôi càng nhận thấy nhiều người hiểu lầm về hai vai trò này. Đơn giản, Product Owner (PO) là một vai trò trong Scrum team, và nó chẳng có liên quan hay lịch sử gì từ Business Analyst cả.
Product Owner là leader của sản phẩm
“About the work” là sprint Retrospective format đơn giản, và tập trung vào việc nhìn lại cách làm việc của Scrum team trong Sprint vừa qua. Nếu bạn đang tìm kiếm một format mà nó hướng Scrum team đến việc làm sao để cải thiện cách làm việc và hiệu quả hơn thì bạn có thể sử dụng format này.
![[Sprint Retrospective] About the work](/uploads/1/1/9/1/119155464/sprint-retrospective-about-the-work_orig.png)
[Sprint Retrospective] About the work - Scrumviet
Bên cạnh Coaching, thì một Scrum Master cần phải biết facilitate. Vì sao? Mỗi Sprint, Scrum Master đều phải facilitate Sprint Planning, Sprint. Review, Sprint Retrospective và những buổi họp khác của Scrum team khi cần. Ngoài ra chính Scrum Master cũng cần hỗ trợ những sự kiện hay buổi họp của tổ chức. Chính vì vậy việc biết, và hiểu được làm thế nào để facilitate một event hay workshop là một kỹ năng vô cùng quan trọng bên cạnh Coaching của một Scrum Master.
Professional Facilitating - Scrumviet
Vài năm gần đây, khi Scrum Guide 2020 đề cập đến Product Backlog phải cam kết với Product Goal, Sprint Backlog phải cam kết với Sprint Goal, và trở thành một phần không thể thiếu trong Scrum framework. Các Scrum team bắt đầu nghiêm túc hơn và áp dụng điều này vào trong việc xây dựng Sản Phẩm của mình. Nhưng đâu đó vẫn có rất nhiều Scrum team dù đang cố gắng để áp dụng, nhưng vẫn gặp rất nhiều khó khăn và loay hoay không biết làm thế nào để có thể xây dựng một mục tiêu tốt và giúp Sản Phẩm thành công.
Lý do cho việc Scrum Guide 2020 đề cập về Sprint Goal, và Product Goal đó là vì muốn các Scrum team phải có Mục Tiêu Chung. Mục Tiêu Chung luôn là thứ quan trọng, dù trước đó Scrum Guide không đề cập đến nó. Cơ bản Mục Tiêu Chung giúp cho Scrum team trở nên Tự Chủ có ý thức. Vì sự Tự Chủ sẽ đến đến hỗn loạn nếu nhóm không có được một Mục Tiêu Chung. (Xem hình dưới)
Lý do cho việc Scrum Guide 2020 đề cập về Sprint Goal, và Product Goal đó là vì muốn các Scrum team phải có Mục Tiêu Chung. Mục Tiêu Chung luôn là thứ quan trọng, dù trước đó Scrum Guide không đề cập đến nó. Cơ bản Mục Tiêu Chung giúp cho Scrum team trở nên Tự Chủ có ý thức. Vì sự Tự Chủ sẽ đến đến hỗn loạn nếu nhóm không có được một Mục Tiêu Chung. (Xem hình dưới)
Nhiều lúc, là một Scrum Master bạn sẽ cần phải facilitate giúp tập hợp Scrum team mới. Việc các thành viên mới lần đầu làm việc như một team cần có những sự kiện, giúp nhóm làm quen, xác định, và hiểu rõ vai trò, cũng như lý do vì sao chúng ta cần là một đội là rất cần thiết.
Xác định vai trò và trách nhiệm là một điều nên làm, vì nó sẽ giúp mọi người hiểu được vai trò và đóng góp của mình sẽ như thế nào cho sản phẩm trong thời gian sắp tới. Hôm nay Scrumviet xin phép chia sẻ cùng các bạn một format giúp cho các Scrum Master có thể dễ dàng giúp nhóm của mình xác định rõ ràng vai trò và trách nhiệm của nhau.
Xác định vai trò và trách nhiệm là một điều nên làm, vì nó sẽ giúp mọi người hiểu được vai trò và đóng góp của mình sẽ như thế nào cho sản phẩm trong thời gian sắp tới. Hôm nay Scrumviet xin phép chia sẻ cùng các bạn một format giúp cho các Scrum Master có thể dễ dàng giúp nhóm của mình xác định rõ ràng vai trò và trách nhiệm của nhau.
Roles and Responsibilities - Scrumviet
Trong bài thứ 3 của loạt bài công cụ hỗ trợ Scrum team đưa ra quyết định, Scrumviet xin chia sẻ cùng các bạn một biểu đồ tương quan khác giữa xác suất xảy ra và lợi ích nhận lại, để giúp Scrum Master có thể linh hoạt và sử dụng khi cần thiết. Biểu đồ này rất hữu dụng để giúp Scrum team xác định được phần trăm của sự mơ hồ, khó đoán (Liệu dịch vụ hay chức năng mới xây dựng đạt được giá trị như kỳ vọng), kèm với lợi ích có thể nhận lại nếu dịch vụ hay chức năng mới xây dựng có mang về thành công mong muốn cho sản phẩm.
Tiếp theo chuỗi bài giúp cho Scrum Master có thể facilitate để Scrum team có thể đưa ra được quyết định tốt nhất. Hôm nay Scrumviet chia sẻ cùng các bạn một biểu đồ khác, thể hiện sự tương quan giữa sự nỗ lực và giá trị (Effort x Value). Biểu đồ này có thể sử dụng cùng với biểu đồ khả thi x hữu ích (Feasible x Useful) để giúp Scrum team có được quyết định tốt nhất có thể.
Là một Scrum Master, nhiều lúc bạn sẽ cần phải facilitate giúp Scrum team quyết định được đâu là giá trị của sản phẩm nên làm và theo đuổi, đâu là những giá trị chưa cần đến trong lúc này. Bạn nắm được nhiều cách thức để tổ chức và tạo điều kiện cho Scrum team trao đổi bao nhiêu, thì Product Owner và Developer càng dễ dàng thảo luận và tối ưu hoá được quyết định của mình bấy nhiêu. Vì vậy hôm nay Scrumviet giới thiệu cùng bạn một phương pháp đơn giản, nhưng mạnh mẽ, giúp Scrum team có thể dễ dàng xác định đâu là giá trị sản phẩm hữu ích cho người dùng, và liệu nó có khả thi để thực hiện hay không?
Biểu đồ khả thi x hữu ích (Feasible x Useful)
Thế giới ngày càng vận hành như một tay đua kiệt xuất, nhanh và vô cùng khó lường. Người dùng ngày càng đòi hỏi nhiều hơn những giá trị mới, khiến những gì được cho là tốt của ngày hôm nay nhanh chóng trở nên bình thường. Dẫn đến các doanh nghiệp phải nhanh hơn nữa để tìm ta giá trị mới, đáp ứng, và làm hài lòng khách hàng. Việc liên tục phải có những giá trị mới, đòi hỏi phải có những sáng tạo, ý tưởng chưa từng có, và làm thế nào để xác định đó là điều khách hàng cần. Đây là một bài toán khó. Lúc này, chỉ dùng những kiến thức, hiểu biết của hiện tại, để giải bài toán này, “dự đoán” được những thay đổi, và đáp ứng được nhu cầu từ khách hàng là không đủ.
Trong những tổ chức đang áp dụng Scrum vào công việc, rất nhiều tổ chức đang áp dụng Scrum ở quy mô lớn, nhiều Scrum team cùng làm việc trên một sản phẩm. Việc mở rộng nhiều Scrum team cùng làm trên một sản phẩm sẽ là cơ hội cho sản phẩm được phát triển nhanh hơn, mang lại nhiều giá trị hơn đến người dùng. Nhưng nó cũng chứa đựng nhiều thử thách và khó khăn trong việc làm sao để các Scrum team phối hợp với nhau một cách hiệu quả. Có một sai lầm cố hữu mà tôi nhận thấy đa phần các nhóm Scrum cùng làm trên 1 sản phẩm mắc phải, đó là có nhiều hơn 1 Product Owner cho sản phẩm đó. Không phải tự nhiên mà Scrum guide trực tiếp đề cập đến việc:
The Product Owner is one person, not a committee - Scrum guide 2020
Vậy khi một sản phẩm, có nhiều hơn một Product Owner thì chuyện gì sẽ xảy ra? Hãy cùng tôi điểm qua những vấn đề mà sản phẩm, và Scrum team sẽ gặp phải nếu có nhiều hơn một Product Owner nhé:
Khi Scrum team đã có một thời gian làm việc cùng nhau, và bạn muốn team có thể cùng chia sẻ cảm xúc về khoảng thời gian đã qua, thì Peaks & Valleys Timeline là một phương pháp dễ và trực quan nhất.
![[Sprint Retrospective] Peaks & Valleys Timeline](/uploads/1/1/9/1/119155464/sprint-retrospective-peaks-valleys-timeline_orig.png)
[Sprint Retrospective] Peaks & Valleys Timeline
Scrum dù đã bước qua tuổi 26, và được ứng dụng rộng rãi trên toàn thế giới. Nhưng hiện nay vẫn còn rất nhiều những hiểu lầm cơ bản về Scrum. Những hiểu lầm này tưởng chừng vô hại, nhưng lại khiến cho nhiều tổ chức bị cản trở trong việc tiếp cận và nhận được những giá trị mà Scrum có thể mang lại cho họ. Hôm nay tôi xin phép điểm qua nhanh 4 hiểu lầm thông thường nhất về Scrum trong bài viết này:
Hôm nay Scrumviet giới thiệu đến các bạn một phương thức có thể áp dụng cho Sprint Retrospective rất hiệu quả. Vì Want, Have, Don’t Want, Don’t Have là Sprint Retrospective format dựa trên bài thực hành coaching, giúp người thực hành chúng có thể tập trung vào những điều mình đang muốn có được, và mình không muốn có. Đây là một cách giúp Scrum team có thể hướng đến giải pháp, để có thể làm tốt hơn trong Sprint tiếp theo.
[Sprint Retrospective] Want, Have, Don’t Want, Don’t Have - Scrumviet
Drop, Add, Keep, Improve hay còn được gọi là DAKI - Sprint Retrospective, là một trong những Format cơ bản, dễ áp dụng cho Scrum team, nhưng lại mạnh mẽ và mang lại nhiều giá trị giúp team nhìn lại những vấn đề cần được giải quyết trong Sprint vừa qua.
![[Sprint Retrospective] Drop, Add, Keep, Improve](/uploads/1/1/9/1/119155464/screen-shot-2021-06-01-at-14-35-48_orig.png)
[Sprint Retrospective] Drop, Add, Keep, Improve - Scrumviet
Start - Stop - Continue là một format dành cho Sprint Retrospective cực kỳ đơn giản, và được áp dụng rất nhiều bởi các Scrum team. Đơn giản vì format này rất dễ hiểu và cách chuẩn bị cũng dễ dàng. Start - Stop - Continue cùng với Like & Dislike là hai format cơ bản nhất các Scrum Master mới bắt đầu đảm đương vai trò SM có thể tìm hiểu và áp dụng, vì tính hiệu quả và đơn giản của chúng.
![[Sprint Retrospective] Start - Stop - Continue](/uploads/1/1/9/1/119155464/screen-shot-2021-05-30-at-14-02-22_orig.png)
[Sprint Retrospective] Start - Stop - Continue
Copyright © 2023, Scrumviet. All rights reserved.