Một người phát triển phần mềm đã viết cho tôi: “Vài tháng trước đây, tôi tham dự xê mi na đào tạo Agile và đã học về phương pháp Scrum. Tôi đã cố gắng làm cho công ti của tôi dùng Scrum nhưng phần lớn mọi người đều bỏ qua lời khuyên của tôi. Nhà tư vấn Agile cho tôi một danh sách các ích lợi của Agile để đưa cho người chủ công ti và thậm chí còn sẵn lòng gặp ông ấy để thảo luận thêm nhưng ông ấy cũng đã từ chối. Làm sao tôi có thể làm cho Agile làm việc trong công ti của tôi? Làm sao tôi có thể giúp cho nhà tư vấn làm cho Agile vào công ti của tôi? Xin thầy lời khuyên.”

Đáp: Bạn KHÔNG phải là người chủ công ti. Bạn thậm chí KHÔNG là người quản lí cấp cao của công ti. Bạn KHÔNG nói được người chủ và người quản lí dùng phương pháp nào và ích lợi nào nó có thể đem lại cho công ti, như được nhà tư vấn Agile gợi ý. Agile là phương pháp rất tốt với MỘT SỐ dự án nhưng không phải là TẤT CẢ. Có những phương pháp khác cho các kiểu phát triển phần mềm khác nhau và ai đó phải quyết định phương pháp nào là phương pháp đúng cho công ti, và người đó KHÔNG phải là bạn. Cho dù bạn đã được thuyết phục rằng Agile là phương pháp đúng nhưng người quản lí của bạn và người chủ công ti phải được thuyết phục. Họ có thể biết cái gì đó về Agile mà bạn có thể không biết. Vai trò của bạn KHÔNG phải là chủ trương cái gì đó mà nhà tư vấn có thể đã gợi ý cho bạn.

Có những lí do mà mọi người không thích Agile. Thứ nhất, nhiều người không thích thay đổi, bất kể kiểu thay đổi hay ích lợi nào. Thứ hai, những người quản lí, đặc biệt người quản lí dự án, có thể không thích Agile vì họ sợ mất kiểm soát. Như bạn có lẽ biết rằng trong Scrum, không có vai trò cho người quản lí dự án; và một số người quản lí dự án không thích điều đó. Vài năm trước, một người quản lí bảo tôi rằng nếu người đó chủ trương cái gì đó mới và nếu nó không diễn ra tốt, người đó có thể mất việc cho nên người đó giữ im lặng và đó là thái độ chung trong những người quản lí. Như bạn đọc về Agile, họ có thể cảm thấy không thoải mái về tổ tự quản mà không có người quản lí, điều có nghĩa là một số người trong họ có thể không có việc làm. Nỗi sợ mất kiểm soát hay tạo ra hỗn độn làm cho họ bỏ qua điều đó thay vì chấp nhận nó.

Vấn đề khác với Agile là nó giả định rằng phần lớn những người phát triển đều có kĩ năng, có kỉ luật, sẵn lòng tự quản và sẵn lòng học những điều mới. Sự kiện là trong mọi công ti, bạn sẽ thấy mọi người với những kĩ năng khác nhau, mục đích khác nhau, và thái độ khác nhau hướng tới việc học. Nhiều người ưa thích làm việc tám giờ rồi về nhà mà không lo nghĩ mấy. Nếu dự án diễn ra không suôn sẻ, người quản lí phải lo nghĩ về điều đó. Tại sao họ phải lo nghĩ ngoài việc chỉ làm công việc phát triển? Đòi hỏi họ thay đổi khi họ cảm thấy thoải mái là khó vì không có lí do để làm như vậy. Tại sao họ phải học cái gì đó mới khi họ đã có việc làm tốt và làm tốt theo cách truyền thống? Sao họ phải muốn ở trong tổ tự quản với trách nhiệm phụ thêm? Nếu bạn biết tổ chức phải mất bao lâu để tổ chức tổ Scrum mười người thì bạn sẽ biết khó thế nào cho toàn thể công ti chuyển sang tự quản. Không tổ nào có thể được biến đổi sang Agile trong vài tháng mà không có đào tạo thêm. Không ai có thể ép buộc được mọi người tự quản nếu họ không nhận được lệnh từ người chủ công ti và người quản lí. Và sẽ cần nhiều đào tạo, huấn luyện, kèm cặp và ép buộc để làm cho thay đổi được thực hiện.

