Làm thế nào để tối ưu hoá dòng chảy giá trị của sản phẩm?

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à Developer 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.

4 Kanban Practices - Scrum with Kanban

Tại sao dòng chảy giá trị công việc lại quan trọng?

Nói đơn giản rằng, việc xác định  ý tưởng hay, khách hàng đang cần, và việc tối ưu hoá thời gian để đưa sản phẩm, hay ý tưởng của bạn ra thị trường càng sớm càng tốt là chìa khóa để thành công. Tương tác với khách hàng của bạn càng sớm thì bạn sẽ hiểu họ và mang lại đúng giá trị họ cần hơn. Đây chính là lý do.

Nhưng tối ưu hoá nó thế nào?

Lý do Scrum không đề cập đến làm thế nào Scrum Team có thể tối ưu hoá dòng chảy giá trị, hay Developer quản lý Sprint backlog và deliver công việc qua từng Sprint làm sao là vì, mỗi team sẽ có một cách làm việc khác nhau, những nhu cầu và sản phẩm khác nhau. Nên Scrum linh hoạt với việc đó và chỉ đề cập rằng dù bằng cách nào thì trách nhiệm quản lý và tối ưu công việc của Sprint là thuộc về Developer, và Scrum Team phải được tự quản để tối ưu hoá dòng chảy giá trị của sản phẩm..

Chính tôi nhiều năm trước từng đặt câu hỏi rằng, vậy có "good practice" nào giúp Scrum Team tối ưu công giá trị sản phẩm không? Hay một "framework" nào giúp Developer tự quản lý và tối ưu công việc của mình trong Sprint không? Và tôi tìm thấy câu trả lời ở Kanban.
​
Phá đi mọi nghi ngờ về việc Kanban chỉ dành cho việc “X” thôi, Scrum dành cho việc “Y”, và cả hai không thể áp dụng cùng nhau cho cùng một team. Sự thật rằng Kanban và Scrum là hai mảnh ghép rất tốt, Kanban practices có thể bổ trợ và giúp cho Scrum team đo lường và cải thiện dòng chảy giá trị.

Nhưng việc áp dụng này cần có được sự hiểu biết rõ, và Scrum Master phải hỗ trợ Developer, Product Owner làm thế nào để áp dụng tốt nhất. Nếu không, chẳng những không mang lại giá trị nào mà còn làm cho mọi thứ trở nên tệ hơn.

Một trong những kinh nghiệm và tôi quan sát được rằng, việc không hiểu rõ những giá trị từ Scrum và Kanban dẫn đến nhiều sai lầm khi áp dụng. Lấy ví dụ: Một trong số đó là việc cho rằng chỉ cần Limit WIP (Limiting Work in Progress) là sẽ tối ưu hoá được công việc của Developer. Dẫn đến việc chỉ quan tâm đến việc giới hạn về số lượng công việc được làm cùng lúc (Limit WIP) mà không chú ý đến những điều khác, như mức độ tin tưởng của các thành viên hay những Kanban Practices khác cũng nên được sử dụng để tương hỗ với LWIP.

Có 4 Kanban Practices mà Scrum team nên chú ý và áp dụng khi muốn áp dụng Scrum và Kanban cùng nhau. Và bạn sẽ nhận thấy rằng, LWIP không nên được đề ra và áp dụng một cách khô cứng, mà nó phải được kiểm tra và thay đổi liên tục cho phù hợp với công việc và khả năng của nhóm thời điểm hiện tại nữa.

Tương tự như DoD trong Scrum, chỉ tạo ra LWIP và áp dụng nó một cách máy móc, sẽ không giúp bạn tối ưu hóa dòng chảy giá trị, mà nó sẽ tạo ra nợ dòng chảy (flow debt), hay tắt ngẽn.

1. Visualization of the workflow
2. Limiting Work in Progress (WIP)
3. Active management of work items in progress
4. Inspecting and adapting the team’s definition of “Workflow”

Bạn có thể đọc thêm bài viết chuyên sâu về 4 Kanban Practices tại đây.

Tôi cũng xin nhấn mạnh rằng việc áp dụng Kanban vào Scrum không làm thay đổi bản chất của Scrum, Scrum vẫn là Scrum. Trong đó, trách nhiệm tối ưu hoá giá trị sản phẩm thuộc về Scrum team và trong Sprint việc quản lý Sprint Backlog là trách nhiệm của Developer, chứ không phải là của ai khác. Vì vậy, việc làm thế nào để tối ưu hóa công việc phát triển sản phẩm trong Sprint bằng việc áp dụng Kanban cũng nên là do Developer quyết định làm thế nào. Scrum Master có trách nhiệm giúp đỡ và chia sẻ nhưng công cụ và phương pháp phù hợp. Nhưng cuối cùng vẫn là Developer xem xét và quyết định điều gì là tốt nhất cho họ.
​
Bạn có thể đọc thêm để nâng cao kiến thức làm sao Scrum Master có thể giúp Scrum team hiểu được điều gì là tốt nhất, và team tự ra quyết định mà không ảnh hưởng đến Self-Organize của team.

Scrum on!

NOTE: Scrum guide 2020, đã được phát hành, trong phiên bản này có nhiều thay đổi, trong số đó là Development team bây giờ sẽ là Developer, bài biết trên đã được thay đổi và update ngày 18 tháng 11 năm 2020 để phù hợp với Scrum guide mới.