Nexus là gì?

Nexus, cũng giống như Scrum, nó là một Framework, được xây dựng trên khung xương sống là Scrum.
Nexus được tạo nên bởi Ken Schwaber và Scrum.org, với mục đích giúp cho các Scrum team đang làm việc trên cùng một product có thể tối ưu hoá năng suất và chất lượng sản phẩm.

Để "hiện thực hóa" bài blog về làm thế nào để apply Liberating Structures vào Sprint Retrospective, hôm nay Scrumviet đã có một buổi sáng thật vui cùng các anh chị và các bạn với meetup cùng chủ đề. Dưới đây xin phép chia sẻ một vài hình ảnh và video về meetup đã diễn ra.

Hi vọng những meetup sắp tới sẽ có ngày càng nhiều bạn tham gia và trải nghiệm về Liberating Structures.

Sprint Retrospective là một event quan trọng của Scrum (Xem thêm về Sprint Retropspective là gì?). Nhưng làm sao để dẫn dắt Scrum Team có được một Sprint Retrospective thật tốt là không dễ dàng. Nhiều Scrum team đã gặp vấn đề và không biết làm sao để cải thiện Sprint Retrospective, như:

• Đội nhóm lẩn tránh vấn đề, không ai muốn chia sẻ về vấn đề kinh niên mà Scrum Team đang gặp phải, dù cho Scrum Master cố gắng khơi gợi thế nào đi nữa.
• Đội nhóm làm Sprint Retrospective một cách cứng nhắc và không nhận được giá trị mà event có thể mang lại.
• Đội nhóm dễ lấn vào những vấn đề ngoài luồng, thiếu trọng tâm, và đôi khi Sprint Retrospective lại là nơi để các cá nhân diễn thuyết (chỉ 1 - 2 người nói), hoặc không tôn trọng tinh thần gốc là, cùng nhau nhìn lại và cải thiện công việc trong Sprint sau.

Để 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.

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".