Cách tiếp cận quá trình chuyển đổi từ Scrum sang SAFe

Việc triển khai các nhóm Scrum chức năng vào một tổ chức tự nó đã là một thách thức và nhiều người liên tục thất bại ở bước này. Tuy nhiên, khi bạn có nhiều nhóm phụ thuộc nhiều hoạt động trong cùng một dòng sản phẩm hoặc giá trị, bạn cần thứ gì đó mạnh mẽ hơn.

Cần phải sử dụng một khuôn khổ mở rộng quy mô cho các nhóm Scrum. Cung cấp cho họ các quy trình và quy tắc cần tuân theo để đồng bộ hóa với nhau, căn chỉnh và không bị lạc trong quá trình thực hiện.

Thường thì bạn kết thúc với các nhóm Silo, về cơ bản có nghĩa là các nhóm scrum độc lập hoạt động hướng tới mục tiêu địa phương của họ nhưng hầu như không có manh mối nào về mục tiêu chung cuối cùng của toàn bộ chương trình. Đây là lúc Khung công tác Agile có quy mô (SAFe) phát huy tác dụng.

SAFe là gì?

Nguồn: http://scaledagileframework.com

SAFe là một cách tiếp cận áp dụng khuôn khổ và quy trình linh hoạt cho các tổ chức phân cấp trước đây. Nó bao gồm các cấp độ cấu trúc và quy trình, nhưng thay vì tạo lại chúng, nó giới thiệu lại hệ thống thứ hai theo cách hữu cơ quen thuộc với hầu hết các bên liên quan hiện có của hệ thống ban đầu.

SAFe được xây dựng dựa trên một số giá trị cốt lõi.

Căn chỉnh

• Tất cả các nhóm scrum cần hiểu tầm nhìn và chiến lược cũng như mục tiêu cuối cùng mà họ đang hướng tới là gì.
• Kết nối chiến lược giữa các nhóm và dẫn dắt họ cùng thực hiện.
• Giao tiếp với các nhóm bằng một ngôn ngữ chung thống nhất mà họ có thể dễ dàng hiểu được.
• Thường xuyên kiểm tra xem các nhóm có hiểu được mục tiêu và tầm nhìn hay không.
• Các nhóm cần lấy khách hàng làm trung tâm và họ nên hiểu khách hàng là ai và họ cần gì. Cập nhật chiến lược để phản ánh điều đó.

Minh bạch

• Tạo ra một môi trường nơi mọi người có thể làm việc hết khả năng của mình mà không bị thiếu sự tin tưởng.
• Truyền đạt một cách cởi mở các lập luận và sự thật của bạn. Hãy thẳng thắn và trung thực, đồng thời không che giấu những sự thật quan trọng trước mặt các đội.
• Thất bại nhanh chóng và biến sai lầm thành những khoảnh khắc học hỏi. Nếu điều gì đó không thành công, hãy sớm nhận ra điều đó và rút kinh nghiệm từ nó. Sau đó, thay đổi chiến lược của bạn.
• Hãy trực quan hóa công việc bạn đang xây dựng để mọi người có thể hiểu rõ hơn.
• Cung cấp quyền truy cập sẵn sàng vào thông tin cần thiết.

Tôn trọng người khác

• Nhấn mạnh ý nghĩa của việc trở thành con người. Đừng coi con người là tài nguyên.
• Đánh giá cao sự đa dạng của con người và ý kiến ​​của họ. Hỗ trợ phản hồi trung thực.
• Phát triển và giáo dục mọi người thông qua huấn luyện và cố vấn.
• Hãy hiểu rằng khách hàng của bạn là người tiêu thụ công việc của bạn.
• Xây dựng mối quan hệ hợp tác lâu dài trong và ngoài nhóm.

Cải tiến không ngừng

