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.

Một trong những giá trị thể hiện được một Scrum team có thành công và tiến bộ qua từng Sprint hay không, được thể hiện qua việc Scrum Team xác định được giá trị khách hàng cần, và có cải tiến/tối ưu công việc của mình cần làm trong Sprint để đạt được Sprint Goal hay không. Việc Scrum team xác định/hiểu được nhu cầu của khách hàng, và Development Team tự tối ưu hoá được công việc của mình trong Sprint là điều không dễ dàng, và có rất nhiều hiểu lầm và áp dụng KHÔNG đúng các công cụ và phương pháp như:

• Hiểu sai mong muốn của khách hàng (End User), hay xây dựng chức năng sản phẩm mà khách hàng không cần đến. Do tập trung làm vui lòng nhà đầu tư là người không trực tiếp sử dụng sản phẩm hay chức năng.
• Áp dụng DoD (Definition of Done) một cách máy móc.
• Tập trung quá nhiều vào tốc độ và số lượng, xem đó là KPI phải đạt được, nếu không thì Sprint đó bị xem như thất bại.
• Không có được Sprint Goal rõ ràng.
• Không biết cách tối ưu hóa dòng chảy giá trị.
• Quản lý kiểu cũ, người quản lý đốc thúc và kiểm tra chi lý công việc, ảnh hưởng đến self-organize của team.
• Và nhiều nữa…

Trong khuôn khổ bài này, tôi xin phép tập trung và yếu tố: tối ưu hóa dòng chảy giá trị. Những yếu tố khác đã được tôi chia sẻ qua những bài blog khác trước đây, bạn có thể tìm kiếm để tham khảo thêm.

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

Từ Scrum guide 2020 - Development Team được thay đổi thành Developer.

Developer là những người trực tiếp làm việc để tạo ta sản phẩm hoàn thiện, sử dụng được bởi người dùng.

Product Owner là như một CEO của sản phẩm, người có trách nhiệm tối ưu hoá giá trị sản phẩm đó mang lại cho người dùng.

Sprint Retrospective là cơ hội để Scrum Team nhìn lại và có được kế hoạch thay đổi và phát triển tốt hơn trong Sprint tiếp theo. 

Sprint Review là sự kiện diễn ra vào cuối Sprint, trước Sprint Retrospective. Có Time-box là 4 tiếng cho Sprint có độ dài một tháng, và có thể ít hơn nếu Sprint ngắn hơn.

Daily Scrum là sự kiện diễn ra mỗi ngày, có thời gian cố định là 15 phút. Daily Scrum nên diễn ra cùng thời điểm và địa điểm mỗi ngày, để mọi người dễ dàng nhớ và thực hiện, giảm thiểu sự phức tạp.

Sprint Planning là một sự kiện trong Scrum, cuộc họp này bao gồm Scrum Team. Trong cuộc họp, Scrum team xem xét, dự đoán sẽ làm gì trong Sprint tiếp theo và làm như thế nào để hoàn thành và phát hành sản phẩm thoả với Definition of Done.

Sprint là trái tim của Scrum, tạo ra nhịp, vòng lặp phát triển sản phẩm để phát hành đến người dùng. Sprint có thể xem là một dự án, trong đó Sprint sẽ giới hạn rủi ro của dự án trong 1 tháng hoặc ít hơn.

Product Increment là tổng của tất cả các Product Backlog Items hoàn thành trong Sprint đó với những giá trị của sản phẩm đã hoàn thành trong những Sprint trước đó.

Product Backlog là gì?

• Product Backlog là một danh sách chứa tất cả những thứ cần cho sản phẩm đó. Là một danh sách được quản lý và sắp xếp thứ tự bởi Product Owner.

Vài năm trước, tôi thường nghe thấy mọi người nói về việc: Scrum chỉ dành cho những dự án phần mềm và sản phẩm phần mềm. Điều này thực sự không thể tránh khỏi, khi ban đầu, Ken và Jeff xây dựng Scrum như một phương thức làm việc mới, thích hợp hơn cho lĩnh vực phát triển những sản phẩm phần mềm. Nhưng việc đó chỉ đúng vào những năm về trước.

Ngày nay, tôi ngày càng nghe nói nhiều hơn từ những người hay những tổ chức đã thành công trong việc áp dụng Scrum vào môi trường không phải là phần mềm. Mỗi lần nghe thấy những thông tin như vậy, càng khiến tôi tin vào tương lai của Scrum. Chính nó (Scrum), sẽ vươn xa ra khỏi môi trường phát triển phần mềm, và tiếp cận với một hướng rộng hơn, nói cách khác là có thể ứng dụng cho đa ngành nghề. Miễn là ngành nghề hay môi trường đó chứa đựng sự phức tạp, khó đoán và khó nắm bắt.

Vì sao lại như vậy? Vì hai lý do dưới đây:

Tôi muốn chia sẻ với các bạn một câu chuyện mà tuần rồi tôi có dịp nói chuyện với một bạn đang muốn có chứng chỉ PSM I. Câu chuyện tưởng chừng như đơn giản, tưởng như không có gì đáng đọng lại. Nhưng tôi lại tìm thấy một điểm khá hay và muốn viết ra đây để chia sẻ cùng mọi người.