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.
<Một lát cắt Agile> Các phương pháp dưới nhãn hiệu Agile nổi tiếng như XP, Scrum xuất hiện chính thức xung quanh mốc 1995. Mặc dù trước đó từ rất lâu đã có những nhóm làm phần mềm hao hao như các phương pháp này mô tả. Nhưng cứ tính từ lúc chính quy thì lấy tạm 1995. Lúc này người ta còn chưa viết cái nhãn Agile lên các phương pháp này, bởi vì nó chưa có.
Suốt thời kì từ 95 tới hết những năm 90 là giai đoạn cãi nhau ỏm tỏi. Phê phán đủ kiểu. Nào là “không học thuật”, “đơn giản chủ nghĩa”, “chỉ dành cho nhóm nhỏ và rất nhỏ, không có nghĩa lí gì”, vân vân. Nhưng các công ty vẫn thấy nó tạo ra kết quả tốt hơn nên cứ tự phát mà dùng, nhất là những ông khởi nghiệp. Chính lực lượng khởi nghiệp với nhu cầu đổi mới cao độ, tốc độ di chuyển chóng mặt mới làm khác đi, dùng cách khác bọn khủng long để mong vượt lên phía trước. 2001, các cha đẻ của những phương pháp có tính chất linh hoạt, ít quy trình nặng nề, có tính thích ứng cao, hỗ trợ tốt cộng tác, hướng đến khách mà sau này gọi chung là Agile ngồi lại và cùng viết ra “The Manifesto for software development”, sau này gọi tắt là Agile Manifesto (Cái kiểu gọi tắt này đã từng bị một trong các cha đẻ của manifesto phê bình, nhưng ai mà cấm được thiên hạ thích gọi tắt :-). Bây giờ người ta vẫn tiếp tục gọi tắt như thế). Nhãn hiệu Agile chính thức ra đời. Sau đó là phường hội ra đời, nào là Agile Alliance, rồi Scrum Alliance. Rồi hàng loạt hội thảo quy mô từ nghìn người đến chục nghìn người cũng ra đời Agile Conference, Scrum Gathering…. Scrum, Agile loang ra như một đại dịch.
Sách của Jeff Sutherland có ghi vào 2007, Microsoft bắt đầu đưa Scrum vào để đổi cách làm việc thuộc khuôn khổ dự án Visual Studio Online để hòng gia tăng tốc độ chuyển giao sản phẩm ra thị trường. Rồi từ chỗ thí điểm thành ra quy trình chính thức (khi quyết định mở rộng phạm vi áp dụng vào 2011), rồi thành quy trình chủ đạo. Theo báo cáo của Steve Denning vào năm 2015, thì quá trình chuyển đổi này có thể tính là đã hoàn tất vào năm 2014. Khoảng 4000 lập trình viên của microsoft được biên chế trong các nhóm nhỏ tầm 12,13 người, làm việc trong các cuh trình ngắn 3 tuần để liên tục chuyển giao sản phẩm có chất lượng tới khách hàng. Nếu trước kia Microsoft có thể mất vài năm để cho ra một phiên bản sản phẩm mới, thì nay thời gian đó rút ngắn xuống còn vài tháng, chất lượng thì khác hẳn. Vào khoảng cuối những năm 2000, nhiều người nhận rõ sự khác biệt về chất lượng phần mềm của MS viết ra so với các đối thủ chính của nó. Ngày nay thì ít còn thấy những so sánh kiểu như vậy nữa. Có thể nói, đế chế phần mềm số 1, con khủng long lớn nhất đã học cách khiêu vũ trong gần 1 thập kỉ. Trước MS vài bước, Google, Amazon, Yahoo!(lúc đó còn hùng mạnh), rồi cậu trẻ Facebook.. đều đã Agile xong xuôi rồi và đang tính những cái khác rồi.
Thập kỉ 2000s có thể được coi là thập kỉ Agile dậy thì thành công. Đến nay, ở các nơi tiên tiến (trừ Nhật, bây giờ người ta cũng đặt câu hỏi về tính tiên tiến của nước Nhật rồi, ít nhất là trong khu vực đổi mới sáng tạo), Agile đã mainstream. Và các vùng trũng cũng bắt đầu vận dụng Agile ở diện rộng. Không chỉ trong phạm vi thực hành ở các công ty, mà còn xuất hiện như đề tài nghiên cứu khoa học, và sinh viên thì được dạy từ lúc còn trên ghế nhà trường (thậm chí đã loang xuống các dự án học tập ở cấp 2).
Ngay ở Việt Nam, trong vòng gần 1 thập kỉ “làm Agile” của tôi, cũng phản ánh một cái hình ảnh hao hao như kể trên, ở quy mô hẹp hơn. Được du nhập hơi muộn, Agile ở VN chỉ được “tiếp nhận” bài bản và chính quy chỉ từ đầu những năm 2010s. Và cũng từ chỗ cãi nhau xem nó có đúng hay không, đến nó hay chỗ nào dở chỗ nào, liệu có đúng ở VN không, đến chỗ mạnh dạn làm thử (và có nhiều ca thất bại), và mạnh dạn thuê dịch vụ tư vấn huấn luyện để làm cho bằng được. Từ vài chục doanh nghiệp có một chút hiểu biết và vận dụng Agile, đến nay thì Việt Nam đã có hàng trăm (và có thể là hàng nghìn, do tôi không có con số chính xác) doanh nghiệp chủ động vận dụng Agile. Nhiều doanh nghiệp thì đã mạnh dạn đẩy sang mức độ enterprise giống như cách Microsoft chuyển mình như kể trên. Ngày nay nhiều trường ĐH ở VN cũng bắt đầu có nhắc đến Agile. Một số nơi thì đã bài bản lắm. Nhưng nhìn chung thì cũng dường như mới bắt đầu thôi. Học viện Agile ra đời cách đây hơn 2 năm, nhưng giờ làm không hết việc. Có lẽ là một một dấu hiệu của bước chuyển từ giai đoạn “tinh hoa” sang giai đoạn “phổ cập” chăng? Như thế cũng đã hơn chục năm để một nhãn hiệu đi vào đời sống.
Hình như không có lối tắt cho đổi mới căn bản và toàn diện. Nhất là khi nó đụng phải những hệ thống có tính quan liêu rất cao độ.
Còn nhớ cũng mới chỉ cách đây có hai năm thôi, khi đến thăm doanh nghiệp để học hỏi, một chủ doanh nghiệp rất trẻ và tài năng (cựu sinh viên đi về từ đất nước mặt trời mọc) rất hồn nhiên nói với tôi “em rất ghét bọn Agile”, vì bọn nó hay khen vống lên, nghĩ là “Agile giải quyết đợc mọi vấn đề”, chả khác gì cuồng tín. Tôi nói lại “đấy là do chứ chưa gặp anh thôi. Anh cũng là một trong bọn Agile đấy”. Thế rồi cùng nói chuyện. Cuộc gặp gỡ ấy kết thúc trong hoan hỉ và thân ái. Chủ doanh nghiệp khách sáo tiễn đưa tôi ra cầu thang và nói “em đã đổi cái nhìn về Agile, không còn ghét nữa rồi”. Chả biết sau này những người anh em thiện lành ấy có tiến lên Agile tí nào không. Cùng thời điểm ấy, Phó tổng giám đốc FSOFT, Mr. Khắc đẹp trai và thư sinh đã khẳng định trên VTV2 “fsoft chủ yếu làm Agile rồi, vì khách hàng yêu cầu như thế”. Có lẽ hiện nay đế chế FSOFT là nơi giữ nhiều chứng chỉ quốc tế về Agile nhất VN. Trong cùng một thành phố phù hoa Paris xứ Đông Lào này, vẫn tồn tại nhiều hơn 2 thế hệ “hệ điều hành quản trị”, giống như trên thế giới này tồn tại những “văn minh” khác nhau. Tương tự như vẫn tồn tại một nước Mỹ tốc độ có một nhà nước hiện đại, và một vùng đâu đó ở New Guinea vẫn còn chủ yếu sống theo kiểu thị tộc hết sức sơ khai. Hình như chúng vẫn chung sống hòa bình.
Trong khóa học Agile Management do Học viện Agile tổ chức, tôi thường gợi ý một số cuốn sách tốt để làm chất liệu cho tư duy và thực hành quản lí.
Danh sách dưới đây là tổng hợp danh mục những cuốn sách tốt dành cho nhà quản lí nhâm nhi mỗi ngày, có thể đủ cho ít nhất 1 năm đọc và học nghiêm túc.
Thứ tự không phản ánh một ưu tiên nào, chỉ là đánh số cho dễ tra cứu. Với một số cuốn sách, tôi có một bài điểm ngắn. Bạn đọc có thể theo đường dẫn để đọc thêm. Hãy dùng Google nếu bạn muốn biết nơi nào bán những cuốn sách này.
Tôi ưu tiên những sách của các tác giả quan trọng, những thought leader trên thế giới, những cuốn sách chứa nhiều thông tin khoa học hơn là sách hướng dẫn kiểu gạch đầu dòng (mặc dù cũng có ngoại lệ). Tôi ưu tiên sách đã được xuất bản bằng tiếng Việt, nhưng cũng để vài cuốn chưa được dịch, biết đâu có ai đọc được lại nảy sinh lòng ham muốn dịch nó ra :-).
Chúng ta là những con người phàm tục với kiến thức hạn chế và ý chí độc lập.
Môi trường kinh doanh là không thể đoán trước và không chắc chắn, vì vậy chúng ta nên mong đợi điều bất ngờ và không nên lập kế hoạch vượt quá hoàn cảnh mà chúng ta có thể thấy trước.
Trong phạm vi hạn chế của kiến thức hạn hẹp của mình, chúng ta nên cố gắng xác định những yếu tố căn bản của một tình huống và lựa chọn những gì cần thiết nhất để đạt được.
Để cho phép mọi người hành động có hiệu quả, chúng ta phải đảm bảo họ hiểu họ sẽ đạt được điều gì và tại sao lại phải như vậy.
Sau đó họ nên giải thích những gì họ sẽ làm như là một kết quả, xác định các nhiệm vụ cần thiết, và kiểm tra lại với chúng ta.
Sau đó họ sẽ phân công nhiệm vụ đã xác định cho những cá nhân có trách nhiệm đạt được chúng và chỉ định ranh giới trong đó họ được tự do hành động.
Mọi người đều phải có kỹ năng và nguồn lực để làm những gì cần thiết và một không gian để có những quyết định và hành động độc lập khi sự kiện bất ngờ xảy ra, như nó sẽ xảy ra.
Khi tình hình thay đổi, mọi người nên được dự kiến sẽ điều chỉnh hành động của mình theo sự đánh giá tốt nhất của họ để đạt được kết quả mong muốn.
Mọi người sẽ chỉ cho thấy mức độ yêu cầu bắt buộc nếu họ tin rằng tổ chức sẽ hỗ trợ họ.
Cái gì không được làm cho thành ra đơn giản thì không thể nói rõ ràng được, và những gì không rõ ràng thì sẽ không được thực hiện.
<Siêu tóm tắt từ The art of action, Stephen Bungay>
Mấy vị lập trình viên phần mềm dùng Agile Software Development để làm ra phần mềm thay đổi thế giới. Việc này nhiều người đã biết. Kể từ 2001 với bản Tuyên ngôn Agile ra đời, Agile đã trở thành lối làm việc mới ưa thích của dân phần mềm. Nhưng Agile đã không chịu dừng ở đó.
Người Việt thường không được đánh giá cao về khả năng làm việc nhóm. Trong khi đó, việc khởi nghiệp lại đòi hỏi các thành viên của nhóm phải cộng tác ở trình độ cao suốt một thời gian dài và liên tục.
Các nhóm khởi nghiệp cần nhìn nhận đúng những rủi ro tiềm tàng của rào cản có tính văn hóa và kĩ năng này, để xây dựng cho mình một nền tảng làm việc nhóm vững chắc. Từ thực tiễn của các nhóm startup trên khắp thế giới, chúng ta có thể thu được nhiều gợi ý quý báu. Dưới đây là bốn trong số các bài học quan trọng bậc nhất.
Về cơ bản, khởi nghiệp sáng tạo là một cuộc chơi có tính đồng đội rất cao. Để tìm kiếm những giải pháp đột phá, sáng tạo, các cá nhân với những năng lực đa dạng, nhiều góc nhìn cần phối hợp nhịp nhàng trong một cách thức tổ chức tối ưu.
Nhiều chuyên gia cho rằng người khởi nghiệp (hiểu theo nghĩa ‘khởi nghiệp sáng tạo’ có yếu tố mới – startup, chứ không phải là mở một doanh nghiệp nhỏ để đáp ứng một nhu cầu đã rất sẵn) không nên học MBA. Điều này có phần đúng.
Vừa trở về từ chuyến đi nhớ đời ở Thái Lan, tôi phi ngay vào Đà Nẵng để được chứng kiến Mr. Đới truyền đạo Agile cho các lãnh đạo của các Sở ban ngành của thành phố đáng sống bậc nhất Việt Nam.
Bạn được nói là sẽ đi làm 8 tiếng 1 ngày, năm sáu ngày mỗi tuần. Nhưng thực ra thì con số 8 đấy cũng cực kì tương đối và co giãn.
Theo cách làm Pomodoro (được giả sử là tập trung nhất về mặt thời gian làm việc năng suất), bạn chỉ thực sự làm việc khoảng 80% thời gian đó. Như vậy thực chất là bạn bỏ ra khoảng sáu tiếng rưỡi, còn lại là thời gian “rảnh”. Thực ra, thời gian rảnh đó thường dài hơn nhiều so với con số lí thuyết 1.5h. Sự việc này có ít nhất hai ý nghĩa.
Thứ nhất là bạn đừng bao giờ lên kế hoạch cho 8 tiếng làm việc mà là 6h làm việc mỗi ngày, nếu bạn sử dụng khung thời gian 8 giờ công sở sao cho vừa khít. Lên kế hoạch và cam kết với 8 tiếng có thể là một điều nguy hiểm, vì bình thường bạn không có khả năng hoàn thành một khối lượng công việc lớn hơn 25% với chất lượng tương đương. Bạn sẽ phải làm thêm giờ, hoặc là hy sinh chất lượng, hoặc sẽ lâm vào tình trạng stress.
