Bài 50 — Lean Thinking for SM — Advanced Scrum Master PSM II

Mở đầu — vì sao bài này quan trọng

Nếu bạn mở Scrum Guide phiên bản 2020 và đọc thật kỹ phần đầu, bạn sẽ thấy một thay đổi nhỏ về câu chữ nhưng rất lớn về ý nghĩa. Ken Schwaber và Jeff Sutherland viết: "Scrum is founded on empiricism and lean thinking." — Scrum được xây dựng trên nền tảng thực nghiệm và tư duy tinh gọn (lean thinking). Ở các phiên bản trước, lean thinking không được nhắc đến một cách tường minh như vậy. Việc đưa lean lên ngang hàng với empiricism là một thông điệp rõ ràng: một Scrum Master ở trình độ PSM II không thể chỉ thuộc lòng ba trụ cột Transparency – Inspection – Adaptation, mà còn phải hiểu cội nguồn tư duy tinh gọn đứng phía sau toàn bộ cách Scrum vận hành.

Vấn đề là phần lớn Scrum Master ở Việt Nam học Scrum như một bộ "luật chơi": có bao nhiêu sự kiện, ai làm gì, kéo dài bao lâu. Họ áp dụng đúng nghi thức nhưng không hiểu tại sao Sprint lại ngắn, tại sao phải giới hạn công việc dở dang, tại sao phải loại bỏ những cuộc họp vô nghĩa. Câu trả lời cho tất cả những câu "tại sao" đó nằm ở lean thinking. Khi bạn nắm được lean, bạn không còn là người "canh giờ họp" mà trở thành người nhìn ra lãng phí trong cả dòng chảy công việc — và đó chính là khác biệt giữa một SM bình thường và một SM giúp tổ chức thực sự tăng trưởng. Bài này sẽ trang bị cho bạn lăng kính đó.

Khái niệm cốt lõi

Lean đến từ đâu?

Tư duy tinh gọn bắt nguồn từ Toyota Production System (TPS) — hệ thống sản xuất mà Toyota phát triển sau Thế chiến II, khi nước Nhật khan hiếm tài nguyên đến mức không cho phép lãng phí dù chỉ một chút. Taiichi Ohno, "cha đẻ" của TPS, đã đúc kết một nguyên lý nền tảng: tối ưu hóa toàn bộ dòng chảy giá trị (value stream), liên tục loại bỏ lãng phí (waste), và tôn trọng con người. Sau này James Womack và Daniel Jones hệ thống hóa thành "Lean Thinking" với năm nguyên tắc, và Mary & Tom Poppendieck đưa lean vào thế giới phần mềm với cuốn Lean Software Development.

Điều cốt lõi bạn cần khắc cốt ghi tâm: lean không phải là làm nhanh hơn, mà là loại bỏ những thứ không tạo giá trị để giá trị thật có thể chảy nhanh hơn. Đây là khác biệt tinh tế nhưng quyết định.

Hai trụ cột của lean

Toyota mô tả lean dựa trên hai trụ cột:

Continuous Improvement (Kaizen) — cải tiến liên tục, từng bước nhỏ, không ngừng nghỉ. Đây chính là tinh thần của Sprint Retrospective trong Scrum.
Respect for People — tôn trọng con người, tin rằng người trực tiếp làm việc là người hiểu vấn đề rõ nhất và có khả năng tự cải tiến. Đây là gốc rễ của khái niệm self-managing team.

Khi nhìn ở góc này, bạn sẽ thấy Scrum thực ra là một hiện thân của lean: empiricism là cách bạn ra quyết định dựa trên thực tế quan sát được, còn lean là triết lý về cái gì đáng làm và cái gì nên loại bỏ.

Bảy loại lãng phí (7 Wastes) — phiên bản phát triển phần mềm

Đây là phần trung tâm của bài. Trong sản xuất, Ohno liệt kê bảy loại muda (lãng phí). Mary Poppendieck đã "dịch" bảy loại này sang ngôn ngữ phát triển phần mềm. Là một Scrum Master, bạn cần thuộc và quan trọng hơn là nhìn thấy chúng trong đội của mình:

Partially Done Work (Công việc làm dở dang) — code đã viết nhưng chưa test, tính năng chưa tích hợp, tài liệu chưa duyệt. Nó nằm chình ình ở đó, ngốn vốn nhưng chưa tạo ra giá trị, và có nguy cơ trở nên lỗi thời. Đây là lý do Scrum nhấn mạnh "Done" và Increment có thể release được.

