Các sự kiện theo Flow
Kanban trong Scrum không đòi hỏi thêm bất cứ sự kiện nào ngoài những sự kiện đã được định ra trong Scrum Guide. Tuy vậy, việc sử dụng góc nhìn và số đo của flow trong các sự kiện của Scrum sẽ thúc đẩy hướng tiếp cận dựa trên thực nghiệm.
Sprint
Những thực hành bổ sung từ Kanban không thay thế Sprint của Scrum. Sprint và các sự kiện của nó tạo cơ hội cho việc kiểm tra và điều chỉnh sản phẩm lẫn quy trình. Có một quan niệm sai lầm phổ biến là các nhóm chỉ chuyển giao giá trị một lần mỗi Sprint. Thực tế là, họ phải chuyển giao giá trị ít nhất là một lần cho mỗi Sprint. Các nhóm sử dụng Scrum kết hợp Kanban sử dùng Sprint và các sự kiện của nó như một chu kỳ phản hồi cải tiến (feedback improvement loop là một chu trình từ khi nhận được yêu cầu đến khi hoàn thành yêu cầu và nhận được phản hồi của khách hàng) thông qua sự cộng tác trong kiểm tra và điều chỉnh Định Nghĩa Workflow và các số đo của flow.
Những thực hành của Kanban có thể giúp Scrum Team cải tiến flow và tạo ra một môi trường ra quyết định đúng lúc trong suốt Sprint dựa trên sự kiểm tra và thích ứng. Trong môi trường này, Scrum Team dựa trên mục tiêu của Sprint và sự cộng tác chặt chẽ trong Scrum Team để tối ưu các giá trị chuyển giao trong Sprint.
Sprint Planning
Một buổi Sprint Planning theo flow sẽ sử dụng các số đo của flow để bổ sung cho việc phát triển Sprint Backlog. Việc sử dụng chỉ số thông lượng trong quá khứ có thể giúp Scrum Team hiểu năng lực của họ đối với Sprint kế tiếp.
Daily Scrum
Một buổi Daily Scrum theo flow sẽ tập trung Developers vào vấn đề làm tất cả những gì có thể để bảo đảm bảo flow nhất quán. Trong khi mục tiêu của Daily Scrum giống như được định ra trong Scrum Guide, cuộc họp này được tổ chức xung quanh bảng Kanban và tập trung vào việc flow đang bị yếu ở đâu và hành động nào các Developers nên thực hiện để xử lý việc đó.
Một số việc khác có thể cân nhắc trong buổi Daily Scrum theo flow bao gồm:
- Mục công việc nào đang bị đình trệ và có thể làm gì để giải quyết?
- Công việc nào đang lưu thông chậm hơn mong đợi? Tuổi của các hạng mục việc đang thực hiện? Mục nào vi phạm hoặc sắp vi phạm SLE và Scrum Team cần làm gì để hoàn tất chúng?
- Có bất cứ điều gì chưa được thể hiện trên bảng có thể gây ảnh hưởng khả năng hoàn tất công việc hôm nay không?
- Nhóm có tìm ra được điều gì mới có thể ảnh hưởng kế hoạch sắp tới của Scrum Team không?
- Nhóm có vi phạm giới hạn WIP không? Và nhóm có thể làm được gì để bảo đảm hoàn tất các công việc đang thực hiện?
Sprint Review
Scrum Guide khái quát về buổi họp Sprint Review. Việc tìm hiểu các số đo của flow trong Kanban sẽ tạo ra cơ hội cho các trao đổi về việc theo dõi tiến độ hướng đến Product Goal. Việc đánh giá thông lượng có thể cung cấp thêm thông tin khi Product Owner thảo luận về các ngày phát hành dự kiến.
Sprint Retrospective
Một buổi Sprint Retrospective theo flow sẽ có thêm phần khảo sát các số đo của flow và những phân tích nhằm giúp cho việc xác định các điểm cần cải tiến mà Scrum Team có thể thực hiện cho quy trình của mình. Scrum Team sử dụng Kanban cũng kiểm tra và điều chỉnh định nghĩa ‘‘Workflow’’ nhằm tối ưu flow trong Sprint kế tiếp. Sử dụng biểu đồ flow tích lũy (Cumulative Flow Diagram - CFD) để trực quan hóa WIP của Scrum Team, ước tính Thời gian Chu Kỳ trung bình và Thông lượng trung bình cũng có thể có ích.
Bên cạnh Sprint Retrospective, Scrum Team nên tận dụng việc kiểm tra quy trình và các cơ hội điều chỉnh xuất hiện trong suốt Sprint.
Tương tự, những thay đổi cho định nghĩa ‘‘Workflow’’ của Scrum Team cũng có thể diễn ra bất cứ lúc nào. Bởi vì những thay đổi này sẽ tạo ra những ảnh hưởng cụ thể tới năng suất của Scrum Team, thay đổi diễn ra đều đặn theo nhịp của Sprint Retrospective sẽ giảm thiểu sự phức tạp, tăng sự tập trung, tính cam kết và sự minh bạch.
Increment
Scrum yêu cầu nhóm phải tạo ra (ít nhất) một Increment có giá trị, sử dụng được sau mỗi Sprint. Chủ nghĩa thực nghiệm trong Scrum khuyến khích việc tạo ra nhiều increments có giá trị trong Sprint để thực hiện việc kiểm tra và thích ứng nhanh chóng các chu trình phản hồi. Kanban giúp quản lý flow của những chu trình phản hồi đó một cách tường minh hơn và cho phép Scrum Team xác định những điểm tắc nghẽn, ràng buộc và khó khăn trở ngại để chuyển giao giá trị nhanh và thường xuyên hơn.
Lời kết
Scrum không phải là một quy trình hay một kỹ thuật. Nó là một cơ cấu tổ chức công việc, trong đó, chúng ta có thể xử lý các vấn đề thích ứng phức tạp trong khi vẫn chuyển giao sản phẩm một cách hiệu quả và sáng tạo, cho ra giá trị cao nhất có thể. Scrum Guide đã nói rõ, Scrum hoạt động tốt như một tập chứa cho các kỹ thuật, phương pháp và thực hành khác.
Các kỹ thuật tối ưu flow trong Kanban cung cấp cho Scrum Team cơ hội để kiểm tra đúng lúc đúng việc và dựa trên đó, điều chỉnh theo nhu cầu. Kanban đặc biệt tập trung vào tính minh bạch, tính trực quan, và flow thì tối ưu phản hồi, chủ nghĩa thực nghiệm và trên hết là chuyển giao giá trị.
Lịch sử phát triển và lời tri ân
Kanban được sử dụng trong lĩnh vực sáng tạo tri thức chủ yếu từ những năm 2006 trong một nhóm tại Corbis, một công ty cấp phép truyền thông ở Seattle. Những thực hành đó nhanh chóng lan rộng trong cộng đồng quốc tế lớn và đa dạng và theo thời gian, tiếp tục mở rộng, phát triển hướng tiếp cận.
Hướng dẫn này được phát triển bằng sự cộng tác giữa Scrum.org, cộng đồng Professional Scrum Trainer của Scrum.org, Steve Porter, Yuval Yeret và Daniel Vacanti.
Đặc biệt tri ân đến Glaudia Califano, Louis-Philippe Carignan, Charles Bradley, Jose Casal, Andy Hiles, Jesse Houwing và Julia Wester vì sự cộng tác của họ. Chúng tôi cũng biết ơn những người trong quá khứ đã góp phần đưa Kanban trở thành một chiến lược lean-agile thành công và khả thi.
Tiếng Việt