Một người phát triển phần mềm viết cho tôi: “Chúng tôi đang áp dụng phương pháp Scrum cho dự án phần mềm của chúng tôi nhưng chúng tôi gặp phải nhiều vấn đề. Mặc dầu người quản lí dự án của chúng tôi đã theo lớp đào tạo Agile nhưng anh ấy không thể giải quyết được vấn đề. Chúng tôi nghĩ về chuyển trở lại phương pháp cũ. Xin thầy lời khuyên.”

Đáp: Scrum là phương pháp tuyệt vời cho dự án phần mềm nhỏ. Khác biệt then chốt giữa Scrum và các cách tiếp cận khác là cách tiếp cận đơn giản của nó. Scrum cho phép dự án được thực hiện tăng dần, từng mảnh mỗi lúc. Để làm cho Scrum làm việc, bạn cần có các thành viên tổ có kinh nghiệm bởi vì Scrum yêu cầu tổ tự quản, điều có nghĩa là không có người quản lí dự án hay người lãnh đạo tổ để chỉ đạo tổ nhưng mọi thành viên của tổ đều phải làm việc cùng nhau để làm cho công việc được thực hiện. Vì bạn có người quản lí dự án, dường như là bạn có thể không dùng Scrum đúng đắn. Nếu người đó là người duy nhất có được đào tạo về Agile thì đó là sai lầm. Tôi khuyên là toàn thể tổ ghi danh vào đào tạo Scrum để cho bạn có thể làm mọi thứ đúng đắn.

Có ba vai trò trong dự án Scrum: Người chủ Scrum, Người sở hữu sản phẩm, và các Thành viên tổ. Người chủ Scrum chịu trách nhiệm đảm bảo rằng tổ tuân theo qui trình Scrum. Người sở hữu sản phẩm đại diện cho cách nhìn của khách hàng và hướng dẫn tổ làm việc đáp ứng nhu cầu của người dùng. Các thành viên tổ chịu trách nhiệm làm cho công việc được thực hiện. Không có một trong những vai trò then chốt này, dự án có thể thất bại. Không có người quản lí dự án, không có người lãnh đạo tổ, không có người kiểm thử, và không có vai trò đảm bảo chất lượng phần mềm trong dự án Scrum. Bất kì ai trong những vai trò phụ này sẽ tạo ra xung đột không cần thiết. (Đó là lí do tại sao tổ được gọi là “tự quản.”)

Có các cách nhìn khác nhau liên quan tới kích cỡ của dự án Scrum. Một số người tin tổ Scrum nên có từ 5 tới 10 người; số khác nghĩ nó có thể lên tới 20 hay thậm chí 40 người.

Theo kinh nghiệm của tôi, 6 tới 8 người làm việc tốt nhất vì quá nhiều người sẽ làm khó chia sẻ thông tin. Mọi người làm việc tốt nhất theo các tổ nhỏ hơn và đó là lí do tại sao cách tiếp cận linh động có tác dụng tốt cho các dự án nhỏ. Nếu dự án của bạn có 15 hay 25 người, bạn có thể có vấn đề.

Dự án Scrum được chia thành nhiều “đơn vị công việc” nhỏ hơn có tên là “Sprint”. Sprint bao giờ cũng có chiều dài thời gian cố định cho nên tổ có đích xác cùng khối lượng thời gian để làm việc. Bằng việc làm cho mọi Sprint có cùng chiều dài, tổ biết năng lực riêng của nó cho công việc. Nếu chiều dài Sprint thay đổi, tổ sẽ không biết năng lực của nó (Cần bao lâu để hoàn thành một số nhiệm vụ) điều làm cho lập kế hoạch thành khó khăn hơn. Đây là vấn đề tinh tế mà nhiều người không chú ý nhưng điều rất quan trọng là mọi Sprints có cùng chiều dài. Nếu dự án của bạn không tuân theo qui tắc này, bạn cũng có thể có vấn đề. Tôi thường cho tổ của tôi thời gian cố định 4 tuần vì tôi nghĩ 2 tuần quá ngắn và 5 tuần là quá dài.

