2014/12/10

A case study on applying Scaled Agile Framework (SAFe)

Tóm tắt:
Bài viết này tóm tắt một số ý quan trọng khi triển khai Scaled Agile Framework (SAFe) ở mức team, dự án, program (chương trình) và tổ chức (company level)

Bối cảnh:
Áp dụng trong một công ty cỡ trung bình,
tổng số nhân viên vài ngàn người,
tổng số nhân sự IT (phát triển, testers, quản trị dự án...) là vài trăm,
với nhiều tiểu dự án, dịch vụ (online) chạy song song.

Mô hình quyền quyết định và budgeting là top-down.
Hệ quả là, tư duy top-down ngay cả trong cách chạy dự án IT cũng là top-down và rất waterfall.

Thách thức:
Áp dụng mô hình Agile vào tổ chức này như thế nào để làm "đẹp lòng" lãnh đạo (cao cấp) trong khi các dự án IT vẫn chạy tốt?

Cách tiếp cận:
- Agile tới từng team, dự án, chương trình, mục tiêu (portfolio) và tổ chức,
- Áp dụng những Agile toolkit cơ bản, có lộ trình,
- Việc áp dụng Agile toolkit ở mức team (5-10 người) được phó mặc cho Project lead, scrum master.

Lựa chọn scaled Agile framework:
Tôi chọn SAFe thì mô hình này vẽ đẹp, trực quan, dễ dàng dùng hình để thuyết phục lãnh đạo.
Iteration là một Agile practice được mô tả đơn giản, chia theo các mức lãnh đạo, phòng ban trong tổ chức có thể dễ dàng áp dụng.
SAFe tập trung vào quy trình, thích hợp hơn ở mức tổ chức

Tôi có tìm hiểu qua các scaled Agile framework sau nhưng không chọn:
  1. RAP (Real Agility Program)
  2. DAD (Disciplined Agile Delivery)
  3. LeSS (Large Scale Scrum)

Lộ trình tiếp cận và áp dụng SAFe:e

  1. Áp dụng Agile toolkits cho các nhóm phát triển. Đối tượng áp dụng là scrum master, tester, developers...
  2. Áp dụng Agile toolkits cho các dự án, mục tiêu lớn. Đối tượng áp dụng là lãnh đạo ở mức trưởng phòng, product manager,
  3. Áp dụng Agile toolkits ở mức C-level (CEO, CFO, CTO...). Điều quan trọng là thay đổi mindset, chuyển đổi nó từ tư duy truyền thống sang tư duy Agile.

Trong đó, việc budgeting, được quyết định chính bởi CEO, CFO là tối quan trọng. CEO và CFO là những người khó thay đổi nhất.

Một số nhận định chung về SAFe:

  1. Áp dụng ở mức tổ chức, chứ không phải chỉ cho một team nhỏ dưới 10 người,
  2. Thích hợp với tổ chức có nhiều phòng ban, tổ chức, dự án, chương trình chạy song song,
  3. Q: SAFe có thực sự là Agile không? A: SAFe là Agile ở mức team và cũng là Agile ở mức program, tổ chức dù điều này hơi khó nhìn,
  4. Q: SAFe liên quan gì tới Scrum? Scrum là một Agile toolkit. SAFe là một mô hình Scaled Agile. Do đó, việc so sánh SAFe và Scrum là khập khiễng. Trong mô hình SAFe, ở mức team, hoàn toàn có thể áp dụng Scrum như một toolkit hoặc nhiều toolkit khác,
  5. Q: Vì sao ít người (nổi tiếng) ủng hộ SAFe? A: Vì họ thường chỉ làm dự án ở quy mô nhỏ, trong khi SAFe áp dụng ở quy mô lớn (hơn),
  6. Q: SAFe có phải là chiến lược không? A: Đúng, nó là một chiến lược, cách tiếp cận đúng để thay đổi tư duy cổ điển của lãnh đạo sang Agile,
  7. Q: SAFe có định nghĩ rõ độ dài của sprint không? A: Không. Độ dài sprint hoàn toàn tùy thuộc vào tình hình thực tế. Với mức team < 10 người, độ dài sprint có thể là 4 tuần, 1 tuần hay thậm chí một vài ngày. Với C-level, "sprint" là 1, 3 hay 6 tháng và có sự điều chỉnh (retrospect:ve) khi cần thiết.

Một số Agile toolkit:

# (mà tôi) khuyến nghị sử dụng ở mức độ công ty, cho các vị trí khác nhau.

  1. Agile for project managers
  2. Agile portfolio management
  3. Scaled Agile Framework
  4. User Stories
  5. Agile Kanban
  6. Iteration Planning
  7. Definition of Done
  8. Agile Quality
  9. Agile Planning
  10. Agile for Executives
  11. Scrum
  12. Planning poker
  13. XP (eXtreme Programming) (use with care :D)
  14. Kanban
  15. TDD (Test-Driven Development)
  16. CI (Continuous Integration)
  17. CTDD (Continuous Test Driven Development)

Topics khác:

(liên quan tới việc triển khai SAFe, hay scaled Agile frameowork nào đó)

  1. Hiring (đúng người đúng việc)
  2. Performance evaluation (đánh giá, đây là việc cần làm trong tổ chức (lớn)
  3. Communications (thông luồng liên lạc, không quá quan liêu, không quá thưa)
  4. Reporting (Hơi đi ngược lại với nguyên tắc Agile. Báo cáo là cần, dù ngắn, không để "báo cáo" trở thành gánh nặng)
  5. Organization structure (Định nghĩa lại sơ đồ tổ chức khi áp dụng SAFe, cùng với RaR)
  6. Project structure (cơ cấu tổ chức ở mức dự án)
  7. Training (Đào tạo tư duy Agile, từ lãnh đạo tới nhân viên)
  8. Authority (Chơ chế quyền quyết định thay đổi khi áp dụng Agile)
  9. RaR (Roles and Responsibilities) definition
  10. Skillset (Năng lực cần và đủ của các vị trí thay đổi khi áp dụng Agile)
  11. Governace (Không có thì móm à)

Tham khảo:

  1. unSAFe at any speed http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/
  2. The Horror Of The Scaled Agile Framework http://neilkillick.com/2012/03/21/the-horror-of-the-scaled-agile-framework/
  3. Large-Scale Agile Design & Architecture: Ways of Working http://www.infoq.com/articles/large-scale-agile-design-and-architecture





--
Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン ヒュン ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.

0 件のコメント: