Một bản tóm tắt khá hay về Lean, Agile, Scrum

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

• Coi Lean & Agile là khá giống nhau, về cơ bản chúng là những cách tiếp cận thực sự tốt để xử lý các dự án có nhiều điều không chắc chắn, đó là lý do tại sao các công ty khởi nghiệp thành công thực hiện phương pháp này. (Để biết lịch sử thực tế của nguồn gốc của Lean, Agile và Scrum thì, tham khảo ở đây.)

• Scrum và Kanban là 2 Framework quản lý dự án Agile phổ biến nhất. Chúng khác nhau khá nhiều — Scrum thì có vẻ như được sử dụng nhiều hơn và Kanban thuần túy thì ít hơn. Nhưng trong thực tế, mọi người đều sử dụng phiên bản sửa đổi Scrum của riêng họ, cách mà được khuyến khích và thường sử dụng các yếu tố của Kanban (chúng tôi cũng vậy).

• Sprint là một thuật ngữ của Scrum. Nó là chu trình lặp đi lặp lại trong Scrum.

• Vì thế: Lean ≈ Agile > Scrum > Sprint

Tại sao là Lean & Agile?

Bởi vì trong thế giới thay đổi của sự tham gia của Social và Digital, chúng ta cần một cách tốt hơn để làm Business và Managing các tổ chức.

Lean & Agile là thuốc giải độc 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.

1. Quản lý dự án Waterfall, và

2. Cấu trúc tổ chức phân cấp chức năng.

Quản lý dự án Waterfall và Agile

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

Tư duy quản lý dự án Waterfall đã ăn sâu vào văn hóa của chúng ta. Nền giáo dục của chúng ta cũng nhấn mạnh vào sự chuẩn bị thật tốt và thận trọng trong từng bước. Tiến độ được đáp ứng những điểm trên Check Point. Việc biết đang đi đúng hướng mang lại cho chúng ta sự thoải mái và tự tin, và nó cũng giúp cho việc giám sát và quản lý dễ dàng hơn cho các giáo viên và Leader chúng tôi. Đó là một cách tiếp cận tốt. Nhiều tuyệt tác hiện đại trên thế giới sẽ không tồn tại nếu như không có Waterfall. Các doanh nghiệp trên toàn cầu đã mở rộng thành công với Waterfall. Nhưng Waterfall có những hạn chế của nó: Nó hoạt động tốt trong các dự án có tính chất lập đi lặp lại tự nhiên và và độ không chắc chắn tương đối thấp.

Thực tế thì, thế giới đầy những bất trắc. Rất khó để dự đoán hành vi của con người. Và trong một dự án mà bạn đang phát triển một sản phẩm mà chưa tìm thấy thị trường, quản lý dự án Waterfall là một cách rất tốn kém để tìm kiếm sự phù hợp với thị trường sản phẩm. Ở đó thì chỉ có số lần hữu hạn bạn có thể loại bỏ và xây dựng lại các sản phẩm, và thời gian cần thiết để trải qua một lần lặp xây dựng sản phẩm trong Waterfall khiến bạn trong thế bất lợi so với đối thủ cạnh tranh.

Agile nổi lên như một giải pháp chống lại những thiếu sót của Waterfall. Đó là 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 cho các doanh nghiệp để đối phó với những điều không chắc chắn xung quanh trong Business của mình. Và trong thế giới chuyển đổi kỹ thuật số nhanh chóng này, không chỉ là những công ty Startup phải đối phó sự phá vỡ thị trường. Các doanh nghiệp thuộc mọi quy mô trong các ngành cần một cách tốt hơn để đối phó với sự thay đổi, và Agile là một giải pháp.

Cấu trúc tổ chức truyền thống và Agile

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