Extra Features (Tính năng thừa) — xây những thứ không ai dùng. Nghiên cứu của Standish Group cho thấy khoảng 64% tính năng trong phần mềm hiếm khi hoặc không bao giờ được dùng. Mỗi dòng code thừa là một gánh nặng bảo trì vĩnh viễn.

Relearning (Học lại) — phải tìm hiểu lại thứ mình từng biết, vì kiến thức không được lưu giữ, vì người cũ rời đi, vì không có tài liệu.

Handoffs (Chuyển giao) — mỗi lần công việc chuyển từ người này sang người khác (BA → Dev → Tester → Ops), một phần kiến thức ngầm bị mất. Càng nhiều handoff, càng nhiều lãng phí. Đây là lý do cross-functional team tồn tại.

Task Switching (Chuyển đổi công việc) — một người ôm ba dự án cùng lúc sẽ mất rất nhiều thời gian "khởi động lại não" mỗi lần chuyển. Đa nhiệm là kẻ thù của năng suất.

Delays (Chờ đợi) — chờ phê duyệt, chờ môi trường test, chờ quyết định từ cấp trên. Thời gian chờ thường chiếm phần lớn lead time mà không ai nhận ra.

Defects (Lỗi) — lỗi phát hiện càng muộn càng đắt. Lean dạy: xây chất lượng vào ngay từ đầu (build quality in) thay vì kiểm tra chất lượng ở cuối.

Năm nguyên tắc lean của Womack & Jones

Bên cạnh 7 wastes, có một khung tư duy bạn nên áp dụng khi nhìn vào tổ chức:

Value — xác định giá trị từ góc nhìn khách hàng cuối, không phải từ góc nhìn nội bộ.
Value Stream — vẽ ra toàn bộ chuỗi các bước từ ý tưởng đến khi đến tay khách hàng, để nhìn rõ đâu là lãng phí.
Flow — làm cho giá trị chảy liên tục, không bị tắc nghẽn.
Pull — sản xuất theo nhu cầu thực, không đẩy hàng tồn (đây là gốc của Sprint Backlog do team kéo việc về, và của Kanban).
Perfection — theo đuổi sự hoàn hảo qua kaizen liên tục.

Tình huống thực tế

Tình huống 1: Công ty fintech ở TP.HCM và núi "công việc dở dang"

Một công ty fintech tầm trung ở Quận 1, TP.HCM (khoảng 80 kỹ sư) gặp tình trạng quen thuộc: cuối mỗi Sprint hai tuần, demo trông rất ấn tượng — nhiều màn hình mới, nhiều luồng mới. Nhưng khi đến lúc release lên production thì chậm trễ liên miên, mỗi quý chỉ ra mắt được một lần và lần nào cũng đầy bug.

SM mới về quyết định vẽ một value stream map đơn giản trên bảng trắng. Kết quả gây sốc cho cả đội: ở bất kỳ thời điểm nào, họ có trung bình 23 tính năng "code xong nhưng chưa release". Đó chính là Partially Done Work — loại lãng phí số 1. Code viết tháng Một, đến tháng Tư mới release, lúc đó yêu cầu đã đổi, phải sửa lại. Đó là Relearning và Defects chồng lên nhau.

SM không hô hào "hãy làm việc chăm hơn". Anh ấy đặt một câu hỏi lean kinh điển: "Điều gì ngăn một tính năng đi từ 'code xong' đến 'khách hàng dùng được' ngay trong Sprint?" Hóa ra là quy trình phê duyệt release phải qua ba cấp ký tay (Delays và Handoffs). Đội đàm phán với compliance để chuyển sang phê duyệt theo lô nhỏ tự động hóa. Sau ba tháng, lượng công việc dở dang giảm từ 23 xuống còn 4, và tần suất release tăng từ mỗi quý lên mỗi hai tuần.

Bài học: Lãng phí lớn nhất thường vô hình vì nó "nằm giữa" các bước. SM giỏi không tối ưu từng người làm nhanh hơn, mà làm cho cả dòng chảy thông suốt.

Tình huống 2: Startup thương mại điện tử và cái bẫy "tính năng thừa"

Một startup e-commerce ở Hà Nội, gọi vốn được vòng seed, đội sản phẩm 12 người. PO rất nhiệt tình, mỗi Sprint backlog luôn dày đặc tính năng mới: wishlist, so sánh sản phẩm, chat tư vấn, gamification điểm thưởng, blog tích hợp... Đội chạy rất chăm, velocity cao, nhưng sau sáu tháng, tỷ lệ chuyển đổi (conversion rate) gần như không nhúc nhích.

