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.

Now - Next - Later Product roadmap là một công cụ giúp cho Product Owner có thể dùng để trình bày và truyền đạt ý tưởng về độ ưu tiên của các PBIs trong Product Backlog. Nó cũng được xem như là một cách trình bày Product Backlog của Product Owner nhằm nhấn mạnh và thể hiện rõ giá trị sản phầm nào có mức độ ưu tiên cao hơn. Cách trình bày này cung cấp cho nhóm và các bên liên quan một cách trực quan dễ hiểu và dễ dàng thay đổi trong bối cảnh những nhu cầu về sản phẩm thay đổi liên tục.

Pirate hay AARRR framework được tạo bởi Dave McClure và được chia sẻ vào năm 2007. Pirate hay AARRR framework là một công cụ giúp trực quan hoá mô hình kinh doanh thành những mảng nhỏ, nơi bạn có thể tập trung sự chú ý của mình để phát triển. Sở dĩ nó được gọi là mô hình/ framework ”cướp biển” là vì các chữ cái đầu tiên được viết thành AARRR (“Cướp biển thường hay nói AARRR!!!!”). AAARR ở đây là viết tắt của 5 vùng:

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.

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.

ICF (International Coaching Federation) đã định nghĩa "Coaching" là sự hợp tác với khách hàng qua một quá trình, kích thích tư duy và sáng tạo, truyền cảm hứng để họ phát huy tối đa tiềm năng cá nhân của mình. Cá nhân tôi nhận thấy, vì đây là một sự hợp tác (partnering) nên tôi không gọi khách hàng của mình là "khách hàng", mà là "bạn đồng hành" (partner). Bởi khi bạn coach một ai đó, đây không phải là mối quan hệ một chiều chỉ "cho và được nhận", mà đó là một kết nối qua lại. Trong buổi coach, người coach sẽ đóng vai trò là người bạn tò mò về những điều khách hàng mong muốn đạt được, người coach sẽ biết cách khuyến khích, khơi gợi suy nghĩ trong người bạn của mình để họ (coachee) tự tạo mục tiêu, khám phá giải pháp, lên kế hoạch, chiến được và tự có trách nhiệm thực hiện nó. Đây giống như một buổi khiêu vũ giữa bạn (coach) và người được coach (coachee).

Khi xây dựng một sản phẩm hay dịch vụ, thì trải nghiệm người dùng (User Experience, hay còn gọi là UX) là điều rất quan trọng. Vì khách hàng chỉ đánh giá cao sản phẩm của bạn khi họ có trải nghiệm tốt với sản phẩm đó. Vậy, những công cụ nào có thể giúp chúng ta ghi nhận và phân tích về khách hàng, người sử dụng sản phẩm/ dịch vụ? Hôm nay chúng ta sẽ đi qua hai công cụ: Persona và Proto-Persona, để phân biệt sự khác nhau giữa hai công cụ này và hiểu hơn về cách sử dụng chúng nhé.

Hôm nay Scrumviet trở lại với loạt bài về Sprint Retrospective. Format dành cho Sprint Retrospective lần này Scrumviet muốn giới thiệu đến các bạn chính là: Like & Dislike.

Like & Dislike Sprint Retrospective là phương thức dễ setup và rất gần gũi, vì nó lấy ý tưởng từ việc sử dụng mạng xã hội (facebook, Linkedin…). Đơn giản là bạn sẽ cùng nhóm nhìn lại Sprint vừa qua, và chia sẻ về những điều bạn thích (Like), và những điều bạn không thích (Dislike).

Một trong những đặc điểm của Scrum Team là tính Self-managed. Khi có được Self-managed thì Scrum Team thường sẽ cam kết và có được sự sáng tạo hơn trong việc phát triển giá trị của sản phẩm. Nhưng làm sao để Scrum team có thể Self-managed là không dễ, người Scrum Master luôn phải biết cách nuôi dưỡng và xây dựng nó. Chính vì lý do này, mà hai trong những hình thái mà người Scrum Master phải giỏi đó là "Facilitate" và "Coaching". Tại sao lại như vậy? Đơn giản vì khi Scrum Master facilitate hay coaching, anh ấy/ cô ấy sẽ không làm ảnh hưởng đến khả năng Self-managed của Scrum Team, nhưng vẫn giúp Scrum Team có thể hợp tác, thảo luận, qua đó có được quyết định tốt nhất cho mình.