Trong tổ chức truyền thống, Leadership và Management Team chịu trách nhiệm ra quyết định — cho chiến lược và giải quyết vấn đề, các câu trả lời được mong đợi đến từ phía trên. Điều này gây rủi ro rất lớn cho các Leader “trong việc phải đưa ra những quyết định đúng đắn”. Tuy nhiên, một lần nữa, trong thời đại phát triển nhanh chóng của Digital và Social, rất hiếm có những người hội tụ đủ đầy đủ tất cả những yếu tố. Nhận thấy rằng giải quyết vấn đề là một quy trình khám phá, Agile khuyến khích xây dựng giả thuyết và thử nghiệm giống như một bài tập của tất cả tổ chức. Nói một cách đơn giản, chỉ cần đặt nhiều cặp mắt và trí tuệ tập thể làm tăng cơ hội “nhận được những điều đúng đắn”.

Tinh thần của Lean & Agile

Lean & Agile là cách tiếp cận, không phải phương pháp. Thậm chí Scrum, một Framework triển khai của Agile, cũng tự chối được gọi mà một phương pháp. Đo là bời vì không có một phương pháp cứng nhắc nào mà có tác dụng giải quyết vấn đề chống lại mọi sự không chắc chắn. Thay vào đó, bạn làm theo những nguyên tắc chung nhất định, hoặc có thể được tóm tắt giống như tinh thần của Lean & Agile, và áp dụng chặt chẽ nó:

• Không ngừng theo đuổi sản phẩm phù hợp với thị trường (= Cung cấp giá trị thực cho khác hàng) như là một nỗ lực của toàn bộ tổ chức.

• Xây dựng, đo lường, học hỏi: chấp nhận sự không chắc chắn — đó là lý do tại sao chúng tôi đưa ra giả thuyết, Test và Validate để xem liệu chúng ta có đang tiến gần hơn đến những gì mà khách hàng thực sự muốn hay không. Thực hiện theo từng bước nhỏ và tiếp tục lặp đi lặp lại cho đến khi nó được cố định.

• Đó là công việc của mọi người để hiểu khách hàng, không chỉ là Sale & Marketing hay là Leadership Team. Nó không phải là công việc của ai khác để nghĩ về khách hàng — Nó cũng là công việc của bạn. Vì vậy, bạn được phép và được khuyến khích để Run “Xây dựng - Đo lường - Học hỏi” thử nghiệm với khách hàng (thậm chí ngay cả khi bạn không trực tiếp đối mặt với khách hàng), và Leadership Team sẽ tạo điều kiện, với tư cách như một Servant Leader, một Framework hợp tác làm việc có hệ thống.

• Trong Lean & Agile, không ai bị khiển trách Nếu có một thất bại, chúng ta không tìm kiếm ai đó để đổ lỗi, thay vào đó chúng ta kiểm tra lại hệ thống đã tạo ra lỗi và khắc phục nó.

Triển khai Scrum

Phân cấp Vision

Đầu tiên, Vision doanh nghiệp của bạn cần được chia sẻ với mọi người trong tổ chức như là một cách “kết nối”: mọi thứ mà mọi người làm, cho đến cấp độ Task của công việc cá nhân, cần được kết nối lại với Vision.

Điều này khó hơn những gì ta tưởng. Leadership có thể nói và trình bày về Vision, nhưng không nhất thiết phải được tán thành của tất cả mọi người. Bài tập chia sẻ Vision thực sự là một bài tập hình thành Vision với con người của bạn.

Enter Scrum: Epic, Story, Task là những thuật ngữ Scrum, cái mà giúp mọi người nghĩ về tất cả những điều quan trong một sản phẩm hay dự án cần phải được xây dựng hoặc thực hiện để hiện thực hóa Vision chung. Theo thiết kế, Scrum đặt mọi người trong cùng một trang bằng việc bài tập tạo ra “Backlog” dọc theo phân cấp Vision.

Running Sprints

Scurm là một Framework quản lý dự án “có ràng buộc thời gian” bằng những Sprint, nơi mà bạn đặt khoảng thời gian cố định của chu kỳ công việc, thường là khoảng thừ một cho đến bốn tuần, theo đặc điểm công việc của Team bạn. (Kanban cũng là một Framework quản lý dự án khác phổ biến của Agile, là cách tiếp cận “ràng buộc về năng lực”.)