• Xây dựng một môi trường trong đó việc giải quyết vấn đề sẽ tạo động lực cho các nhóm.
• Hãy suy ngẫm về cách bạn đã làm trong tuần trước và xác định những gì có thể làm tốt hơn vào lần tới.
• Hãy lấy sự thật làm lý lẽ quan trọng nhất để cải thiện mọi thứ.
• Cung cấp thời gian và không gian cho sự đổi mới. Tạo cơ hội cho các đội thử nghiệm và thử các tuyến đường khác nhau, ngay cả khi chúng không phải là tuyến đường an toàn nhất.

SAFe mang đến một lớp cộng tác và giao tiếp cho các hệ thống Agile có quy mô lớn. Nó không thay thế các Hoạt động chạy nước rút của Nhóm Scrum riêng lẻ mà bạn thực hiện ngày hôm nay.

Một phần quan trọng của mọi SAFe là Chương trình đào tạo phát hành linh hoạt (ART). Đó là một nhóm Scrum ổn định, lâu dài (thường có tới 12 nhóm riêng biệt) thường xuyên mang đến các chức năng gia tăng mới sau mỗi lần phát hành nước rút. Họ phát triển, cung cấp và hỗ trợ một hoặc nhiều giải pháp trong quy trình làm việc.

Nguồn: http://scaledagileframework.com

Vai trò của SAFe

SAFe dựa vào những người có trách nhiệm khác nhau. Bám sát những kỳ vọng đối với các vai trò là yếu tố quan trọng quyết định mức độ thành công của việc triển khai khuôn khổ. Do đó, điều quan trọng là phải hiểu những vai trò đó là gì và mục đích của chúng là gì.

#1. Đội ngũ nhanh nhẹn

Các nhóm Agile có tính đa chức năng, có nghĩa là họ có thể bao quát toàn bộ lĩnh vực mà họ đang triển khai trong chính nhóm đó. Họ cũng là những thực thể tự tổ chức xác định, xây dựng, thử nghiệm, triển khai và giải phóng các giá trị gia tăng.

Mỗi nhóm Agile có bộ kỹ năng để thực hiện theo phạm vi đã thỏa thuận và cam kết của họ. Nhóm triển khai phạm vi đó bằng cách tăng dần mỗi lần chạy nước rút theo cách có thể dự đoán được. Khả năng dự đoán là rất quan trọng vì chỉ khi đó nhóm mới có thể cam kết thực hiện các mục tiêu cụ thể trong thời gian cụ thể. Giao tiếp và phân phối là những giá trị quan trọng mà nhóm sẽ không ngừng cải thiện.

Nhóm linh hoạt là một phần cơ bản của các buổi Lập kế hoạch Tăng trưởng Chương trình (PI) để tạo các câu chuyện trong và lên kế hoạch cho chúng trong Sprint. Cuối cùng, họ cam kết thực hiện các Mục tiêu PI của riêng mình.

Scrum Master huấn luyện Nhóm Agile và điều phối các cuộc họp nhóm. Họ loại bỏ những trở ngại và bảo vệ nhóm khỏi ảnh hưởng từ bên ngoài. Họ tham gia các cuộc họp Scrum như một phần của ART.

Chủ sản phẩm (PO) là một thành viên đặc biệt khác của nhóm. PO là tiếng nói của khách hàng và có ảnh hưởng trực tiếp đến câu chuyện cũng như mức độ ưu tiên của họ. PO liên lạc với các PO khác để xác định và ưu tiên các câu chuyện trong hồ sơ tồn đọng của các nhóm.

#2. Quản lý sản phẩm

Quản lý sản phẩm nằm phía trên các nhóm scrum và chịu trách nhiệm về sự liên kết giữa các nhóm. Họ cần phải đảm nhận các trách nhiệm sau:

• Đáp ứng các mục tiêu kinh doanh bằng cách đảm bảo các nhóm phát triển tạo ra các sản phẩm và giải pháp khả thi và bền vững.
• Hiểu nhu cầu của khách hàng và đảm bảo sản phẩm được hoàn thiện theo quan điểm khách hàng đã xác định.
• Đảm bảo luôn có đủ tính năng sẵn sàng trong hồ sơ tồn đọng.
• Hỗ trợ luồng công việc thông qua bảng chương trình và vào phần tồn đọng của chương trình.
• Xác định phạm vi của bước tăng chương trình tiếp theo bằng cách cung cấp mức độ ưu tiên cho các tính năng mà nhóm đã tạo. Quản lý sản phẩm chịu trách nhiệm cuối cùng về việc xác định PI tiếp theo.

#3. Kiến trúc sư/Kỹ thuật hệ thống

Nhóm kỹ thuật phân tích và phát triển nội dung đã thống nhất của các câu chuyện tồn đọng. Họ là bộ phận chuyên môn của nhóm và họ đảm nhận các trách nhiệm sau:

• Tạo và duy trì Đường băng kiến ​​trúc để các tính năng mới có thể sử dụng các công cụ hỗ trợ công nghệ.
• Tích cực tham gia Lập kế hoạch tăng cường chương trình. Có mặt trong các bản trình diễn Hệ thống ở cuối mỗi phần của chương trình.
• Làm việc với các nhóm linh hoạt để triển khai các công cụ hỗ trợ kiến ​​trúc mới. Chỉ điều này mới cho phép các nhóm xây dựng các tính năng mới.
• Giúp các nhóm linh hoạt xác định các giải pháp và quyết định thiết kế cấp cao. Đề xuất các giải pháp thay thế và cách tiếp cận tốt nhất cho các hoạt động chứng minh khái niệm trong các nhóm linh hoạt.
• Họ tạo ra một đường băng kiến ​​trúc. Đó là định nghĩa về các công cụ hỗ trợ công nghệ sẵn sàng được sử dụng bởi các tính năng do các nhóm tương ứng xác định.

#4. Chủ doanh nghiệp / Các bên liên quan

Đó là những nhóm bên ngoài nhóm Scrum nhưng họ vẫn đóng vai trò quan trọng trong khuôn khổ SAFe trong mọi giai đoạn thực hiện.

Trước khi lập kế hoạch PI:

• Cung cấp đầu vào cho các hoạt động sàng lọc tồn đọng.
• Tham gia Lập kế hoạch Pre-PI khi cần thiết.
• Đảm bảo rằng các mục tiêu kinh doanh được các bên liên quan chính của chương trình đào tạo hiểu và đồng ý, bao gồm Kỹ sư tàu phát hành (RTE), Quản lý sản phẩm và Kiến trúc sư hệ thống.

Trong quá trình lập kế hoạch PI:

• Cung cấp bối cảnh kinh doanh và tầm nhìn cho PI sắp tới.
• Tham gia Đánh giá Kế hoạch Dự thảo và chỉ định giá trị kinh doanh cho các Mục tiêu PI của nhóm.
• Tham gia vào Đánh giá của Ban quản lý và giúp giải quyết các vấn đề dẫn đến việc chấp nhận Kế hoạch cuối cùng.

Sau khi lập kế hoạch PI:

• Tích cực tham gia vào việc duy trì sự liên kết kinh doanh và phát triển khi các ưu tiên và phạm vi chắc chắn sẽ thay đổi.
• Giúp xác thực định nghĩa về Sản phẩm khả thi tối thiểu (MVP) cho Chương trình sử thi và hướng dẫn quyết định xoay trục hay kiên trì dựa trên việc phân phối MVP.
• Tham dự buổi Demo hệ thống để xem tiến trình và đưa ra phản hồi.
• Tham dự các sự kiện Lập kế hoạch Sprint và Hồi tưởng Sprint của nhóm Agile, theo yêu cầu.
• Tham gia Quản lý phát hành, tập trung vào phạm vi, chất lượng, các tùy chọn triển khai, phát hành và cân nhắc thị trường.

#5. Kỹ sư đào tạo phát hành (RTE)

RTE tổ chức các hoạt động của mọi người và các nhóm trong ART. Đây là vai trò của Scrum Master trong toàn bộ chương trình. Sau đây là các trách nhiệm chính:

• Quản lý và tối ưu hóa dòng giá trị thông qua ART.
• Thiết lập và truyền đạt lịch hàng năm cho Sprint và Phần tăng trưởng chương trình (PI).
• Hãy là người điều hành các cuộc họp lập kế hoạch PI.
• Tổ chức các nhóm và giúp họ tạo bản tóm tắt về Mục tiêu PI đã xác định của họ. Chuyển mục tiêu của các nhóm thành mục tiêu tổng thể của Kế hoạch PI.
• Tập hợp các nhóm để giao tiếp và giải quyết các rủi ro cũng như sự phụ thuộc lẫn nhau.
• Kết nối Quản lý sản phẩm, Chủ sở hữu sản phẩm và các bên liên quan bên ngoài khác với nhau để gắn kết các bên về chiến lược chung của họ.
• Tổ chức các hội thảo Kiểm tra và Thích ứng với mục tiêu liên tục cải tiến các quy trình và hoạt động hiện có.
• Đánh giá mức độ hoàn thiện hiện tại của việc áp dụng phương pháp linh hoạt giữa các nhóm và xác định các mục hành động tiếp theo để cải thiện các nhóm trong tương lai.

#6. Khả năng lãnh đạo

Lãnh đạo xác định chiến lược cho chương trình và cung cấp cho các nhóm tất cả các công cụ và sự hỗ trợ cần thiết để họ có thể thực hiện công việc của mình. Cuối cùng, họ xác định hệ thống nơi tất cả những thứ còn lại hoạt động. Đó là lý do tại sao việc có một đội ngũ quản lý có thể mang lại cho nhóm mục đích và định nghĩa giá trị đúng đắn là rất quan trọng. Trách nhiệm chính của họ là như sau:

• Dẫn bằng ví dụ.
• Áp dụng tư duy phát triển.
• Làm nổi bật các giá trị và nguyên tắc của SAFe.
• Phát triển con người.
• Dẫn dắt sự thay đổi.
• Thúc đẩy sự an toàn về mặt tâm lý.

Lập kế hoạch tăng cường chương trình (PI)

Lập kế hoạch PI là một sự kiện kéo dài từ hai đến ba ngày với mục tiêu là tìm hiểu và cam kết thực hiện công việc cho giai đoạn tiếp theo của chương trình. Ví dụ: đây có thể là khoảng thời gian của quý tiếp theo.

Quản lý sản phẩm sở hữu mức độ ưu tiên của các tính năng được xác định trong quá trình lập kế hoạch PI. Các nhóm linh hoạt lập kế hoạch năng lực, sáng tạo câu chuyện, ước tính và cam kết với các mục tiêu PI.

Lập kế hoạch PI là điều cần thiết đối với SAFe. Nếu bạn không lập kế hoạch PI, điều đó về cơ bản có nghĩa là bạn không thực hiện SAFe.

Quy trình PI

Nguồn: http://scaledagileframework.com

Lập kế hoạch PI bắt đầu với một số đầu vào trên bàn. Mỗi quy trình làm việc sẽ thu thập nhu cầu và ý tưởng của họ về những gì họ muốn xây dựng tiếp theo cho sản phẩm của mình. Sau đó, họ mang nó đến PI làm đầu vào:

• 10 tính năng hàng đầu cần triển khai tiếp theo,
• ART Backlog của các sử thi hoặc tính năng đã sẵn sàng để xây dựng,
• Tầm nhìn của Chủ sở hữu sản phẩm.

Cuộc thảo luận bắt đầu giữa các luồng công việc khác nhau. Mỗi người trong số họ trình bày tầm nhìn và tính năng của họ. Họ nêu bật những gì quan trọng cần thực hiện tiếp theo và những gì họ cần để thành công khi thực hiện điều đó. Điều này có thể có nghĩa là một số điều khác nhau:

• Sự hỗ trợ được cung cấp bởi các luồng công việc khác để cho phép chúng tiếp tục với các tính năng.
• Sự phụ thuộc vào các luồng công việc khác và sự cần thiết phải ưu tiên đặt hàng.
• Các vấn đề hiện tại đang tồn tại trong hệ thống và cần được khắc phục trước để tiếp tục.
• Những thách thức về nhân sự cho nhóm. Có thể một số vai trò chính trong nhóm vẫn còn thiếu để triển khai nội dung mà các tính năng yêu cầu.
• Những hạn chế về ngân sách ngăn cản luồng công việc của bạn thực hiện tầm nhìn trong dòng thời gian nhất định.
• Bất kỳ rủi ro, vấn đề, giả định hoặc sự phụ thuộc nào khác mà nhóm có thể nhận ra và cần phải thảo luận rộng rãi hơn giữa các nhóm SAFe còn lại để hướng tới mục tiêu chung.

Hướng dẫn PI

Bản thân việc lập kế hoạch PI thường được chia thành nhiều ngày, thường là từ hai đến ba ngày, trong đó chương trình nghị sự có thể như sau:

1 ngày

• Thảo luận về tuyên bố của doanh nghiệp và các mục tiêu chính sắp tới hình thành nên tầm nhìn và chiến lược chương trình tổng thể. Lãnh đạo làm chủ phần này và truyền đạt rõ ràng cho nhóm.
• Đặt tất cả các tính năng từ quy trình làm việc lên bàn và ưu tiên chúng phù hợp với tầm nhìn chung.
• Bước vào tầm nhìn Kiến trúc và xác định các mục tiêu chính của các yêu cầu phát triển. Nêu bật những thách thức kỹ thuật và thống nhất giải quyết những trở ngại giữa các nhóm.

Ngày 2

• Giải thích chi tiết quá trình lập kế hoạch cho các nhóm. Phác thảo các kết quả mong đợi sau khi đóng PI.
• Thực hiện Đột phá nhóm lần đầu tiên trong quá trình lập kế hoạch. Mục tiêu của nhóm là tạo ra các kế hoạch dự thảo và xác định các trở ngại cũng như rủi ro.
• Sau khi phần chia nhóm kết thúc, các đội sẽ trình bày và xem xét các phương án dự thảo mà mình đã lập trước các đội khác.
• Bước tiếp theo dành cho ban quản lý, nơi họ xem xét các kế hoạch và đưa ra phương hướng cho các sáng kiến ​​giải quyết vấn đề tiếp theo. Việc điều chỉnh kế hoạch được thực hiện dựa trên những thách thức, rủi ro và trở ngại.

Ngày 3

• Bắt đầu ngày mới với những điều chỉnh kế hoạch phù hợp với cuộc họp quản lý ngày hôm trước.
• Các nhóm sẽ phát triển Kế hoạch cuối cùng và sàng lọc các Rủi ro và Trở ngại. Chủ doanh nghiệp sẽ chỉ định giá trị kinh doanh cho các mục tiêu của nhóm.
• Tiếp theo, các đội sẽ trình bày phương án cuối cùng trước toàn thể khán giả.
• Các rủi ro cấp chương trình còn lại sẽ được thảo luận và thông tin rủi ro ROAM (đã giải quyết, sở hữu, chấp nhận, giảm nhẹ) được áp dụng.
• Các đội bỏ phiếu cho sự tin tưởng của họ vào kết quả lập kế hoạch tăng dần chương trình.
• Nếu số phiếu bầu quá thấp hoặc niềm tin tổng thể vẫn còn thấp, việc lập kế hoạch bổ sung sẽ được thực hiện.
• Sau Cam kết PI, RTE lập kế hoạch hồi tưởng để các đội thảo luận về tiến trình lập kế hoạch và những điều cần cải thiện cho vòng tiếp theo. Lãnh đạo nêu rõ điều gì sẽ xảy ra trong tương lai cùng với những chỉ dẫn cuối cùng.

