Từ ngày 24 tháng 2 năm 2024, Scrum.org đã chính thức đổi tên khoá học Professional Scrum Master II thành Professional Scrum Master - Advanced (PSM-A). Lý do cho việc thay đổi này là:
Mọi ưu đãi khác khi tham dự khoá học Professional Scrum Master - Advanced (PSM-A) là không đổi: Tất cả những học viên hoàn thành khoá học PSM-A sẽ nhận được password để tham dự kỳ thi đánh giá Professional Scrum Master II (PSM II). Nếu bạn tham dự thi trong vòng 14 ngày và điểm chưa đạt được ít nhất 85%, bạn sẽ được cấp thêm một lần dự thi thứ hai mà không phải đóng thêm bất cứ khoản chi phí nào. Bạn cũng sẽ được ưu đãi giảm 40% cho kỳ thi PSM III tiếp theo.
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)
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é:
FAST Goal là gì?
FAST Goal là một phương thức đặt mục tiêu và đo lường cho nhóm hay tổ chức tương đối mới, được Donald Sull và Charles Sull chia sẻ gần đây vào năm 2018. Trong bài viết đầu tiên của mình Donald Sull và Charles Sull chia sẻ rằng họ đã nghiên cứu và thống kê hơn 500.000 công ty, tổ chức thành công về cách tạo ra mục tiêu và đạt được chúng. Họ đã tìm ra công thức thành công chung của những công ty, tổ chức này trong việc đặt ra và đạt mục tiêu, và gọi nó là “4 nguyên tắc cốt lõi” để đặt một mục tiêu hiệu quả.
FAST Goal là phương thức được cấu thành từ 4 nguyên tắc cốt lõi:
OKR là gì?
OKR (viết tắt của Objectives and Key Results) là một công cụ mạnh mẽ giúp thiết lập và đo lường mục tiêu (GOAL). Andrew Grove được biết đến như là cha đẻ của OKR, khi ông đã giới thiệu cách ông áp dụng OKR với Intel trong quyển sách của mình được xuất bản năm 1983 - High Output Management.
Cũng vì lý do này mà OKR còn được biết đến với cái tên "iMBOs" (Intel Management by Objectives). John Doerr đã tiếp cận được OKR khi còn là người bán hàng cho Intel, và sau này ông đã giới thiệu nó đến với Google (lúc này khoản vào năm 1999). Sau đó OKR được công nhận tại Google, và nhanh chóng trở thành một phần văn hoá tại đây. Đây cũng chính là bàn đạp giúp OKR trở nên nổi tiếng và được nhiều công ty áp dụng như ngày nay.
Giữa những năm 1990 - Harvard Business School đã tài trợ cho nghiên cứu của Anita L. Tucker và Amy C. Edmondson; ở đó nhóm nghiên cứu quan sát, phỏng vấn các lãnh đạo và thành viên của nhóm về tần suất mắc lỗi/ sai lầm xảy ra trong một khoản thời gian nhất định. Nghiên cứu cho thấy những đội có mối quan hệ TỐT giữa các thành viên và quản lý thường có tần suất mắc lỗi cao hơn gấp 10 lần những đội mà mối quan hệ giữa các thành viên và quản lý KHÔNG TỐT! Điều này thật thú vị.
System thinking là gì?
System thinking (tư duy hệ thống) là một cách tiếp cận giải quyết vấn đề bằng cách xem xét vấn về đó như một phần của một hệ thống tổng thể, thay vì chỉ xem và giải quyết vấn đề đó một cách độc lập và riêng lẻ. Trong khoa học nghiên cứu về cách hệ thống vận hành, người ta lập luận rằng cách duy nhất để hiểu đầy đủ lý do tại sao một vấn đề hoặc yếu tố xảy ra và tồn tại là hiểu mối liên quan giữa các phần đến tổng thể. Việc giải quyết vấn đề một cách riêng lẻ độc lập nhưng loại bỏ những ảnh hưởng qua lại/ liên kết đến hệ thống một cách tổng thể có thể mang lại những hiểm hoạ khôn lường cho toàn bộ hệ thống.
Wrong determination
People often think that persistence or not giving up will bring them to the success. However looking back to your past, how many times you tried, but did not get a good result? Your determination faced with many failures than successes or even just only failures? Did you ask yourself "Why" and "What is missing to be successful"? Let's talk about football. Does the football team want to win the cup or want to win all the matches? If you put your expectations on how to win every match, that’s more challenging and might be impossible. But if the goal to win a cup, it will give you a better chance and strategies like you do not need to win all the matches (by accepting the loss or draw in some matches). Or even have a long preparation to be the champion in the couple years rather than this year . Having persistence and determination is good but putting it on the right thing, and the right time is more important. The journey to reach the goal is a long journey. And you can have a lot of strategies to achieve it. Knowing how to inspect and adapt the plan or strategy to help you reach the goal; once you failed, you learn from it, change your plan, and continue. Trong thời đại V.U.C.A, mọi thứ trở nên hỗn loạn, khó lường hơn. Nơi kiến thức của ngày hôm qua đã không còn đúng vào hôm nay nữa. Sự cạnh tranh trở nên ngày càng khốc liệt, và công nghệ đã góp phần lớn dẫn dắt sự thay đổi khó lường này. Bạn dễ tìm thấy ví dụ như một hãng Taxi truyền thống sẽ không thể ngờ được, miếng bánh thị phần sẽ rơi vào tay của một hãng Taxi công nghệ, mặc dù họ không cùng ngành nghề với nhau. (Grab và Uber)
Trong kỷ nguyên này đòi hỏi các doanh nghiệp phải thay đổi để trở nên linh hoạt hơn, họ không thể dùng mãi một công thức là kinh nghiệm để chiến thắng hay nắm phần thắng trong tương lai nữa. Mà họ cần một phương thức mới, giúp họ có thể nhanh chóng ra quyết định và thay đổi theo nhu cầu của thị trường một cách nhanh nhất, và Agile là chìa khoá. Nhưng làm thế nào để thay đổi?
Có nhiều câu hỏi và mối quan tâm về việc quản lý rủi ro xoay quanh việc trao quyền cho Scrum Team như:
Làm thế nào để đảm bảo thành công cho Product nếu Product Owner không hiểu nhiều về Product hoặc chưa đủ kỹ năng? Làm sao Product Owner quyết định được Business Value nào sẽ là trong 20% mang lại 80% giá trị? (80/20 - Pareto Principle) Việc trao quyền cho Development Team dẫn đến nhiều rủi ro tiềm ẩn? Làm sao Development Team biết nên làm gì và làm thế nào để tạo ra Done Increment?
Để trả lời cho câu hỏi này chúng ta cần đi qua hai định nghĩa: Team và Self-Organizing.
Team là gì? Team là một nhóm bao gồm những cá nhân làm việc cùng nhau để hoàn thành một công việc nào đó. Đây là một nhu cầu tự nhiên, khi những cá nhân cảm thấy không thể giải quyết công việc một mình. Self-Organizing là gì? Self-Organizing là tính tự tổ chức. Một nhóm hay cá thể trong tổng thể được gọi là có tính tự tổ chức, khi nhóm hay cá thể đó có thể tự vận hành, kiểm tra và thích nghi với hoàn cảnh đang đối mặt. Scrum có 3 Artifacts là Product Backlog, Sprint Backlog và Product Increment. Mỗi Artifact đều có một vai trò rõ ràng và rất quan trọng với Scrum. Qua mỗi Artifact, giá trị của sản phẩm được minh bạch tối đa để mọi người có thể nhận biết và hiểu rõ được. Từ đó giúp cho Scrum Team có thể tối ưu hoá sản phẩm bằng chủ nghĩa kinh nghiệm: Transparent, Inspection, và Adaptation. Bài này tôi sẽ không nói nhiều về chi tiết của từng artifacts (để xem chi tiết các bạn có thể click vào link để xem những bài viết trước) mà sẽ nói qua về việc tại sao Artifacts lại quan trọng với sản phẩm. Và dòng chảy giá trị sản phẩm được tối ưu hoá thế nào qua Product Backlog, Sprint Backlog và Product Increment.
Nội dung đã được cập nhật theo bản Scrum guide 2020
Nhiều năm trước, tôi bắt đầu tìm hiểu và quan sát cách thức hoạt động của các dự án phần mềm. Lý do tôi quan tâm đến việc này là vì, nhiều dự án thậm chí đã rất thành công trong việc deliver đúng hạn, đạt được đúng yêu cầu đề ra ban đầu, và hoàn thành trong chi phí cho phép. Tuy nhiên, khi nó được đưa ra thị trường thì không ai sử dụng cả. Sau đó sản phẩm đó cũng chết đi để lại nhiều sự lãng phí trong đầu tư và sức lực của các bên để đảm bảo nó được hoàn thành. Từ đó, trong đầu tôi luôn tồn tại một câu hỏi: Điều gì tạo ra khoảng cách giữa một sản phẩm thành công, được đón nhận bởi người dùng và một sản phẩm thất bại? Qua nhiều năm quan sát, tôi rút ra được một điều, một trong những lý do sản phẩm không được đón nhận như nó được kỳ vọng đa phần là vì nó bị đánh giá sai giữa "Input", "Output" và "Outcome". Bạn có tự hỏi, thành công giá trị thế nào? Câu hỏi này không dễ trả lời, và sẽ khác với mỗi người. Vì sao? Vì giá trị của thành công sẽ bằng với giá trị của những thất bại mà bạn đã trải qua để đạt được thành công đó.
Chúng ta luôn sợ thất bại, xem thất bại là sự xấu hổ. Vị của sự thất bại luôn không hề dễ nếm, mỗi khi thất bại, chúng ta dễ buông bỏ, chạy trốn khỏi nó. Nhưng để có được thành công, thì bạn phải chấp nhận thất bại, hay nói đúng hơn là học từ thất bại, để làm đúng hơn, tốt hơn. Empiricism is built by 3 pillars, Transparency, Inspection and Adaption. People used to talk about how to inspect and adapt, but did not stress on transparency. It likes you can't stand on the three-legged table while it lost one leg.
Transparency is important! No transparency, no data. How do we inspect and adapt? How do we have continuous improvement? It like walking in the darkness. |