Ý tưởng là làm mọi thứ theo từng bước nhỏ và lặp lại nhanh, với sự nhấn mạnh vào việc xem xét công việc để giúp Team tiến tới mục tiêu. Xây dựng giả thuyết và lặp lại việc thử nghiệm là một phần không thể thiếu của Scrum, vì hầu hết các dự án đều đối mặt với sự không chắc chắn, và khám phá là chìa khóa (Marketing là một ví dụ điển hình — Bản thân việc sản phẩm phù hợp với thị trường là một quá trình khám phá).

1. Backlog

Hãy suy nghĩ về mọi thứ có trong sản phẩm hoặc những thứ cần phải được thực hiện trong dự án. Bước đi trên hành trình của User: User Story là cách tuyệt với để bối cảnh hóa mong muốn và nhu cầu của khách hàng.

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

2. Sprint Planning

Đặt độ ưu tiên và ước lượng Backlog, quyết định những việc cần làm trong Sprint tiếp theo.

• Để ước lượng thời gian cần thiết để hoàn thành mỗi Job, Planning Poker làm một công cụ hữu ích.

• Kanban Board (hoặc Scrum Board) là Item chính trong Scrum. Đây là nơi mà thông tin được hiển thị liên tục, trực quan hóa và chia sẻ với Team. Khuyến khích việc tùy chỉnh để phù hợp với Workflow của Team.

• Definition of Done là một điều phải tuân thủ trong Scrum. Definition of Done không chỉ là một khái niệm đảm bảo chất lượng cho các thành viên Sprint Team để xác minh công việc trước khi Release. Nó cũng là một tiêu chí đo lường và học hỏi cho nhiều giả thuyết và thử nghiệm diễn tra trong Sprint.

• Có hai vài trò Leader điều phối trong Scrum. Đầu tiên là Product Owner, “what” guy, và thứ hai là Scrum Master, “how” guy. Chìa khóa là sự điều phối — năng suất của Scrum Team được đo lường bởi velocity (tốc độ), hay độ nhanh mà họ có thể hoàn thành công việc, và cách hiệu quả nhất là tạo điều kiện cho các thành viên trong nhóm, để cá nhân và tập thể đưa ra quyết định phải làm gì và làm công việc như thế nào, chứ không phải là hướng dẫn họ như trong những tổ chức truyền thống.

3. Daily Stand Up

Một Scrum Team điển hình thì nên trong khoảng từ 3-9 người, bao gồm cả Product Owner và Scrum Master. Nếu lớn hơn thì tốc độ của Team giảm xuống, vì vậy tốt nhất là nên chia thành các Scrum Team khác nhau.

Chìa khóa của vận tốc là sự giao tiếp phong phú giữa các thành viên trong Team về tiến độ và các trở ngại. Daily Stand Up với hình thức cố định được chứng minh là có hiệu quả cho mục đích này: Mỗi ngày tại cùng thời gian, dưới 15 phút, cả Team tập hợp lại trước Kanban Board, và mỗi thành viên Team sẽ chia sẻ tiến độ của họ bằng việc trả lời 3 câu hỏi sau:

✓ Bạn đã làm gì vào ngày hôm qua?

✓ Bạn dự định làm gì trong ngày hôm nay?

✓ Có bất kỳ trở ngại nào trên tiến trình hay không?

Ngoài ra, Team cũng có thể xem qua theo trình tự của các hạng mục Done hoặc Todo trên Kanban Board. Nó là cách tốt hơn nếu như có nhiều thành viên trong Team tham gia vào mỗi Item của Kanban Board.

Daily Stand Up không phải là cuộc họp để cập nhật trạng thái cho Manager để tìm ra ai đang bị chậm tiến độ hoặc là hướng dẫn công việc cho họ. Việc cập nhật trạng tái chỉ cung cấp Snapshot — Cái quan trọng là kiểm tra Flow. Stand Up là để cho Team hiểu được những công việc đã hoàn thành và những gì còn lại, để mọi người có thể tặng tốc làm việc Teamwork. Nếu một ai đó đang bị mặc kẹt, các thành viên Team có thể đến giúp đỡ. Và nếu cần thiết, Scrum Master sẽ điều chỉnh lại Work Flow để tạo điều kiện loại bỏ trở ngại.

