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

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

    Tìm hiểu thêmBảng Kanban là gì? Ứng dụng Kanban trong CRM, ERP và Quản trị công việc
     
  • Cycle Time: Là khoảng 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ảng 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 Law

​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. Vậy 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", 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.

Tại sao việc hạn chế WIP lại quan trọng như vậy? Lý do là việc giảm WIP (Work In Progress - công việc đang triển khai) thực sự làm tăng năng suất của nhóm - nó tăng tốc độ hoàn thành công việc. Định luật Little's Law chứng minh rằng thời gian của một hàng đợi (mất bao lâu để hoàn thành các công việc) tỷ lệ thuận với kích thước của nó (bao nhiêu công việc đang được thực hiện).

Hãy xem thêm một ví dụ khác:

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.

Throughput, WIP

Đ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ó gì đặc biệt hay phép màu nào về cải thiện năng suất của nhóm 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. Sẽ không có gì ngạc nhiên về giả thuyết này. Trong thực tế 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. Muốn đạt được điều đó bạn sẽ phải thay đổi / cải tiến thông số Throughput,  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 PO 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à Development Team, đã 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.

Tham khảo: Scrumviet