Bài viết này tôi xin chia sẻ về những sai lầm trong vai trò Product Owner (PO) mà tôi thường thấy nhất (Tôi phân tích và tổng hợp lại thành một vài sai lầm thường gặp nhất trong rất nhiều sai lầm khác nhau). Mục tiêu là để các Scrum Team nhận thấy được những ảnh hưởng từ những sai lầm này, để tránh hoặc thay đổi cách làm việc của mình, qua đó có thể xây dựng một Scrum Team tốt hơn.

Chú ý: Một Product Owner có thể đang mắc một hoặc nhiều sai lầm được liệt kê ở dưới cùng lúc.

Empathy Map là công cụ giúp chúng ta có thể liên kết, và hình dung rõ hơn về hành vi và cảm nhận của người dùng sản phẩm, qua đó có được sự hiểu biết sâu hơn về khách hàng, để có sự điều chỉnh phù hợp làm hài lòng khách hàng hơn. Trong quá trình bạn lập lên biểu đồ, những khoảng trống, hay câu hỏi chưa được trả lời sẽ giúp bạn nhận ra được những thiếu sót, lỗ hỗng nào mà bạn chưa nhận ra để cải thiện.

Công cụ này được sử dụng rất nhiều bởi các nhóm làm việc chuyên về UX (User Experience), cũng như là một công cụ chủ lực cho Product Owner hiểu và định hình hành vi của khách hàng với sản phẩm.

Chúng ta lại trở lại với loạt bài về Sprint Retrospective format, và hôm nay tôi muốn chia sẻ với các bạn về một chủ đề khá hay cho một buổi Sprint Retrospective, đó là tập trung nhìn lại Scrum Values và tìm cách cải thiện nó qua mỗi Sprint.

Scrum Values là format giúp team bạn có thể tập trung thảo luận và có cái nhìn rõ hơn về các giá trị của Scrum trong team. Nó giúp transparent về mức độ của Scrum value đang tồn tại trong nhóm, và trong công việc hằng ngày. Qua đó Scrum team có thể nhìn nhận và có cách để nuôi dưỡng những giá trị này càng lớn mạnh hơn qua từng Sprint.

Cách thức để tổ chức format này rất dễ, các bước thực hiện như sau (đây là cách thức thực hiện mà riêng tôi đã trải nghiệm và điều chỉnh cho hợp lý với kinh nghiệm cá nhân của mình):

Những dấu hiệu nào cho bạn biết rằng buổi Sprint Retrospective đang không thực sự hiểu quả, hoặc không mang lại giá trị mong đợi? Và chính bạn, là Scrum Master phải chú ý đến và có sự hỗ trợ tương ứng với team.

Dưới đây tôi sẽ liệt kê nhanh những dấu hiệu của một buổi Sprint Retrospective mà tôi thường thấy nhất:

Nhiều bạn nói với tôi rằng, Scrumviet đã chia sẻ nhiều về cách tổ chức Sprint Retrospective rồi, vậy còn Sprint Review thì sao? Làm sao để Scrum Master có thể tổ chức một buổi Sprint Review hiệu quả? Nhiều Scrum Team cùng làm việc trên một sản phẩm, vậy cuối Sprint, họ tổ chức Sprint Review như thế nào?

Hôm nay, tôi chia sẻ với các bạn một cách để tổ chức một buổi Sprint Review thật năng động và hiệu quả dành cho nhiều Scrum Team cùng làm việc trên một sản phẩm. Phương thức này được gọi là Science Fair / Expo (Hội chợ, hay cuộc triển lãm khoa học). Sở dĩ nó được gọi tên như vậy là vì cách thức thực hiện buổi Workshop/ Sprint Review này như một buổi triển lãm vậy, hình thức giống như khi bạn đến những buổi triển lãm xe.