4. Sprint Review và Retrospective

Vào cuối mỗi Sprint, Scrum Team thực hiện hai Meeting.

Cái đầu tiên là “what” Meeting: Sprint Review xem xét những gì đã thực hiện trong Sprint vừa qua, và được điều phối bởi Product Owner. Cuộc họp này thường đi kèm với các Demo của Release mới và các thành tưu đạt được khác, và các thành viên còn lại của tổ chức được hoan nghênh tham gia.

Cái thứ hai là “how” Meeting: Sprint Retrospective. Đây là lúc để các thành viên Scrum Team phản ánh và thảo luận về những trở ngại xuất hiện trong Sprint vừa qua, ngay cả khi mọi thứ đang diễn ra tốt đẹp, các ý tưởng để cải thiện. Scrum Owner tạo điều kiện thuận lợi cho Meeting này bằng việc tập trung còn lại trên việc sửa lỗi quy trình mà không phải là để đổ lỗi trên người khác.

Kết thúc cả hai cuộc họp, Team cập nhật Backlog và lên kế hoạch cho Sprint tiếp theo.

Cạm bẫy phổ biến của Scrum

‣ Scrum không có linh hồn: Sprint giống như Mini-Waterfall

Thông thường, User Story trở thành những tài liệu đặc tả nhỏ. Cùng với đó, Coding hoặc bật kỳ hoạt động nào được thực hiện, sau đó là UAT (user acceptance testing) hoặc là quá trình ... khác. Thoạt nhìn thì điều này có vẻ không sai, và nhiều Team rơi vào cái bẫy này.

Vấn đề là, đây chỉ là kiểu Running một dự án nhỏ theo kiểu Waterfall thu nhỏ. Việc phân tích, thiết kế, Coding và Testing được thực hiện theo kiểu tuần tự, có thể trải qua nhiều Sprint và rất có thể là quá trình chuyển giao giữa các chức năng (ví dụ như BA (Phân tích nghiệp vụ) > Developer > QA (Đảm bảo chất lượng)).

Lean & Agile là về khám phía để chống lại sự không chắc chắn. Trong Scrum, chu trình “Xây dựng - đo lường - học hỏi” được thiết kế để xảy ra trong Sprint, và thành viên Team làm việc dựa trên giả thuyết, MVP (Minimum viable product) xây dựng và Testing cần làm việc và Close vấn đề sớm nhất có thể với nhau; tức là Teamwork đa chức năng. Công việc không phải là tuần tự — nếu một cái gì đó không hoạt động hoặc thiếu điểm quan trọng, nó hoàn toàn ok để làm thay đổi thiết kế và sửa đổi, hoặc đưa ra một quyết định có ý thức để theo đuổi cách tiếp cận khác nhau; tức là tinh chỉnh và mini-pivoting. Waterfall nhỏ hủy hoại mục đích của sự lặp lại và chỉ đạt được những lợi ích nhỏ của Scrum.

‣ Scrum cục bộ

Agile bây giờ là một nơi phổ biến trong các Team phát triển phần mềm. Vấn đề là, trong nhiều tổ chức, đó chỉ là một Team phát triển đang Run Scrum, kết quả là tạo ra một hòn đảo trong tổ chức.

Kết quả là tạo ra một văn hóa chuyển giao giữa Development Team và phần còn lại của tổ chức, chẳng hạn như Sale Team: “Chúng tôi đã kết hợp vào sản phẩm theo đặc tả mà bạn yêu cầu, bây giờ thì vui lòng đi bán nó.”

