Ngày nay thế giới biến động, công nghệ phát triển nhanh, khiến các công ty lúc nào cũng bị đặt vào tình thế bị biến từ vị trí số 1 trong ngành thành bóng ma của quá khứ. Hãy nhìn tấm gương Nokia mobile, Motorola mobile, và hàng loạt tên tuổi lớn khác.

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ả.