SM ngồi lại cùng PO và mở Google Analytics. Họ phát hiện tính năng "so sánh sản phẩm" mà đội mất ba Sprint để xây chỉ được 1,8% người dùng chạm vào; gamification điểm thưởng còn thấp hơn. Đây chính xác là Extra Features — lãng phí số 2 trong danh sách của Poppendieck. Đội đã đổ hàng trăm giờ công vào thứ không ai cần, trong khi luồng thanh toán — nơi 60% khách bỏ giỏ hàng — thì chưa ai đụng tới.

SM dùng tư duy lean để định hình lại cách làm việc: thay vì hỏi "Sprint này làm được bao nhiêu tính năng?", đội chuyển sang hỏi "Tính năng nào sẽ tạo giá trị đo lường được cho khách hàng?". Họ áp dụng nguyên tắc Value và Pull — chỉ kéo việc khi có giả thuyết giá trị rõ ràng. Trong quý tiếp theo, đội tập trung tối ưu luồng thanh toán, conversion tăng từ 1,2% lên 2,1% — gần gấp đôi — dù velocity "trên giấy" giảm.

Bài học: Bận rộn không phải là tạo giá trị. Một SM hiểu lean sẽ giúp đội phân biệt giữa "output" (số lượng làm ra) và "outcome" (giá trị thật), và can đảm dừng làm những thứ thừa.

Tình huống 3: Đội outsourcing và bẫy đa nhiệm

Một công ty gia công phần mềm ở Đà Nẵng có một kỹ sư senior giỏi tên Tuấn, bị phân vào ba dự án cùng lúc vì "anh ấy quá giỏi để chỉ làm một việc". Quản lý nghĩ đang tận dụng tối đa nguồn lực. Thực tế ngược lại.

SM theo dõi và nhận ra Tuấn mất trung bình 20–30 phút mỗi lần chuyển ngữ cảnh giữa các dự án để nhớ lại mình đang làm gì — và một ngày anh chuyển qua lại cả chục lần. Đó là Task Switching, lãng phí số 5. Nghiên cứu của Gerald Weinberg ước tính mỗi dự án thêm vào làm mất khoảng 20% thời gian hữu ích vì context switching; với ba dự án, có thể mất tới 40% năng suất. Tệ hơn, Tuấn trở thành nút thắt cổ chai cho cả ba đội — ai cũng phải chờ (Delays) anh.

SM trình bày dữ liệu này cho ban quản lý, không bằng cảm tính mà bằng con số lean. Họ quyết định cho Tuấn tập trung vào một dự án trong mỗi giai đoạn. Kết quả: cả ba dự án đều hoàn thành nhanh hơn so với khi Tuấn "chia ba", vì dòng chảy không còn bị chặn.

Bài học: "Tận dụng tối đa từng người" (resource utilization) là tư duy chống lại lean. Lean tối ưu dòng chảy của công việc, không phải mức bận của con người.

Hướng dẫn từng bước

Đây là cách bạn áp dụng lean thinking như một SM trong công việc hằng ngày:

Học cách "nhìn thấy" lãng phí. Mỗi tuần, dành thời gian quan sát đội qua lăng kính 7 wastes. Tự hỏi: việc nào đang nằm dở dang? Có ai bị chia nhiều dự án? Công việc chờ ở khâu nào lâu nhất?

Vẽ Value Stream Map. Cùng đội vẽ toàn bộ các bước từ "ý tưởng" đến "khách hàng dùng được". Với mỗi bước, ghi hai con số: thời gian thực sự làm việc (process time) và thời gian chờ (wait time). Bạn sẽ thường sốc khi thấy wait time chiếm 80–90% tổng lead time.

Đo lường flow, không chỉ đo velocity. Bắt đầu theo dõi các chỉ số dòng chảy như Cycle Time (một item mất bao lâu từ khi bắt đầu đến khi Done) và Work In Progress (WIP). Velocity cho biết bạn làm bao nhiêu; flow metrics cho biết bạn làm trơn tru đến đâu.

Giới hạn công việc dở dang (Limit WIP). Đây là can thiệp lean mạnh nhất và dễ áp dụng nhất. Khi đội ngừng bắt đầu việc mới và tập trung hoàn thành việc đang dở, lead time giảm rõ rệt. Stop starting, start finishing.

Biến Retrospective thành cỗ máy Kaizen. Đừng để Retro thành buổi than phiền. Mỗi Retro, chọn một lãng phí cụ thể trong 7 wastes và một hành động nhỏ để giảm nó. Cải tiến từng bước nhỏ nhưng đều đặn — đó chính là kaizen.

Đưa "Respect for People" vào thực hành. Khi có vấn đề, đừng đi tìm "ai sai" mà tìm "quy trình nào khiến lỗi này xảy ra". Lean tin lỗi đến từ hệ thống, không từ con người.