Từng Sprint đều là một cơ hội để học vì tổ làm việc cùng nhau và điều chỉnh theo năng lực của nhau. Mọi Sprint đều bắt đầu với cuộc họp lập kế hoạch cho Sprint nơi các thành viên tổ thảo luận xây dựng “CÁI GÌ” và họ sẽ xây dựng nó “NHƯ THẾ NÀO”. Tập trung của cuộc họp là chọn một số nhiệm vụ từ Các khoản mục tồn dư sản phẩm – Product Backlog Items (yêu cầu phần mềm) và chia chúng thành một danh sách các nhiệm vụ có tên là Tồn dư Sprint (Sprint Backlog). Mục đích của Lập kế hoạch Sprint là để lập kế hoạch công việc cho Sprint đó, và chắc các thành viên tổ hiểu công việc của nó dựa trên phản hồi thừ Sprint trước. Mọi thành viên tổ phạm sai lầm ở vài Sprints ban đầu, khi họ làm việc cùng nhau; họ học cùng nhau và cuối cùng trở nên giỏi hơn. Mọi sự thường cải tiến ở Sprint thứ ba hay thứ tư. Nếu bạn có vấn đề trong vài Sprint đầu, đừng lo lắng vì bạn vẫn đang học cách làm việc cùng nhau khi bạn xây dựng sản phẩm cho một Sprint và một lúc.

Mỗi sáng tổ ngồi cùng nhau vào cuộc họp Scrum hàng ngày để chia sẻ thông tin và phân công nhiệm vụ (Ai làm gì ngày hôm đó). Cuộc họp Scrum hàng ngày thường  kéo dài quãng 10 phút nhưng sai lầm chung là các thành viên thường quyết định bỏ qua cuộc họp hàng ngày. Theo kinh nghiệm của tôi, nếu tổ không có cuộc họp Scrum hàng ngày, tổ sẽ không làm việc tốt khi xung đột xảy ra. Scrum hàng ngày là thời gian mà các thành viên tổ thảo luận về công việc của họ với nhau cũng như chia sẻ kinh nghiệm và học từ nhau. Người chủ Scrum phải giám sát và đo tiến bộ của Sprint (tức là, việc đo được thực hiện hàng ngày trên tiến bộ của tổ). Nếu tổ của bạn không có cuộc họp Scrum hàng ngày, đó có thể là lí do tại sao dự án của bạn có vấn đề.

Phần cuối cùng của Sprint là suy ngẫm Sprint và kiểm điểm Sprint nơi toàn tổ (kể cả người chủ Scrum và người sở hữu Sản phẩm) thảo luận về cách họ đã làm việc trong Sprint đã qua và đi tới cách cải tiến công việc của họ trong Sprint tiếp. Suy ngẫm Sprint được giữ riêng trong tổ chỉ khi họ thảo luận nó đã được thực hiện “THẾ NÀO”. Hoạt động này là mấu chốt cho tổ vì nó là quá trình học tập cho mọi thành viên. Nó là việc làm của người chủ Scrum để chắc các thành viên tổ tham dự tất cả các cuộc họp và chia sẻ kinh nghiệm.

Kiểm điểm Sprint là chỗ tổ duyệt qua “CÁI GÌ” đã được thực hiện với khách hàng để xem liệu tổ có hoàn thành điều họ lập kế hoạch trong Lập kế hoạch Sprint không. Trong buổi kiểm điểm này, các thành viên tổ giải thích và làm đề mô công việc và khách hàng cung cấp phản hồi về sản phẩm. Việc trao đổi thông tin được làm tài liệu bởi người sở hữu sản phẩm trong tồn dư sản phẩm – Product Backlog.

Vì bạn không giải thích chi tiết về các vấn đề với Scrum, tôi chỉ đoán nhưng trước khi bạn chuyển trở lại phương pháp cũ, bạn cần kiểm điểm công việc của bạn và phải chắc rằng bạn không phạm phải những sai lầm mà tôi đã nhắc tới ở trên. Giống như bất kì phương pháp mới nào, cần thời gian để làm nó tốt và điều quan trọng nhất là toàn bộ tổ phải có được đào tạo đúng để làm nó tốt. Scrum có tác dụng tốt với dự án phần mềm nhỏ và nó đang ngày càng phổ biến hơn với các dự án phát triển ứng dụng Di động và Tính toán mây. Nếu bạn vẫn còn có vấn đề, bạn có thể cần ai đó có kinh nghiệm để giúp. Có thể bạn cần đem vào một nhà tư vấn Agile.

—English version—

Difficulty applying Scrum

