Giải thích về những sai lầm lớn nhất của việc chuyển đổi phân phối sang Agile
Khi các công ty chuyển đổi các giải pháp phần mềm từ on-Premise sang Cloud, họ thường đặt cho mình mục tiêu trở nên “linh hoạt” hơn. Điều này thường được áp dụng một cách lý tưởng cho mọi việc ở cấp độ xuyên công ty. Và tất nhiên là ở mọi nơi cùng một lúc.
Việc chuyển đổi các quy trình có thể dễ dàng thực hiện được, ít nhất là về mặt lý thuyết. Bạn có thể xác định các nghi thức scrum và phân công lại mọi người vào các vai trò mới (như người điều khiển scrum, chủ sở hữu sản phẩm, người quản lý phân phối và nhóm scrum).
Bạn có thể mang theo các công cụ như bảng Jira, Azure ADO và Miro và bắt buộc phải sử dụng chúng. Nhưng còn các quá trình kết nối các công cụ với nhau thì sao? Còn việc chuyển hóa tư duy, hành vi và cách làm việc của con người thì sao? Rõ ràng là những điều đó sẽ không chuyển hóa suôn sẻ và cũng sẽ không kết thúc nhanh chóng. Bây giờ chúng ta hãy quan sát lý do tại sao.
Mục lục
Sáng kiến chuyển đổi giao hàng là gì và tại sao các công ty đang thực hiện nó?
Một bộ phận lớn các công ty ngày nay vẫn hoạt động theo mô hình phân phối thác nước. Đó có nghĩa là:
Toàn bộ quá trình này có thể mất vài tháng đến vài năm và như bạn có thể thấy, người dùng sẽ chỉ thấy kết quả khi kết thúc quá trình đó. Vì vậy, sau một thời gian dài chờ đợi, khoảnh khắc của sự thật (hoặc thất bại) đã đến.
Nếu có điều gì đó thay đổi trong thời gian dài đó và sản phẩm cuối cùng trông hơi khác một chút thì đó là tình huống được gọi là yêu cầu thay đổi. Thiết kế phải được mở lại, làm lại và phê duyệt lại. Nó kéo dài toàn bộ lịch trình thời gian thêm một phần khác.
Rõ ràng, điều này không hề linh hoạt chút nào. Mọi thay đổi đều yêu cầu khởi động lại toàn bộ quá trình trước đó.
Chuyển sang Agile
Vậy làm thế nào để chúng ta thoát khỏi tình trạng này và thay đổi nó trở nên linh hoạt? Những người làm việc trong việc thiết lập thác nước trong nhiều năm, thậm chí nhiều thế kỷ. Họ có những vai trò và trách nhiệm mà họ cảm thấy thoải mái và họ không muốn thay đổi hiện trạng. Lý do chính cho điều đó là việc thực hiện thay đổi này cuối cùng đồng nghĩa với việc mất đi một số quyền lực mà họ có cho đến nay.
Đây là lý do chính tại sao sự thay đổi như vậy sẽ gây ra sự phản kháng mạnh mẽ nhất từ những người mà bạn có thể tạo ra.
#1. Tái cơ cấu đội ngũ
Việc đầu tiên và tương đối đơn giản nhất cần làm là cơ cấu lại mọi người thành các nhóm scrum. Phân chia chúng dựa trên các khu vực chức năng hoặc bất kỳ sự phân chia hợp lý nào khác hợp lý.
Việc chia tách thường diễn ra suôn sẻ; vấn đề bắt đầu khi bạn nhận ra rằng mọi người vẫn bị ràng buộc với cấu trúc ban đầu. Ngay cả khi họ đã là thành viên của nhóm scrum mới thì trên thực tế, họ vẫn chưa trở thành thành viên. Họ vẫn làm việc theo cách thiết lập cũ đó vì họ vẫn còn những trách nhiệm chưa kết thúc cùng với quá trình tái cấu trúc nhóm (vì tại sao lại như vậy – lãnh đạo không quan tâm nhiều đến những gì cần phải hoàn thành mà chủ yếu là về những gì phải bắt đầu).
Vì vậy, trên thực tế, bạn sẽ có một nhóm scrum không phải là nhóm scrum hoàn toàn chuyên tâm. Đó là một nhóm người giờ đây đơn giản là có nhiều việc phải làm hơn. Không có nhiều thời gian cho công việc trong nhóm scrum như ban quản lý mong đợi.
Đồng thời, kỳ vọng là mọi người sẽ hoàn thành các hoạt động ban đầu cũng như kỳ vọng mới này trong các nhóm scrum. Đó là một thiết lập được xác định là thất bại ngay từ đầu.
#2. Lên lịch các buổi lễ Scrum
Việc ra lệnh cho các nhóm lên lịch một số cuộc gọi thường xuyên (nghi lễ chạy nước rút) rất dễ xác định và bắt đầu. Ít nhất, giả sử nhóm scrum của bạn không bao gồm những người từ 3 múi giờ trở lên (điều này thường xảy ra).
Vấn đề bắt đầu khi mọi người không tham gia các nghi lễ một cách thường xuyên. Tùy thuộc vào người mất tích và mức độ thường xuyên, điều này có thể phát triển thành nhiều loại vấn đề khác nhau. Ví dụ:
- Nếu chủ sở hữu sản phẩm không tham dự các buổi lễ lập kế hoạch và sàng lọc, nhóm sẽ không có câu chuyện mới nào để tiếp tục. Hoặc mô tả câu chuyện quá kém đến mức những người còn lại trong nhóm không thể bắt tay vào thực hiện chúng.
- Nếu thiếu người quản lý scrum trong các cuộc gọi, thì nhóm đang thiếu sự điều phối scrum cơ bản và cuối cùng có thể bị lạc lối theo thời gian.
- Nếu các thành viên trong nhóm phát triển thường xuyên vắng mặt, họ không thể đồng bộ hóa với nhau và việc giao tiếp trong nhóm khó khăn hơn nhiều. Ngoài ra, cần có nhiều cuộc họp hơn để bắt kịp, điều này sẽ làm mất thêm thời gian của nhóm.
Cuối cùng, việc bỏ lỡ các buổi lễ không hẳn là lỗi của mọi người. Chỉ là thiết lập sẽ không cho phép họ tham gia các cuộc gọi (xem ở trên về các nhiệm vụ song song trước đó).
#3. Sự ổn định của đội
Bạn có thể có một nhóm scrum có cơ cấu và nghi thức, nhưng nếu nhóm đó không ổn định trong một khoảng thời gian dài hơn – giả sử lý tưởng là ít nhất nửa năm, thì một năm ổn định sẽ là yêu cầu tối thiểu của cá nhân tôi – thì một nhóm như vậy có thể không thực sự phát triển và cải thiện.
Tiếp theo, bạn có thể sẽ không bao giờ có được một nhóm scrum hoàn toàn độc lập để xử lý các lần chạy nước rút như công việc bình thường. Cuối cùng, bạn sẽ cần phải liên tục đào tạo và học hỏi những người trong nhóm để hiểu được tư duy và quy trình scrum. Đó là một vấn đề mệt mỏi phải có.
Đây là một vấn đề được đánh giá rất thấp, đặc biệt là bởi lãnh đạo hoặc quản lý của công ty. Gọi các nhóm người chỉ là “tài nguyên” và lập kế hoạch “sử dụng” họ từ quý này sang quý khác là con đường dẫn đến địa ngục ngay lập tức.
#4. Vai trò mới cho cùng một người
Một trở ngại khác cần vượt qua là phân công lại những người hiện có vào các vai trò mới khác nhau. Ví dụ: những người trước đây quản lý các nhóm có quyền lực tối cao giờ đây có thể trở thành Chủ sở hữu sản phẩm. Đây là một vị trí mạnh trong nhóm scrum, nhưng nó có thể được coi là một vai trò yếu hơn so với cơ cấu hiện có.
Đột nhiên, chủ sở hữu sản phẩm phải đồng bộ hóa với người quản lý chương trình hoặc người quản lý chương trình. Họ vẫn chịu trách nhiệm về nội dung nhưng không chịu trách nhiệm nhiều về quá trình phân phối. Tình trạng này đòi hỏi phải từ bỏ một số trách nhiệm mà mọi người đã đảm nhận trước đây và do đó, thật khó để chấp nhận.
#5. Cách thức làm việc
Điều này thật thú vị và thỉnh thoảng tôi nghe thấy nó khá thường xuyên – chúng ta cần học những cách làm việc mới để trở nên phù hợp trong thị trường đang phát triển, nơi sự linh hoạt là kỳ vọng cơ bản. Nhưng chính xác thì những cách làm việc đó có ý nghĩa gì?
Nếu bạn hỏi tôi, bạn sẽ thấy rõ ý nghĩa của việc quản lý đó – đạt được (nhiều) nhiều hơn trong thời gian ngắn hơn. Sau khi thành lập các nhóm scrum, kỳ vọng là mọi thành viên trong nhóm sẽ đột nhiên đạt được một số kết quả gia tăng được ghi nhận hàng ngày. Nếu không phải như vậy, lãnh đạo sẽ bắt đầu đặt câu hỏi tại sao quy trình linh hoạt lại không hoạt động tốt.
Đột nhiên, ban lãnh đạo mong đợi mỗi giờ đều có giá trị và các nhóm scrum về cơ bản không có thời gian nhàn rỗi, chỉ vì được cho là không có không gian cho tất cả các quy trình scrum tại chỗ. Và đó chính là định nghĩa tóm tắt về “cách làm việc mới” từ góc độ lãnh đạo.
Tất nhiên, kỳ vọng này không được xây dựng dựa trên việc kiểm tra thực tế. Thật ảo tưởng khi mong đợi mọi người trong công ty bắt đầu làm việc nhiều hơn trong cùng khoảng thời gian chỉ vì một số quy trình hàng ngày sẽ thay đổi. Ý tôi là, một số người trong số họ có thể, dù chỉ là thiểu số. Tuy nhiên, ngay cả nhóm này cũng bị thu hẹp hơn nữa khi họ phải làm lộn xộn nhiều nhiệm vụ hơn cùng một lúc.
Sự khác biệt giữa mục tiêu và thực tế
Không còn nghi ngờ gì nữa, phần mô tả về mục tiêu cuối cùng thường hay và rất có ý nghĩa. Nó xoay quanh các nguyên tắc sau:
- Các nhóm scrum ổn định đang xử lý các hồ sơ tồn đọng độc lập với KPI và OKR rõ ràng.
- Chủ sở hữu sản phẩm xây dựng lộ trình vững chắc và lên kế hoạch cho nội dung được ưu tiên phân phối theo các mốc thời gian cụ thể.
- Nội dung tồn đọng được xác định với các tính năng liên quan đã được trình bày chi tiết trước khi công việc bắt đầu.
- Các quy trình kiểm tra đáng tin cậy được thực hiện cùng với công việc phát triển chạy nước rút thông thường.
- Phát hành thường xuyên vào sản xuất – ít nhất một lần mỗi tháng, nhưng lý tưởng nhất là sau mỗi lần hoàn thành chạy nước rút.
- Theo dõi rủi ro và các vấn đề cũng như liên lạc giữa các nhóm scrum khác nhau trong trường hợp phụ thuộc.
Sau đó, khi nhìn vào thực tế, tôi có thể nói rằng không có điểm nào ở trên là dễ dàng đạt được.
- Bạn thành lập các nhóm scrum, nhưng họ liên tục thay đổi (từ quý này sang quý khác). Bạn đầu tư thời gian để dạy nhóm về các quy trình scrum và khi họ bắt đầu chấp nhận nó và thay đổi cách làm việc, bạn sẽ tổ chức lại các nhóm cho giai đoạn tiếp theo. Lộ trình được sửa đổi, thay đổi hoặc hủy bỏ.
- Chủ sở hữu sản phẩm không biết thực sự về chi tiết lộ trình và (chỉ vì trước đây họ đã có thói quen như vậy) nên họ sẽ giao nhiệm vụ xây dựng nội dung tồn đọng trực tiếp cho nhóm. Do đó, nhóm không có thời gian để phát triển nội dung vì trước tiên họ cần tìm ra nội dung cần phát triển.
- Các quy trình kiểm tra chỉ thực hiện thủ công và yêu cầu nhiều bước phụ, phê duyệt cũng như các quy trình phức tạp phải tuân theo. Điều đó có nghĩa là không có cách nào việc thử nghiệm có thể hoàn thành trong cùng một lần chạy nước rút như quá trình phát triển.
- Kết quả là, việc phát hành vào sản xuất đang bị chậm lại vài lần chạy nước rút.
- Giao tiếp giữa các nhóm scrum khác nhau rất hỗn loạn và không hiệu quả, vì mỗi nhóm có rất nhiều hoạt động cần hoàn thành trong mỗi lần chạy nước rút. Trên thực tế, chủ sở hữu sản phẩm có xu hướng giao cho nhóm quá nhiều nội dung trong mỗi lần chạy nước rút. Nhóm không có cơ hội hoàn thành hết nên họ thường xuyên bị căng thẳng về thời hạn.
Sửa chữa sai lầm
Với kinh nghiệm từ một số dự án chuyển đổi linh hoạt, tôi xin tóm tắt một số sai lầm lớn nhất mà tôi đã trải qua và đưa ra một số ý kiến chủ quan về khả năng khắc phục chúng.
#1. Đúng trách nhiệm cho đúng vai trò
Nếu bạn cố gắng bẻ cong định nghĩa và phân bổ trách nhiệm theo bất kỳ cách nào khác ngoài cách lẽ ra phải có của scrum/agile, thì bạn đang khiến toàn bộ sáng kiến bị thất bại.
- Chủ sở hữu sản phẩm sẽ sở hữu nội dung và duy trì hồ sơ tồn đọng. Họ chịu trách nhiệm về các câu chuyện tồn đọng và nếu các câu chuyện tồn đọng không được xác định rõ ràng thì họ phải hành động và khắc phục nó. Mặt khác, họ không được có bất kỳ ảnh hưởng nào đến việc phân công hoặc quyết định của những người trong nhóm scrum về ngân sách dự án.
- Scrum master sẽ không chịu bất kỳ trách nhiệm nào liên quan đến nội dung tồn đọng. Họ ở trong nhóm để sắp xếp các buổi lễ và hướng dẫn nhóm một cách làm việc nhanh nhẹn. Họ không nên làm thư ký cho Chủ sản phẩm. Ngược lại, họ sẽ bảo vệ nhóm phát triển trước chủ sở hữu sản phẩm và các bên liên quan bên ngoài.
- Mỗi nhóm scrum sẽ được chỉ định một trưởng nhóm giao hàng. Người này sẽ kết nối PO, SM và nhóm phát triển thành một thiết lập khả thi, xác định quy trình phân phối và giải quyết mọi rủi ro, vấn đề hoặc xung đột tiềm ẩn mà nhóm có thể gặp phải. Trưởng nhóm giao hàng là người phù hợp để quyết định các câu hỏi về nhân sự và ngân sách của dự án. Người này sẽ cố gắng xây dựng một môi trường cho nhóm nơi mọi người có thể phát huy hết khả năng của mình.
- Trách nhiệm của nhóm phát triển là phát triển các câu chuyện từ hồ sơ tồn đọng. Họ có thể giúp PO xây dựng nội dung cho một số câu chuyện (chủ yếu là những câu chuyện quá kỹ thuật), nhưng họ không chịu trách nhiệm hoặc thậm chí không chịu trách nhiệm về những câu chuyện xây dựng lộ trình tạo nội dung.
#2. Đội ổn định
Đầu tư vào nền giáo dục linh hoạt của nhóm là quan trọng và phải là một quá trình nhanh chóng. Cứ vài tháng lại bỏ đi những kiến thức này chỉ là lãng phí thời gian đối với mọi người.
Năm lần chạy nước rút đầu tiên mà bạn có thể sử dụng làm lộ trình học tập để nhóm làm quen và thực hành các hoạt động scrum cơ bản. Khi những điều đó đã rõ ràng đối với cả nhóm, quá trình cải tiến liên tục của nhóm scrum có thể bắt đầu. Nhưng nếu những người trong nhóm thay đổi thường xuyên, bạn sẽ thấy mình luôn ở trong một vòng lặp chuyển giao kiến thức và giáo dục.
Một nhóm như vậy có thể sẽ không bao giờ đạt được tiềm năng hoạt động tối đa và đội ngũ lãnh đạo sẽ tiếp tục tự hỏi tại sao trước đây (trước khi chuyển đổi linh hoạt) họ lại hiệu quả hơn hiện tại.
Vì vậy, hãy xây dựng nhóm, đầu tư kiến thức và khi nhóm đã tự tin với các quy trình mới, hãy giữ nguyên như hiện tại và phát triển hơn nữa. Từ đây, con đường không ngừng hướng tới sự hoàn hảo sẽ bắt đầu.
#3. Ma trận RACI
Một cách thực hành tốt là xây dựng và thống nhất về ma trận RACI (Trách nhiệm, Chịu trách nhiệm, Được tư vấn, Được thông báo) giữa tất cả các nhóm ngay trước khi công việc thực sự bắt đầu. Điều này có thể loại bỏ rất nhiều nhầm lẫn ngay từ đầu.
Điều này khá quan trọng, đặc biệt là trong giai đoạn đầu của các sáng kiến chuyển đổi. Nếu không, mọi người sẽ bắt đầu đặt ra câu hỏi về việc ai nên làm gì trong tình huống nào, đặc biệt là trong những vấn đề chưa được giải quyết rõ ràng thông qua kênh liên lạc của nhóm.
Đây là một ví dụ về ma trận RACI như vậy cho một số trách nhiệm. Dự án của bạn có thể có một bộ khác. Điều quan trọng là phải nắm bắt được những cái có liên quan.
TaskRequestorTrưởng nhóm giao hàngProduct OwnerScrum MasterDev TeamPhiên lập kế hoạch SprintC/ICA/IRC/IDeliver Gia tăng phát hànhN/AIA/IC/IRSĐánh giá bản inC/IIRICSprint RetrospectiveIIA/IRC/IRefine the BacklogIA/IRAC/I
Phần kết luận
Có thể vẫn còn nhiều điều để viết, vì có nhiều cách và nhiều nơi mà việc chuyển đổi linh hoạt có thể dẫn đến chệch hướng. Mục đích là để chỉ ra một số vấn đề mà tôi cho là thường xuyên lặp lại.
Bản thân sáng kiến này đã là một ý tưởng hay. Tuy nhiên, nó có thể nhanh chóng trở thành cơn ác mộng đối với tất cả những người tham gia nếu bạn tuân thủ một số quy tắc cơ bản. Tôi đã đánh dấu một vài trong số chúng, nhưng chỉ cần sử dụng cảm giác thông thường là bạn sẽ ổn thôi. 🙂
Tiếp theo, hãy xem các tài nguyên học tập tốt để lấy chứng chỉ Agile.
