Ken mới xem video “Agile là gì?” của Học viện Agile. Xem xong không hiểu gì bèn lôi Sun ra hỏi.

Ken: Agile có đảm bảo sự thành công không? 
Sun: Không. Xạ thủ Hoàng Xuân Vinh rất giỏi bắn súng, có lúc được huy chương vàng Olympic, lại thất bại ở Asiad tầm thấp hơn. 
Thành công là kết quả mang tính thời điểm, sự chuẩn bị, năng lực, nhất là phong độ và may mắn nữa. Anh Vinh có đỉnh không, sao vẫn hỏng?

Ken: Sao bảo nhóm Agile có tỉ lệ thành công của dự án cao hơn? 
Sun: Thì cao hơn chứ có phải đảm bảo đâu. Thống kê ra con số trung bình, từ đó mà nhìn ra chủ yếu là tương quan, chứ không phải là cứ A thì B. Làm dự án phức tạp lắm, bao nhiêu thứ có thể tác động đến sự thành bại.

Ken: Agile có đảm bảo mình sẽ hơn đối thủ không? 
Sun: Không. Nhỡ đâu đối thủ cũng dùng Agile mà lại giỏi hơn thì sao? Lợi thế cạnh tranh đâu cớ đơn giản thế.

Ken: Thế vì sao tôi phải dùng Agile? 
Sun: Cái đó ông phải tự biết chứ. Agile có giúp ông được gì không? Nếu không giúp được gì thì dùng làm gì, hâm à.

Ken: Nghe đồn cứ làm Agile thì sản phẩm tốt. Có phải không? 
Sun: Phét đấy. Cái đấy phụ thuộc các năng lực làm ra sản phẩm và đảm bảo chất lượng. Agile không phải toàn bộ điều kiện cần duy nhất. Và trong nhiều cách thức để đạt được chất lượng, có thể có cách không cần Agile.

Ken: Nghe đồn nhóm Agile thì không phải làm việc quá giờ, cứ 5 giờ ra về trong vui sướng?
Sun: Phét. Làm việc quá giờ liên quan rất ít đến Agile. Nó liên quan đến các tình huống cụ thể, có lúc cần lúc không, liên quan đến gu của leader và cả sở thích của nhân viên nữa hehe

Ken: Ơ, thế Agile có gì hay nhỉ? 
Sun: Ông xem lại video đi.

Trong khảo sát về hiện trạng sử dụng Agile trên thế giới năm 2011 của VersionOne, bên cạnh các dữ liệu hết sức “có lợi” cho người ủng hộ Agile, có những dữ liệu cực kì đáng nghi ngại cho những người mới chân ướt chân ráo vào lĩnh vực mới mẻ này.

Quan sát bảng dưới đây:

Nhìn vào bảng trên, có một sự thật ẩn sau đó là:

Chỉ 16% số người được hỏi là thành công mĩ mãn với Agile.

Còn lại 84% vấp phải những rắc rối, hoặc sai lầm, hoặc thất bại thảm hại, kể cả khi chuyển sang Agile.

Làm sao để tránh đây?

#1.

Ảnh: IEEE

Đây là một vụ rất ồn ào, tốn giấy mực của báo chí: Dự án Sentinel của FBI

• Mục đích: số hóa các dữ liệu điều tra của FBI, dùng cho 30.000 nhân viên FBI
• Ước tính ban đầu: 451M, hoàn thành và cài đặt vào 2009.
• Đơn vị phát triển: Lockheed Martin.
• Mô hình: waterfall-based.
• Khởi công: 2006

Đến tháng 8-2010, đã chi 405M/451M nhưng mới chỉ đạt được 50% tiến độ; chưa dùng được gì.

Do tốn kém và trì trệ, FBI kết thúc hợp đồng với Lockheed Martin, thay CIO, để lại 50% công việc dang dở.

Công ty kiểm toán độc lập Mitre ước tính FBI cần thêm 35M nữa, cùng với 6 năm nữa để hoàn thành dự án.

Thời điểm đó CTO mới quyết định chuyển dự án sang Scrum, và họ hoàn tất khối lượng công việc với chỉ 30M trong vòng 1 năm, tiết kiệm 90% chi phí.

Nguồn: Ken Schwaber và Jeff Sutherland, “Software in 30 days”.

***

Biên tập viên John Foley của Information Week có bình luận về vụ này (tại đây), và rút ra năm bài học:

1. Chuyên gia ở khu vực tư nhân rất đáng giá