Chìa khóa để lan truyền Agile rộng rãi trong tổ chức là để mọi người nhận thức Agile giống như một khái niệm rộng lớn hơn về giao tiếp, hợp tác và đồng sáng tạo, và 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 không thể có đủ kết nối giữa chúng ta với nhau, 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ự sáng tạo giá trị khách hàng bền vững và tư duy sản phẩm phù hợp thị trường giữa các Team.

Về mặt triển khai thực tế của Agile trên toàn tổ chức, Scrum về Sale và Marketing có thể được Run song song cùng với Developement Scrum Team. 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 mà Development, Sale và Marketing đều nằm trong mỗi Scrum Team, và được căn chỉnh bởi dự án khách hàng hoặc sản phẩm.

‣ Scrum Master in Command

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

Scrum là một nỗ lực có hệ thống để đưa tổ chức ra khỏi kiểu Manager-Worker. Các mô hình Commanding Leadership thất bại trong việc giải quyết vấn đề doanh nghiệp — nó dựa vào những Leader để có tất cả các câu trả lời, làm cho chính các Leader trở thành trở ngại.

Trong một tổ chức Agile, bạn cố gắng mang ra tất cả những “co’s / cùng nhau” từ mọi người — cooperation, collaboration, coordination, co-creation, communication, connection (hợp tác, cộng tác, đồng sáng tạo, giao tiếp và kết nối) v.v. Vai trò Scrum Master giữ cho dòng chảy “co / cùng nhau” được ngang nhau, không thẳng đứng giống như Command (chỉ huy).

Chúng ta cũng phải hiểu sự thoải mái thụ động của “worker” trong chế độ Manager-Worker: Việc lấy sự chỉ dẫn cho công việc là thoải mái bởi vì bạn sẽ không phải nghĩ tại sao và làm như thế nào, và bạn không chịu trách nhiệm 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ủ trong nhiều cách; cách tiếp cận chia thành khối nhỏ kiến cho việc quản lý dễ dàng hơn, Daily Stand Up có nghĩa là để các thành viên Team giúp đỡ lẫn nhau khi họ gặp rắc rối, 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 Leader nghĩ rằng “Sprints” giống như một phương tiện có hệ thống để làm cho mọi người làm việc chăm chỉ ở mức tập trung cao độ, điều đó đơn giản là kiểu quản lý theo thói quen bởi khủng hoảng hoặc tệ hơn là sự bóc lột sức lao động.

Một Leader ít độc ác hơn có thể xem “Sprint” là một cái gì đó giống như là “Interval Training” dưới sự theo dõi hoặc Swimming. Anh ta có thể lập luận rằng, bằng việc đi qua một chu kỳ liên tục của công việc có cường độ cao, Team sẽ đạt đến giới hạn của hiệu suất. Nhưng điều này có dẫn đến nguy cơ thành viên 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 một Sprint mới để cố gắng hồi phục từ Sprint trước đó, rõ ràng họ đang bị quá tải. Sprint phải được Run ở 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.

Scrum Sprints có lẽ không nên được gọi là “chạy nước rút”, thực sự. Nó nên được gọi kiểu như ”Jogging / chạy bộ” hay là một thứ gì đấy. Nếu thực bạn muốn tăng “velocity / tốc độ” của Team (trong Scrum chúng ta sử dụng “Burn Down Charts” để đo lường điều này), nhưng đó không phải là tốc độ cuối cùng mà bạn đi sau đó. Đó là việc cải thiện tốc độ trung bình mà bạn theo đuổi, tức là có nhiều hơn khoảng cách được bao phủ trong cùng một khoảng thời gian. Và giống như bất kỳ người chạy đường dài nào sẽ chứng thực, tìm ra tốc độ và nhịp điệu là chìa khóa phù hợp để đi được quảng đường.

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

Thank you for reading. Vui lòng Share hoặc Follow nếu bạn thích bản dịch này và hãy chia sẻ suy nghĩ của bạn! Hy vọng bạn cũng thích những bài dịch khác của tôi:

[Source: https://medium.com/@takeshi.yoshida/a-pretty-good-summary-of-lean-agile-scrum-168cf123748]