A software developer wrote to me: “We are applying Scrum method to our software project but we are having a lot of problems. Although our project manager has taken an Agile training class but he cannot solve it either. We are thinking about switching back to the old method. Please advise.”

Answer: Scrum is an excellent method for small software project. The key different between Scrum and other approaches is its simplicity approach. Scrum allows the project to be done incrementally, one piece at a time. To make Scrum works, you need to have experienced team members because Scrum requires a self-organizing team, that means there is no project manager or team leader to direct the team but every member of the team must work together to get the work done. Since you have a project manager, it seems that you may not use Scrum correctly. If he is the only one who receives Agile training than it is a mistake. I recommend that the entire team to enroll in a Scrum training so you can do thing correctly.

There are three roles in Scrum project: The Scrum Master, the Product Owner, and the Team Members. The Scrum Master is responsible to make sure that the team is following the Scrum process. The Product owner represents the customers’ views and guides the team to do work that meet user’s needs. Team Members are responsible for getting the work done. Without one of these key roles, the project may fail. There is no project manager, no team leader, no tester, and no software assurance quality roles in Scrum project. Any of these additional roles will create unnecessary conflict. (That is why the team is called “self-organized.”)

There are different views regarding the size of Scrum project. Some believe Scrum team should be 5 to 10 people; other think it could be up to 20 or even 40 people.

In my experience, 6 to 8 people works best since too many people will make it difficult to share information. People work best in smaller team and that is why agile approach works well for small projects. If your project has 15 or 25 people, you may have problem.

Scrum project is divided into several smaller “unit of work” called “Sprint”. Sprint always has a fixed length of time so the team has exactly the same amount of time to do work. By making every Sprint the same length, the team learns its own capacity for work. If the Sprint length changes, the team will not know its capacity (How long to complete a number of tasks) which make planning more difficult. This is a subtle issue that many people do not pay attention but it is very important that all Sprints have the same length. If your project does not follow this rule, you may also have problem. I often give my team a fixed time of 4 weeks as I think 2 weeks is too short and 5 weeks is too long.

Each Sprint is an opportunity to learn as the team works together and adjusts to each other’s capability. Every Sprint starts with a Sprint Planning meeting where the team discusses “WHAT” to build and “HOW” they will build it. The focus of the meeting is on choosing a number of tasks from the Product Backlog Items (Software Requirements) and breaking them into a list of tasks called the Sprint Backlog. The goals of Sprint Planning is to plan the work for that Sprint, and make sure team members understanding its works based on feedback from the previous Sprint. Every team makes mistakes at the first few Sprints, as they work together; they learn together and eventually get better. Things often improve in the third or fourth Sprint. If you are having problems in the first few Sprints, do not worry as you are still learning how to work together when you build the product one Sprint at a time.

Each morning the team gets together at the Daily Scrum meeting to share information and assign task (Who is doing what on that day). The Daily Scrum meeting usually lasts about 10 minutes but the common mistake is members often decide to skip the daily meeting. In my own experience, if a team fails to have daily Scrum meeting, the team will not work well as conflicts will happen. Daily Scrum is the time where the team members discuss their works with each other as well as share experience and learn from one another. The Scrum Master must monitors and measure the progress of the Sprint (i.e., Measurement is made every day on the team progress). If your team does not have the daily scrum meeting, it may be a cause why your project is having problem.

The last parts of the Sprint are the Sprint Retrospective and Sprint Review where the whole team (including the Scrum Master and Product Owner) discuss how they did their work during the past Sprint and come up with ways to improve their work in the next Sprint. The Sprint Retrospective is keeping exclusive within the team only where they discuss “HOW” it was done. This activity is critical for the team as it is a learning process for every member. It is the job of the Scrum Master to make sure team members do attend all these meetings and share experiences.

The Sprint Review is where the team goes over “WHAT” was done with the customers to see if the team does complete what they plan during Sprint Planning. In this review, team members explain and demonstrate the work and customers provide feedback about the product. The exchange of information is documented by the Product Owner into the Product Backlog.

Since you do not explain in detail about the problems with Scrum, I only guess but before you switch back to the old method, you need to review your work and make sure that you do not make mistakes as I mentioned above. Like any new methods, it take times to do it well and the most important is the entire team must receive the proper training to do it well. Scrum works well with small software project and it is getting more popular with Mobile application development and Cloud computing projects. If you are still having problems, you may need someone with experience to help. Maybe you need to bring in an Agile consultant.