2. Agile rất được việc

3. Các phần mềm thương mại đóng vai trò quan trọng

4. Agile rất tiết kiệm

5. Đừng cài đặt phần mềm mới lên phần cứng đã lạc hậu

tiếp #2

Brian Wernham đã viết một cuốn sách mới về kỹ năng lãnh đạo cho việc thực hiện các dự án quy mô lớn thuộc khu vực công chỉ trong phạm vi vài tháng, chứ không phải mất hằng năm như hiện nay. Đó là cuốn “Quản lý Linh hoạt cho các dự án nhà nước” (Agile Project Management for Government).

Gần đây, Bộ Quốc Phòng Mỹ đã hủy bỏ một dự án quản lí nguồn nhân lực (HR) sau 12 năm nỗ lực. 1 tỷ USD đã tiêu tùng. Tương đương với gần $100 cho mỗi người nộp thuế Mỹ. Thay đổi chuyên gia quản lý, Brian Wernham nghĩ rằng chính phủ nên làm nhiều điều hơn để các dự án công nghệ quy mô lớn có được hiệu quả chi phí tốt hơn thông qua việc sử dụng Agile.

“Quản lý Linh hoạt cho các dự án nhà nước” của Brian Wernham là một nghiên cứu chuyên sâu mới về việc lãnh đạo Agile có thể làm giảm nguy cơ thất bại của các dự án thuộc khu vực công cộng và giảm phần lớn những chi tiêu lãng phí.

Đây là cuốn sách nên đọc của các nhà lãnh đạo trong chính quyền trung ương, liên bang và địa phương cũng như trong khu vực tư nhân. Cuốn sách này cung cấp:

• lý do tại sao nhiều dự án có thay đổi lớn đã thất bại và làm thế nào để đảm bảo bạn không “dính” phải cái dớp đó.

• 9 hành vi Lãnh đạo Linh hoạt mà bạn cần phải biết

• bám sát các quy tắc, đạo luật và các chiến lược của chính phủ Mỹ và Anh

• làm thế nào để thích ứng với phương pháp linh hoạt trong khu vực công

• Các đặc điểm của hai phương pháp linh hoạt phổ biến: SCRUM & DSDM

Bình luận về lý do ông viết cuốn sách này, Brian nói, “Mặc dù có rất nhiều người ủng hộ ý tưởng quản lý linh hoạt ở Mỹ, sự tiếp nhận các ý tưởng này trong khu vực nhà nước là rất chậm chạp. Tôi tin rằng với cách thức linh hoạt hơn và tương tác hơn, quản lý linh hoạt (agile management) có thể mang lại thành công trong lĩnh vực công, nơi rất nhiều dự án thác nước truyền thống (waterfall) tiếp tục phải nhận các thất bại nặng nề”.

Nguồn: Kelly Waters, AllAboutAgile.com.

1. Chơi cho biết, thiệt hại gì

Cách dễ nhất và ít thiệt hại nhất luôn là thử. Cái mất duy nhất thường chỉ có thời gian (ngắn). Nhưng bù lại thì được:

– Biết Scrum là gì?

– Nó chạy như thế nào \ Hỏng như thế nào?

– Mình có dùng được không?

Cách làm: chỉ cần lập ra một đội vài người, rủ nhau đọc Scum Primer, thảo luận một buổi, chọn lấy một bài toán nho nhỏ rồi “chiến” luôn không cần đợi. Để thử thì chỉ cần một vài tuần là quá đủ; có nhóm thậm chí chỉ cần bốn ngày cho một mini-sprint duy nhất trước khi làm thật. Thử xong, ngồi lại và xem xét đã học được gì, trả lời cho các câu hỏi bên trên. Xong.

2. Đánh nhanh thắng nhanh
Nhiều khi có nhóm chỉ có một hai tháng để làm project, không đủ thời gian để đầu tư nhiều cho học tập, đào tạo hay thử nghiệm. Trong trường hợp này, nhóm cần các Quick-wins thay vì chiến lược bài bản. Mục tiêu lớn nhất: hiệu quả hơn.
Có thể làm thế này:

• Đọc nhanh Scrum Primer và thảo luận để hiểu Scrum
• In ra Ba chân của Scrum dán vào nơi làm việc để nhớ cái cốt lõi
• Chọn lấy một trong các thứ hữu dụng để tập trung làm tốt. Ví dụ: thiết kế lấy task board, cộng với daily scrum. Tạm thời quên đi các phần khó của Scrum như Retrospective, Scrum Master, Estimation v.v.
• Tuân thủ nguyên tắc Sprint ngắn, không nhất thiết tuân thủ chặt chẽ quy tắc Potentially Shippable trong một vài Sprint đầu
• Có đánh giá lại thường xuyên những gì đang diễn ra. Hằng ngày, thay vì để cuối Sprint.

