Little’s Law - Công thức quan trọng cho Scrum với Kanban

Little’s Law là gì?

Little’s Law là một định lý của John Little. Đơn giản là một công thức dùng để thể hiện mối tương quan giữa ba giá trị:

• Work in Progress (WIP): Là số lượng các công việc đã bắt đầu nhưng chưa kết thúc. Lưu ý: sự khác biệt giữa WIP và Limited WIP (Limited WIP là thông số giới hạn nhóm đặt ra để giới hạn số lượng công việc có thể làm cùng lúc). Các nhóm có thể sử dụng WIP để cung cấp sự minh bạch qua đó dựa trên dữ liệu đó nhóm có thể biết được sẽ giới hạn WIP như thế nào và cải thiện dòng chảy của giá trị.
• Cycle Time: Là khoản thời gian khi một mục công việc bắt đầu và khi một mục công việc kết thúc. 
• Throughput: Số lượng công việc được hoàn thành trên một đơn vị/ khoản thời gian. (Ví dụ: Nhóm A hoàn thành 180 points công việc trong vòng 2 tuần.) (Trong một số trường hợp được hiểu là Lead Time).

​Công thức Little’s Law như sau:

Average Cycle Time = Average Work In Progress / Average Throughput

Lấy ví dụ với Sprint 2 tuần (10 ngày làm việc):

WIP trung bình của team bạn là 15, Cycle Time trung bình là 5, và Thoughtput cho 2 tuần sẽ là trung bình sẽ là = 3

Với ví dụ này đơn giản bạn sẽ hiểu được, khả năng trung bình team bạn mỗi Sprint hoàn thành được 3 items. -> Team của bạn có khả năng phải cần 5 Sprints để hoàn thành 15 items (bạn hãy chú ý từ "khả năng" của tôi, vì không điều gì là chắc chắn cho con số đó cả, rất nhiều điều có thể làm thay đổi nó, như nghỉ bệnh, hay những yếu tố bất ngờ khác). Qua đó đơn giản muốn giảm Cycle Time, dễ nhất bạn sẽ cần phải giảm Work In Progress.

Công thức Little’s Law cho ta điều gì?

Công thức này không phải là một phép màu, nó không giúp team bạn làm nhanh hơn hay tốt hơn bằng cách tính toán. Nhưng nó mang lại cho bạn sự nhận biết về giá trị của việc làm ít đi nhưng được nhiều hơn. Hãy đi qua thêm một ví dụ khác nhé:

Qua công thức này bạn đã nhận thức được mối liên hệ bởi ba yếu tố: WIP, Cycle Time, Throughput.
​
Điều này sẽ giúp bạn hiểu rõ mối quan hệ chặt chẽ này, sẽ không có phép màu xảy ra nếu bạn đơn thuần muốn tăng WIP lên 60 nhưng vẫn giữ Cycle Time ở mức 5 (??? bạn đừng ngạc nhiên về giả thuyết này, tôi đã làm việc với rất nhiều team, khi các nhà quản lý chỉ đơn thuần push thêm việc nhưng vẫn giữ deadline đó thôi). Muốn đạt được điều đó bạn sẽ phải thay đổi/ cải tiến Throughput, và Throughput không phải là yếu tố có thể cải thiện ngay lập tức và chính nó cũng là một thứ dễ bị thay đổi bởi tác động bên ngoài.

Vì sao Throughput không phải là yếu tố có thể cải tiến ngay lập tức như Cycle Time hay Work In Progress? Đơn giản vì việc hoàn thành một công việc trong bao lâu là yếu tố gần như tương đối nếu nó được gắn thêm những yếu tố sau:

• Chất lượng: Mức độ chất lượng có thể chấp nhận của sản phẩm là gì? Team cần bao nhiêu nỗ lực để hoàn thành công việc ở mức độ chất lượng đó?
• Multi-tasking: Thành viên trong nhóm đang làm bao nhiêu việc cùng lúc? Bạn có biết Multi-tasking sẽ làm giảm năng suất?
• Team work: Mức độ hiểu nhau hay mức độ hợp tác của team bạn đang thế nào? Là team mới hay đã làm cùng nhau lâu năm? Hiện đang có mâu thuẫn giữa các thành viên không?
• Kiến thức hay kỹ năng: Team bạn đang có đủ kiến thức và kỹ năng để hoàn thành công việc hiện tại? Tất cả các thành viên đều có thể đảm đương công việc như nhau, hay có những kỹ năng mà chỉ một vài thành viên có?
• Và nhiều yếu tố ngoại cảnh khác nữa…

Qua đó bạn sẽ thấy được Throughput là một yếu tố không dễ để thay đổi ngay. Mà nó là một quá trình và sự cố gắng của cả Scrum team để cùng nhau cải thiện qua mỗi Sprint.

Kết luận:

1. Khi làm vai trò Product Owner của Scrum team, Little’s Law là một công cụ hữu dụng giúp tôi tham chiếu và hiểu được khả năng hiện tại của team, qua đó có cách tiếp cận tốt nhất cho sản phẩm của mình. Nếu team chỉ có thể deliver được 3 items mỗi Sprint, thì tôi cần có chiến lược cho sản phẩm của mình phù hợp. Thay vì cố gắng ép nhóm làm nhiều nhất có thể, tôi sẽ tìm hiểu rõ điều gì là thật cần thiết và ưu tiên chúng, để làm sao deliver ít nhưng mang lại giá trị lớn nhất có thể (20/80). Đây là một nghệ thuật ra quyết định mà mỗi người Product Owner cần phải biết và hiểu rõ.
2. Trong quá trình làm việc, tôi cũng đã thấy rất nhiều Product Owner đưa ra mong muốn quá nhiều hay thậm chí là Developer, đã cố gắng giải quyết nhiều công việc hơn khả năng của họ hiện tại trong một Sprint. Và rồi, đến cuối Sprint, họ thậm chí không thể xong được việc nào cả, hay chấp nhận xong trên một mức độ chất lượng kém. Hãy dùng dữ liệu, và Little’s Law, để xác định về khả năng hiện tại của mình qua đó có chiến lược phù hợp nhất.
3. Scrum Master hãy xem Little’s Law là tham chiếu và "Coach Scrum Team" của mình hiểu được giá trị của việc làm ít đi nhưng mang lại giá trị nhiều hơn. Qua đó tập trung vào giúp PO nhận thức được việc deliver ít hơn nhưng mang lại outcome và impact lớn, thay vì deliver nhiều nhưng chất lượng thấp. Giúp Scrum team cải thiện Throughput qua việc hỗ trợ giải quyết những trở ngại (impediment), giúp team ngày càng tốt hơn qua mỗi Sprint, nâng cao kỹ năng và kiến thức qua việc tối ưu hoá Self-organize, và Cross-functional bằng chủ nghĩa kinh nghiệm.

-------------------------
Xin lưu ý, đây là loạt bài nằm trong loạt bài về kiến thức cơ bản khi áp dụng Kanban vào Scrum team. Nếu bạn chưa xem qua những kiến thức hay định nghĩa cơ bản về Scrum with Kanban, bạn có thể tham khảo tại đây: Scrum with Kanban
​
Những kiến thức trong loạt bài này tập trung chủ yếu để giúp Scrum team có thể áp dụng Kanban và mang lại giá trị tương hỗ lớn nhất cho nhau (Scrum with Kanban). Qua đó đội có thể được hưởng lợi bằng việc tăng được giá trị cho sản phẩm.
​