Mặc cho các bằng chứng về ích lợi của cách tiếp cận Agile, khó mà thực hiện được Agile trong công ti với cấu trúc quản lí trên xuống. Bạn cần người chủ công ti và mọi người quản lí đồng ý và quyết tâm thay đổi và họ phải đầu tư nhiều tiền vào đào tạo để làm cho nó làm việc. (Đây là lí do tại sao nhà tư vấn đang hi vọng vậy.) Lời khuyên của tôi là bạn KHÔNG nên làm điều này cho ông ta.

Theo ý kiến cá nhân, tôi thích cách tiếp cận Agile và đã dùng Scrum trong nhiều dự án thành công. Tôi đã viết nhiều bài báo về Agile trong blog của tôi nhưng lời khuyên của tôi là đừng cố thuyết phục người khác về Agile nếu họ không muốn thay đổi. Nếu bạn thực sự thích Agile, tìm công ti khác đang dùng Scrum và tham gia cùng họ. Bạn sẽ có cơ hội thực hành điều bạn thích và ở trong tổ tự quản cùng với những người như bạn.

—-English version—-

Advice on Agile

A software developer wrote to me: “Few months ago, I attended an Agile training seminar and learned about the Scrum method. I tried to make my company to use Scrum but most people ignored my recommendation. The Agile consultant gave me a list of benefits of Agile to give to the company owner and even willing to meet with him to discuss further but he also refused. How can I make Agile work in my company? How can I help the consultant to get Agile into my company? Please advice.

Answer: You are NOT the owner of the company. You are NOT even a senior manager of the company. You do NOT tell owner and managers what method to use and what benefits it can bring to the company, as suggested by Agile consultant. Agile is a very good method for SOME projects but not ALL. There are different methods for different types of software development and somebody must decide which one is the right method for the company, and that person is NOT you. Even you have been convinced that Agile is the right method but your managers and company owner must be convinced. They may know something about Agile that you may not. It is NOT your role to advocate something that the consultants may have suggested to you.

There are reasons that people do not like Agile. First, many people do not like to change, regardless of what types of change or benefits. Second, managers, especially project managers, may not like Agile because they are afraid of losing control. As you probably know that in Scrum, there is no role for project manager; and some managers do not like that. Few years ago, a manager told me that if he advocates something new and if it does not go well, he may lose his job so he keep quiet and that is the common attitude among managers. As they read about Agile, they may feel uncomfortable about self-organized team without manager which means some of them may not have job. The fear of losing control or create chaos let them to ignore it instead of accept it.

Another issue with Agile is it assumed that most developers are skilled, disciplined, willing to self-organize and willing to learn new things. The fact is in every company, you will find people with different skills, different goals, and different attitudes toward learning. Many prefer to work eight hours then go home without worry much. If the project does not go well, manager has to worry about it. Why should they worry other than just doing development works? By asking them to change when they feel comfortable is difficult since there is no reason to do so. Why should they learn something new when they already have a good job and doing well in the traditional method? Why should they want to be in a self-organized team with additional responsibilities? If you know how long will it take to organize a ten person Scrum team then you will know how difficult to organize the whole company to self-organized. No team can be transformed into Agile self organized team in few months without additional training. No one can force people to self-organize if they do not get the order from company owner and managers. And it would take a lot of training, coaching, mentoring and enforcing to get the change implemented.

Despite evidences about the benefits of Agile approach, it is difficult to implement Agile in a company with top-down management structure. You need the company owner and all managers to agree and commit to the change and they have to invest a lot of money in trainings to make it works. (This is why the consultant is hoping for) My advice is you should NOT do this for him.

Personally, I like Agile approach and have used Scrum in several projects successful. I have written several articles about Agile in my blog but my advice is do not try to convince others about Agile if they do not want to change. If you really like Agile, find another company that is using Scrum and join them. You will have a chance to practice what you like and be in a self-organized team with people like you.