Lỗi thường gặp & mẹo

Hiểu nhầm lean là cắt giảm chi phí / sa thải nhân sự. Đây là sai lầm phổ biến và nguy hiểm nhất ở Việt Nam, do dịch "tinh gọn" thành "thắt lưng buộc bụng". Lean là loại bỏ lãng phí trong quy trình, không phải cắt người. Sa thải người làm việc trong khi giữ nguyên quy trình lãng phí là phản-lean.

Tối ưu cục bộ thay vì toàn cục. Nhiều SM ép một khâu chạy nhanh hơn mà không nhìn cả dòng chảy, khiến công việc dồn ứ ở khâu sau. Mẹo: luôn hỏi "việc này có làm cả dòng chảy nhanh hơn không, hay chỉ làm một người bận hơn?".

Lẫn lộn busy với productive. Đội nhìn ai cũng tất bật nhưng giá trị đến tay khách hàng vẫn chậm. Mẹo: treo Cycle Time và WIP lên bảng, để cả đội thấy dòng chảy chứ không chỉ thấy độ bận.

Áp 7 wastes như một bài kiểm tra học thuộc. Đừng bắt đội học vẹt bảy loại lãng phí. Hãy dùng chúng như công cụ quan sát trong ngữ cảnh thật, gắn với ví dụ cụ thể của chính đội.

Mẹo vàng — bắt đầu từ "Delays". Trong hầu hết tổ chức Việt Nam, lãng phí lớn nhất là thời gian chờ phê duyệt và chờ quyết định. Nếu chưa biết bắt đầu từ đâu, hãy đo wait time. Đó thường là "mỏ vàng" cải tiến đầu tiên.

Bài tập thực hành

Săn lãng phí (Waste Walk). Trong tuần tới, mỗi ngày ghi lại ít nhất một ví dụ về lãng phí bạn quan sát được trong đội, gắn nhãn nó thuộc loại nào trong 7 wastes. Cuối tuần, đếm xem loại nào xuất hiện nhiều nhất.

Vẽ Value Stream Map mini. Chọn một User Story gần nhất đã hoàn thành. Vẽ lại hành trình của nó qua từng khâu, ghi process time và wait time mỗi khâu. Tính tỷ lệ: thời gian làm việc thực / tổng lead time. Con số đó nói lên điều gì?

Thí nghiệm Limit WIP. Đề xuất với đội một giới hạn WIP cho cột "In Progress" trong Sprint tới (ví dụ tối đa bằng số người chia 2). Sau một Sprint, so sánh cảm nhận và Cycle Time trước/sau.

Liên kết với Scrum Guide. Viết một đoạn ngắn (khoảng 150 từ) giải thích vì sao mỗi sự kiện Scrum (Sprint, Daily, Review, Retro) thực ra là một cơ chế lean để giảm một loại lãng phí cụ thể.

Tóm tắt

Scrum Guide 2020 tuyên bố rõ ràng rằng Scrum đứng trên hai chân: empiricism và lean thinking. Là một Scrum Master ở trình độ PSM II, hiểu lean không phải là kiến thức "thêm vào cho oai" mà là lăng kính giúp bạn lý giải tại sao Scrum được thiết kế như vậy. Lean bắt nguồn từ Toyota Production System với hai trụ cột là Continuous Improvement (Kaizen) và Respect for People, và cốt lõi là loại bỏ lãng phí để giá trị thật chảy nhanh hơn — chứ không phải bắt người làm nhanh hơn.

Bảy loại lãng phí trong phần mềm — công việc dở dang, tính năng thừa, học lại, chuyển giao, chuyển đổi công việc, chờ đợi, và lỗi — là bộ công cụ quan sát cốt lõi của bạn. Năm nguyên tắc Value – Value Stream – Flow – Pull – Perfection cho bạn khung tư duy ở cấp tổ chức. Qua ba tình huống thực tế từ fintech, e-commerce đến outsourcing, bạn đã thấy lean không phải lý thuyết khô khan mà là cách nhìn giúp giải quyết những vấn đề rất đời thường: release chậm, tính năng vô dụng, con người bị xé lẻ. Hãy bắt đầu nhỏ: học cách nhìn thấy lãng phí, đo dòng chảy thay vì chỉ đo độ bận, giới hạn WIP, và biến mỗi Retrospective thành một bước kaizen. Khi bạn tư duy theo lean, bạn không còn chỉ là người canh giờ họp — bạn trở thành người giúp cả tổ chức chảy nhanh hơn về phía giá trị.