Kết quả PI

Kết quả cuối cùng của việc lập kế hoạch PI là danh sách các tính năng được lên kế hoạch hoàn thành theo các lần chạy nước rút trong giai đoạn PI tiếp theo. Tất cả các phần phụ thuộc đã biết đều có kế hoạch chính xác về cách giải quyết và bỏ chặn tiến trình cho các tính năng.

Các nhóm sẽ cam kết thực hiện mục tiêu và phạm vi của mình. Nếu có những mục tiêu bổ sung không nhất thiết nằm trong danh sách, hãy coi chúng như những mục tiêu không được cam kết. Những vấn đề đó vẫn có thể được giải quyết nếu thời gian và nguồn lực cho phép.

Các nhóm sẽ ghi lại và theo dõi tất cả các rủi ro của chương trình và sẽ có kế hoạch chính xác về cách giải quyết chúng.

Các nhóm cũng sẽ nắm bắt mọi ý tưởng hồi cứu mà họ đưa ra trong cuộc họp hồi cứu và đánh dấu chúng là bài học kinh nghiệm cho phiên lập kế hoạch PI tiếp theo.

Riêng đối với các đội, có rất ít kỳ vọng cụ thể, chẳng hạn như:

• Các nhóm cam kết thực hiện các mục tiêu bằng các giá trị kinh doanh.
• Các đội sẽ tính toán công suất trên mỗi sprint để có thể ước tính tốt hơn tính khả thi của nội dung lộ trình.
• Họ cũng xem xét tải thực tế cho mỗi lần chạy nước rút.
• Các câu chuyện được đưa đến các giai đoạn nước rút cụ thể của từng quy trình làm việc dựa trên năng lực được cung cấp.
• Các nhóm bỏ phiếu tin tưởng vào kế hoạch và nội dung PI sẽ cung cấp.

Phần kết luận

Điều này không cần phải quá rõ ràng, ngay cả sau khi đọc tất cả thông tin ở trên, nhưng tôi có thể nói với bạn rằng việc chuyển đổi một tổ chức lớn thành SAFe là một nhiệm vụ cực kỳ khó khăn. Vâng, trong một số trường hợp, nó có thể giống như một nhiệm vụ bất khả thi. Mặc dù một số nguyên tắc cơ bản đó đã được áp dụng, nhưng thường phải mất nhiều lần lặp lại để chuyển sang trạng thái mà bạn có thể nói rằng mình hiện đang AN TOÀN một cách an toàn :).

Rất thường xuyên, sự tiến bộ đang phá hủy một số nguyên tắc và quy tắc phân cấp kiểu cũ, những nguyên tắc và quy tắc này sẽ không biến mất cho dù bạn có cố gắng thế nào đi chăng nữa. Bạn có thể lập kế hoạch PI mở rộng và kết quả thuộc loại nào đó mà bạn thậm chí có thể nêu tên một cách đáng tin cậy. Nhưng điều đó thực sự có ý nghĩa gì nếu các nhóm làm việc không hoạt động theo phương pháp linh hoạt phù hợp?

Tôi chỉ có thể nói rằng ở đây không có chỗ cho con lai. Bạn đang ở trong – với tất cả các quy trình, con người và tư duy phù hợp, hoặc bạn sẽ ở ngoài nếu ít nhất một trong các khía cạnh phương pháp luận không thực sự được đáp ứng.

Đương nhiên, trước khi bạn xem xét việc triển khai SAFe, chỉ cần nói rõ rằng bạn đã nắm vững các nguyên tắc và cách làm việc của nhóm Agile. Không chỉ ở góc độ lãnh đạo mà hãy để các đội biểu quyết và bày tỏ ý kiến ​​trung thực của mình. Bạn có thể ngạc nhiên bởi kết quả.

Tiếp theo, hãy xem các tài nguyên học tập tốt để có được chứng chỉ linh hoạt.

Bài viết này hữu ích không?

Cảm ơn phản hôi của bạn!