3. Một nước hai chế độ

Cái này thì theo sách mà làm: làm một cái factory cho khu vực sản xuất, chọn nhân sự phù hợp Scrum để gửi vào đó. Rồi áp dụng Scrum bài bản: đào tạo, huấn luyện, phân rõ vai vế, môi trường làm việc phù hợp Scrum, triển khai Scrum đầy đủ “theo sách” …
Ngòai khu vực factory, mọi chuyện vẫn diễn ra theo cách bình thường.
Có thể các nhóm khác vẫn làm việc như cũ. Vận hành kiểu một đất nước hai chế độ.

4. Scrum là động lực phát triển

Nếu điều kiện cho phép (đủ quyết tâm, đủ chuyên gia, đủ tiền & lãnh đạo đủ “máu” v.v.) thì có thể bắt trước Saleforce.com để  kéo cả làng làm Scrum.

Cách làm: thành lập một rollout team với đầy đủ thành phần quan trọng: chuyên gia Scrum, lãnh đạo cấp cao, những key person của các đội phát triển; lập chiến lược với mục tiêu rõ ràng cho việc áp dụng đại trà Scrum; xây dựng kế hoạch dài hơi, chi tiết và thực thi hiệu quả cho việc áp dụng Scrum.

Việc này có thể mất hai ba tháng cho chuẩn bị, hai ba tháng “dò đường” và vài năm để trưởng thành thực sự.

5. Văn hóa Scrum ở mọi nơi

Người người dùng Scrum.

Nhà nhà [phát triển, kinh doanh, tiếp thị v.v.] dùng Scrum;

Scrum trở thành “khí” của cả tổ chức; tạo thành cái hồn, thành nếp sống. Khi đó, không cần tới manual nào cả, chẳng cần đến Scrum Guide nào hết; người mới được quẳng vào làm việc là sẽ phải hít thở không khí Scrum, không cần gì thêm.

Cách làm: ???

Bài phỏng vấn Nhân trong series AgileInterview được thực hiện từ đầu tháng, nhưng phải chờ Hương biên dịch và tổng hợp lại, edit cẩn thận mới cho lên khuôn. Hy vọng qua series này người thực hành và người học Scrum, agile sẽ có thêm nhiều dữ kiện quý để suy nghĩ và vận dụng vào thực tiễn công việc của mỗi người.

Ảnh: http://blogs.uct.ac.za/

Có một dữ liệu rất đáng quan tâm về việc Mr. Nhân cùng đồng sự của mình đã thực hiện để có được hiểu biết về “agile là gì”:

“Nhân: Đầu tiên, mỗi sáng tôi đọc to một dòng trong bản tuyên ngôn agile bằng tiếng Anh; hỏi xem họ hiểu thế nào, sau đó đọc lại bằng tiếng Việt. Cứ như thế trong vòng một tuần. Sau đó cũng áp dụng hệt như trên đối với sách “Căn bản Scrum” (Scrum Primer). Đọc và thảo luận khoảng 15 phút cho mỗi buổi sáng trong vòng 2 tháng thì sẽ hiểu về agile.”

Nhiều nơi nói “tôi có biết agile”, “tôi cũng dùng Scrum” có thể sẽ phải giật mình khi đọc cái “tâm sự” trên đây của Nhân. Tại sao họ lại phải mất hai tháng chỉ để hiểu “agile là gì”? Liệu mình có hiểu agile thật không? Liệu bọn mình có agile thật không?

Agile là một quá trình (chính là quá trình chuyển đối – transformation) hơn là một trạng thái hay là một bộ các công cụ (toolbox). Ngay cả khi Nhân có trao đổi với tôi về việc cách tiếp cận của anh thiên về tiếp cận toolbox, thì trong cách làm của anh vẫn chứng tỏ anh đã chủ động transform đội ngũ của mình sang agile chứ không đơn thuần là nhìn vào toolbox agile và “gắp” lấy một cái tool ưa thích để dùng.

Thêm nữa, ngay cả khi có định hướng đúng, chúng ta phải bỏ ra nỗ lực nhiều ngày thì mới có thể gặt hái thành công. Không có việc gì dễ cả.