Tổng quan về Lean, Agile, Scrum

I. Thuật ngữ: Lean, Agile, Scrum, Sprint, Kanban

• Lean và Agile có nhiều điểm giống nhau, chúng đều là cách tiếp cận cơ bản để làm việc với những project có nhiều điểm chưa chắc chắn, đó là lý do mà nhiều startup chọn cách cách tiếp cận này.
• Scrum và Kanban là 2 framwork quản lý dự án Agile phổ biến nhất. Scrum được dùng nhiều hơn, nhưng thực tế mọi người thường chỉnh sửa để tạo phiên bản Scrum riêng biệt, và vì thế thường bao gồm cả những thành phần của Kanban.
• Sprint là thuật ngữ của Scrum, là một vòng đời trong Scrum.
• Lean ≈ Agile > Scrum > Sprint

II. Tại sao Lean và Agile?

Bởi vì với việc thay đổi nhanh chóng của thông tin, chúng ta cần một cách tốt hơn để tổ chức và quản lý.

Lean & Agile là thuốc giải cho 2 nguyên nhân chính gây rối loạn chức năng trong các tổ chức hiện đại:

• Quản lý dự án theo mô hình thác nước, và
• Phân cấp hướng chức năng

Waterfall vs Agile

Khi nói về quản lý dự án, hầu hết chúng ta đều tưởng tượng ra một phương pháp kỷ luật, tiếp cận từng bước một với kế hoạch và mục tiêu rõ ràng. Đây thực chất là quản lý dự án theo mô hình thác nước.

Tư duy quản lý dự án kiểu thác nước đã ăn sâu vào văn hóa của chúng ta. Nền giáo dục cũng nhấn mạnh vào việc chuẩn bị kỹ càng và thận trọng. Tiến độ đáp ứng với check-point. Biết rằng đang đi đúng hướng mang lại sự thoải mái và tự tin, đồng thời giúp giáo viên và ban giám hiệu giám sát và quản lý dễ dàng hơn. Đó là một cách tiếp cận tốt. Nhiều tuyệt tác ở thế giới hiện đại sẽ chẳng thể tồn tại mà không có thác nước. Nhiều doanh nghiệp toàn cầu đã mở rộng thành công với mô hình thác nước. Nhưng nó cũng có mặt hạn chế: nó chỉ hoạt động tốt trong các dự án có tính chất lặp đi lặp lại và độ chắc chắn tương đối cao.

Thực tế là thế giới hiện đại đầy những điều bất trắc. Hành vi con người rất khó để dự đoán. Và trong một dự án bạn phát triển sản phẩm nhưng lại chưa tìm thấy thị trường, quản lý theo mô hình thác nước sẽ rất tốn kém. Số cơ hội bạn có thể đập đi xây lại sản phẩm rất hãn hữu, và thời gian cần thiết để xây dựng lại sản phẩm khác sẽ giảm khả năng cạnh tranh của sản phẩm.

Agile nổi lên như một giải pháp cho những thiếu sót của mô hình thác nước. Doanh nghiệp sẽ có một cách tiếp cận nhanh hơn, hiệu quả hơn về chi phí và ít rủi ro hơn để đối phó với những bất trắc khó lường trong hoạt động kinh doanh. Và với xu thế chuyển đổi kỹ thuật số nhanh như hiện tại, không chỉ các startup mà tất cả các doanh nghiệp ở mọi quy mô đều phải tìm cách đối phó với sự thay đổi. Và Agile chính là một giải pháp.

Tổ chức kiểu truyền thống vs Agile

Ủy thác công việc là một thách thức hàng ngày cho lãnh đạo và quản lý. Văn hóa bàn giao giữa các team tạo ra những trở ngại chống lại việc theo đuổi các mục tiêu cao cấp hơn của doanh nghiệp. Agile về cơ bản sẽ giải quyết những thách thức này với mô hình được xác định lại về tinh thần đồng đội và lãnh đạo.

