Những ngày cuối tháng 9 thật tuyệt, vì Scrumviet lại có cơ hội được chia sẻ kiến thức cùng mọi người. Hai ngày qua là những trải nghiệm chia sẻ về Scrum, về nghề IT, Scrumviet cảm thấy có thật nhiều động lực và luôn mong muốn mình có thể làm tốt hơn nữa để mang những giá trị của Scrum đến với cộng đồng.

Xin chia sẻ cùng mọi người những hình ảnh của lớp học đã qua.

Khi áp dụng Nexus ngoài Sprint Backlog của từng Scrum team, chúng ta còn có Nexus Sprint backlog. Nexus Sprint backlog là Backlog của Nexus Integartion Team, được quản lý bởi họ.

Nexus Sprint backlog không chứa tất cả những Sprint Backlog Item, mà chỉ chứa những Sprint Backlog Items nào bị phụ thuộc lẫn nhau giữa các Scrum team, và những mối quan tâm tiềm ẩn có thể tạo ra sự phụ thuộc giữa các Scrum Team.

Sự phụ thuộc lẫn nhau nên được thể hiện rõ trong Nexus Sprint Backlog.

Cũng như những Artifact khác của Scrum, Nexus Sprint Backlog phải được Transparency với các bên liên quan.

Dưới đây là ví dụ của một Nexus Sprint backlog:

Mỗi ngày Scrumviet chọn một niềm vui, nhưng niềm vui lớn nhất là được chia sẻ Scrum cùng các anh chị và các bạn. Hôm nay Scrumviet xin chia sẻ với mọi người hình ảnh về lớp PSM vừa diễn ra cuối tuần qua.

​Scrum on!

Không có sự khác biệt giữa Product Backlog khi Scrum Team sử dụng Nexus. Trong cùng một product, thì chỉ nên có một Product Owner và một Product Backlog duy nhất. Đọc thêm về: Product Backlog.

Có một số sai lầm về cách sử dụng Product Backlog khi mở rộng Scrum team như là:

Việc nhiều Scrum Team cùng làm việc với nhau, sẽ dẫn dến nhiều sự phức tạp hơn, lúc này hơn bao giờ hết vai trò Scrum Master rất quan trọng:

• Scrum Master trong Nexus cần đảm bảo được Nexus được hiểu rõ và thực thi trên nhiều Scrum team của product.

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.

Chia sẻ các mối quan hệ điển hình, mà chúng có thể tạo ra những giá tốt hoặc sự rối loạn. (25 phút)

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

Sắp xếp các thách thức/khó khăn đang gặp thành các nhóm: đơn giản (simple), phức tạp (complicated), rắc rối (complex) và hỗn loạn (chaotic) (45 phút)