Trong tổ chức truyền thống, đội ngũ lãnh đạo và quản lý chịu trách nhiệm ra quyết định, về chiến lược và giải quyết vấn đề, các câu trả lời dự kiến đến từ họ. Điều này gây ra rủi ro và yêu cầu phải đưa ra những quyết định đúng đắn. Tuy nhiên, một lần nữa với thời đại phát triển chóng mặt về kỹ thuật số và xã hội, rất hiếm khi có một người hội đủ yếu tố đó. Nhận định rằng giải quyết vấn đề là một quá trình, Agile khuyến khích xây dựng và thử nghiệm như một bài tập của tất cả cá nhân trong tổ chức. Nói đơn giản, nhiều cặp mắt và trí tuệ làm tăng khả năng giải quyết vấn đề nhanh chóng.

Tinh thần Lean & Agile

Lean và Agile là cách tiếp cận, không phải phương pháp. Thậm chí Scrum, framwork triển khai của Agile, cũng từ chối được gọi là phương pháp. Đó là vì không có một phương pháp cứng nhắc nào có tác dụng với những bất ngờ. Thay vào đó, bạn tuân theo một số nguyên tắc chúng nhất định, hay còn gọi là tinh thần của Lean & Agile, như sau:

• Không ngừng theo đuổi sản phẩm phù hợp với thị trường
• Build-mesuare-learn: chấp nhận bất ngờ - đó là lý do tại sao chúng ta đưa ra giả thueyets, test và validate để xem liệu ta đã đến gần thứ khách hàng mong muốn hay chưa. Cho đến khi mọi việc chắc chắn thì hãy thực hiện từng bước nhỏ và tiếp tục lặp lại vòng lặp đó.
• Tất cả mọi người đều phải hiểu khách hàng, không chỉ riêng bộ phận bán hàng, tiếp thị hay là đội ngũ quản lý. Vì vậy, bạn được phép cũng như khuyến khích thử nghiệm build-mesuare-learn với khách hàng, ngay cả khi không trực tiếp làm việc, và đội ngũ lãnh đạo sẽ tạo vạch ra một framwork để hợp tác một cách có hệ thống.
• Với Lean & Agile, không ai bị khiển trách. Nếu có lỗi xảy ra thì cũng không tìm người để đổ lỗi, thay vì đó chúng ta sẽ kiểm tra hệ thống đã tạo ra sự cố và khắc phục.

III. Triển khai Scrum

Tầm nhìn

Trước tiên, tầm nhìn của doanh nghiệp cần được chia sẻ với mọi thành viên trong tổ chức bằng một cách có tính kết nối: mọi việc ở mọi cấp độ cá nhân, cần được kết nối với tầm nhìn.

Điều này khó hơn ta tưởng. Lãnh đạo có thể nói và trình bày về tầm nhìn, nhưng điều đó không nhất thiết buộc tất cả phải tham gia vào. Việc chia sẻ thực tế là bài tập để cấu thành tầm nhìn cho mỗi người.

Epic, Story, Task là những thuật ngữ của Scrum mà giúp mọi người nắm được những điều quan trọng trong sản phẩm hoặc dự án cần được xây dựng hoặc hoàn thành để hiện thực hóa tầm nhìn chung. Theo thiết kế, Scrum đặt mọi người trên cùng trang giấy bằng cách tạo những "backlog" dựa trên cây phân cấp tầm nhìn.

Chạy Sprints

Scrum là một framework quản lý dự án theo kiểu giới hạn thời gian bằng những Sprint, mỗi sprint sẽ có một chu kỳ làm việc cố định, thường từ một đến bốn tuần, tùy theo tính chất công việc.

Ý tưởng của sprint chính là chia nhỏ công việc và tăng tốc vòng lặp, trọng tâm là giúp cả team hướng về mục tiêu. Xây dựng giả thuyết và lặp lại việc kiểm thử chính là một phần không thể thiếu của Scrum, vì hầu hết các dự án đều có những điều chưa chắc chắn, và khám phá tìm tòi chính là chìa khóa.

1. Backlog

Tưởng tưởng tất cả những thứ có thể có trong sản phẩm hoặc nhu cầu cần đáp ứng trong dự án. User Story chính là cách tốt nhất để ngữ cảnh hóa nhu cầu và mong muốn của khách hàng.

User Story: As a [user], I want [what], so that [value].

2. Sprint Planning

Phân chia độ ưu tiên và estimate Backlog, quyết định điều gì cần làm trong Sprint tiếp theo.

• Ước tính thời gian để hoàn thành task
• Bảng Scrum cũng là công cụ chính trong Scrum. Đây là nơi thông tin hiển thị trực quan, được chia sẻ với cả team. Việc tùy chỉnh luôn được khuyến khích để phù hợp với quy trình làm việc nhóm.
• Done là một điều cần tuân thủ trong Scrum. Nó không chỉ là một khái niệm đảm bảo chất lượng, nó còn là tiêu chí đo lường cho những giả thuyết và thử nghiệm trong Sprint.
• Có 2 nhân tố lãnh đạo trong Scrum. Một là Product Owner, hai là Scrum Master. Yếu tốt đo lường năng suất của team là tốc độ, tức là tốc độ hoàn thành task, thu thập và ra quyết định.

3. Daily Stand Up

Một nhóm Scrum thường từ 3 đến 9 người, bao gồm cả Product Owner và Scrum Master. Nếu nhiều hơn thì tốc độ của team sẽ giảm suống, nên tốt hơn hết là nên chia thành nhiều team.

Chìa khóa cho tốc độ chính là việc giao tiếp giữa các thành viên về tiến độ và trở ngại. Một format daily stand up được chứng minh là có tính hiệu quả cao: mỗi ngày vào một khung giờ cố định, cả team tập hợp lại và mỗi member sẽ chia sẻ về tiến độ của họ theo 3 câu hỏi:

✓ Hôm qua làm được gì?

✓ Hôm nay định làm gì?

✓ Làm như thế nào?

4. Đánh giá Sprint

Cuối mỗi Sprint, team sẽ có 2 cuộc họp.

Cuộc họp thứ nhất là "what": đánh giá xem đã làm được gì trong sprint vừa rồi, bao gồm cả demo sản phẩm

Cuộc họp thứ hai là "how": bao gồm việc member thảo luận khó khăn, vướng mắc gặp phải, hoặc giả nếu mọi chuyện đang đi đúng hướng, thì có đề xuất cải thiện.

Cuối mỗi cuộc họp thì update vào Backlog và lên kế hoạch cho Sprint tiếp theo.

IV. Cạm bẫy thường gặp về Scrum

‣ Thiếu tinh thần Scrum: Sprints as Mini-Waterfalls

User Stories trở thành những tài liệu đặc tả mini. Với bản đặc tả này thì code xong, rồi UAT ... Thoạt nhìn thì có vẻ ổn, nhưng lại rất nhiều team rơi vào cái bẫy này.

Vấn đề là đây không khác gì một dự án mini của mô hình thác nước. Phân tích, thiết kế, code và test được làm tuần tự.

Lean & Agile là tinh thần khám phá những điều chưa chắc chắn. Trong Scrum, vòng lặp build-measure-learn được thiết kế để xảy ra trong Sprint, và các thành viên làm việc dựa trên giả thuyết, xây dựng và thử nghiệm MVP (minimum viable product). Công việc sẽ không được làm theo kiểu tuần tự, nếu có gì đó không ổn thì việc chỉnh sửa thiết kế hoặc đề ra một cách tiếp cận khác.

‣ Scrum cục bộ

Agile hiện là một phần phổ biến trong các nhóm phát triển phần mềm. Vấn đề là, trong nhiều tổ chức, nó chỉ là nhóm phát triển (development team) đang chạy Scrum, tạo ra một hòn đảo trong tổ chức một cách hiệu quả.

Kết quả là một văn hóa bắt tay giữa nhóm phát triển và phần còn lại của tổ chức, chẳng hạn với đội sale: bọn tao tạo sản phẩm như spec rồi đấy, giờ tìm người mua đi.

Chìa khóa để tuyên truyền Agile là cho phép mọi người nhận thức về Agile như một khái niệm rộng hơn về giao tiếp, hợp tác và đồng sáng tạo, chứ không chỉ là một framework quản lý dự án đơn thuần. Đặt câu hỏi, nếu chúng ta có thể kết nối nội bộ đủ tốt, làm thế nào chúng ta có thể kết nối với khách hàng? Điều này sẽ tạo ra sự giá trị khách hàng bền vững và tư duy phù hợp với thị trường sản phẩm giữa các đội.

Về mặt triển khai thực tế của Agile trên toàn tổ chức, Scrum về bán hàng và tiếp thị có thể được điều hành song song với đội phát triển Scrum. Cuối cùng, tốt nhất là hướng đến việc chuyển sang các nhóm Scrum đa chức năng, nơi đội phát triển, bán hàng và tiếp thị đều nằm trong mỗi nhóm Scrum, được liên kết bởi các sản phẩm hoặc dự án khách hàng.

‣ Scrum Master trong việc điều hành

Trong Daily Stand Up, nếu mọi người đang cập nhật tiến độ cho Scrum Master và Scrum Master nói cho mọi người biết phải làm gì, thì bạn đã hủy hoại mục đích của Scrum.

Scrum là một nỗ lực có hệ thống để đưa các tổ chức ra khỏi chế độ manager-worker. Các mô hình lãnh đạo chỉ huy thất bại trong giải quyết vấn đề - nó dựa vào các nhà lãnh đạo để có tất cả các câu trả lời, làm cho chính các nhà lãnh đạo trở thành trở ngại.

Trong một tổ chức Agile, bạn cố gắng đưa ra tất cả - từ sự hợp tác, cộng tác, phối hợp, đồng sáng tạo, giao tiếp, kết nối, v.v. Vai trò của Scrum Master kèm theo là giữ cho dòng chảy.

Chúng ta cũng phải hiểu được sự thoải mái thụ động của người lao động ở chế độ manager-worker: nhận chỉ thị công việc rất thoải mái vì bạn không phải nghĩ về lý do và cách thức, bạn không phải chịu trách nhiệm trong việc ra quyết định. Scrum giải quyết nỗi đau của việc chuyển đổi sang chế độ làm việc tự chủ theo nhiều cách; Cách tiếp cận chia nhỏ giúp công việc dễ quản lý hơn, Daily Stand Up có nghĩa là để các thành viên trong nhóm giúp đỡ lẫn nhau khi họ gặp vấn đề và văn hóa không đổ lỗi khuyến khích các cá nhân chấp nhận rủi ro thử nghiệm.

‣ Sprint Till You Drop

Nếu một nhà lãnh đạo nghĩ sprint là một phương tiện có hệ thống để khiến mọi người làm việc hết sức lực ở mức tập trung cao độ, thì đó chỉ đơn giản là một cách quản lý theo thói quen do khủng hoảng, hoặc tệ hơn là bóc lột sức lao động.

Một nhà lãnh đạo ít độc tài hơn có thể xem sprint như một điều gì đó giống với việc theo dõi. Anh ta có thể lập luận, bằng cách trải qua một chu kỳ làm việc căng thẳng liên tục, team sẽ có thể chạm đến ranh giới về hiệu suất. Nhưng điều này có nguy cơ khiến thành viên trong team kiệt sức tinh thần. Thật khó để thu hút và giữ chân nhân tài để làm việc trong môi trường căng thẳng cao như vậy.

Sau một Sprint, Sprint tiếp theo bắt đầu ngay lập tức. Nếu team bắt đầu Sprint mới bằng cách cố gắng phục hồi từ sprint trước đó, rõ ràng họ đang quá tải. Sprint phải được thực thi ở tốc độ bền vững, trong đó không cần nghỉ hoặc thời gian phục hồi giữa các Sprint.

Thực hiện Lean & Agile không phải điều đơn giản. Hệ tư tưởng đằng sau Lean & Agile là hợp lý và có ý nghĩa trong hầu hết trường hợp, nhưng đưa điều đó vào hành động đòi hỏi sự thay đổi tư duy và phá vỡ rất nhiều thói quen. Mặc dù nếu được thực hiện một cách chính xác, Lean & Agile sẽ mang lại năng suất, sự tích cực và đột phá cho các tổ chức.

Thanks for reading.

Tham khảo: https://medium.com/@takeshi.yoshida/a-pretty-good-summary-of-lean-agile-scrum-168cf123748