Một người viết cho tôi: “Em đã làm việc như người phát triển phần mềm trong ba năm và vừa mới được đề bạt làm người quản lí dự án. Gần đây công ti của em đang chấp nhận phương pháp agile (phương pháp Scrum). Có tin đồn rằng họ không cần người quản lí dự án nữa và em có thể bị sa thải. Em có thể làm gì để duy trì vị trí của em? Xin thầy lời khuyên.”
Đáp: Việc dịch chuyển từ phát triển truyền thống sang cách tiếp cận agile mất thời gian và đào tạo để làm nó cho đúng. Mọi người phải hiểu vai trò, trách nhiệm của họ và đảm nhiệm cho công việc của họ. Điều này sẽ yêu cầu thay đổi trong cách công ti vận hành từ đỉnh tới đáy nơi những người quản lí phải hiểu “tình huống lí tưởng” là thế nào và tình huống nào thì không. Dễ nói điều gì đó như chúng ta không cần người quản lí dự án nữa nhưng trong thực hành điều đó không xảy ra dễ dàng thế. Đừng mong đợi việc dịch chuyển từ phát triển truyền thống sang cách tiếp cận agile xảy ra trong vài tuần hay vài tháng, có nhiều điều công ti của bạn phải học từ việc chuyển này, và nó sẽ yêu cầu nhiều nỗ lực để làm việc cho đúng. Theo ý kiến cá nhân, tôi nghĩ Scrum là cách tiếp cận rất tốt tới phát triển phần mềm. Nó khác với cách tiếp cận thác đổ truyền thống mà yêu cầu phải là rõ ràng và được hiểu. Scrum chấp nhận rằng yêu cầu có thể không được xác định rõ từ đầu cho nên chúng có thể thay đổi và mục đích là đáp ứng theo cách tốt với những thay đổi đó bằn việc tạo ra phần mềm làm việc tăng dần cho khách hàng.
Về căn bản, có ba vai trò trong Scrum: Thầy Scrum, Người chủ sản phẩm, và Tổ tự quản. Mặc dầu không có vị trí người quản lí “chính thức” trong Scrum, điều đó không có nghĩa là bạn không có việc làm. Bạn có thể vẫn học làm việc như một Thầy Scrum để đảm bảo rằng mọi người tuân theo các qui tắc scrum; tạo điều kiện cho gặp gỡ giữa tổ và người chủ sản phẩm; và loại bỏ các chướng ngại từ dự án để cho tổ dự án có thể hội tụ vào sản phẩm mà không bị ngắt quãng. Kĩ năng mà bạn đã học như người quản lí dự án vẫn áp dụng được trong phương pháp Scrum. Chẳng hạn, bạn có thể tham gia và tạo điều kiện cho việc phát triển Tồn dư sản phẩm của những việc được ưu tiên hoá để được thực hiện. Tồn dư là tương tự như đặc tả yêu cầu của dự án truyền thống mà bạn quen thuộc với. Trong Scrum, tồn dư sản phẩm thường được phát triển cùng với Người chủ sản phẩm và Tổ phát triển nhưng trong việc chuyển dịch, họ vẫn cần ai đó để quản lí nó.
Dự án cần có Kế hoạch đưa ra để chuyển giao sản phẩm qua nhiều chặng nước rút Sprints với ưu tiên cao nhất được chuyển giao trước nhất. Kế hoạch đưa ra cũng là tương tự với Lịch biểu dự án. Nó nhận diện tính năng sản phẩm và thời gian tương ứng theo đó những tính năng nào đó sẽ được chuyển giao cho khách hàng. Trong Scrum, Kế hoạch đưa ra được phát triển chung bởi Người chủ sản phẩm và Tổ phát triển nhưng trong khi dịch chuyển, họ vẫn cần ai đó tạo điều kiện và quản lí nó.
Vậy mà, Người chủ sản phẩm và Tổ phát triển quyết định tính năng nào và nhiệm vụ có liên quan nào được thực hiện trong từng Sprint, ai đó có nhiều kinh nghiệm phải đưa ra các ước lượng như một phần của lập kế hoạch Sprint. Những rủi ro và vấn đề nào đó cũng phải được thảo luận trong Họp lập kế hoạch Sprint nơi việc phát triển, kiểm thử và đưa ra được xác định và đây là chỗ kinh nghiệm của bạn được cần tới.
Khi các nhiệm vụ được nhận diện trong Họp lập kế hoạch Sprint, chúng được làm tài liệu trong Tổn dư Sprint. Tồn dư Sprint là tương tự như Phạm vi dự án trong phát triển truyền thống bởi vì nó bao quát mọi hoạt động cần được hoàn thành bên trong Sprint.
Tồn dư Sprint được cập nhật trong cuộc họp Sprint nơi khách hàng và người dùng được mời tham dự và có thể cần ai đó như bạn, người có thể tạo điều kiện và quản lí cuộc họp.
Trong cách tiếp cận Scrum, có cuộc họp hàng ngày nơi các thành viên tổ chia sẻ mối quan tâm và hoạt động của họ giữa các tổ, thỉnh thoảng họ cần ai đó để quản lí nó cho tới khi tổ sẵn sàng tự quản và có hiệu quả.
Đến cuối của từng Sprint, tổ họp cùng nhau và thảo luận cái gì làm việc và cái gì không làm việc, cuộc họp hồi tưởng này là tương tự với “bài học rút ra” truyền thống hay kiểm điểm “hậu kì” trong dự án truyền thống. Chừng nào tổ chưa có kinh nghiệm và không hiệu quả, nó có thể cần ai đó để tạo điều kiện cho cuộc họp hồi tưởng để chắc mọi sự làm việc tốt.
Nếu bạn so sánh các vai trò của người quản lí dự án truyền thống với Thầy Scrum, bạn có thể thấy rằng có những nhiệm vụ nào đó thiếu trong Thầy Scrum vì trong tình huống lí tưởng, mọi thứ có thể được thực hiện bởi Tổ tự quản, giả định rằng tổ bao gồm những thành viên có kinh nghiệm và được đào tạo tốt. Tuy nhiên trong thực hành, điều đó có thể không xảy ra theo cách đó. Vai trò của Thầy Scrum có thể bành trướng ra để bao quát một số nhược điểm khác. Trong cách tiếp cận Scrum, qui trình được tạo điều kiện bởi Thầy Scrum người có trách nhiệm chính là hướng dẫn và loại bỏ các vấn đề ngăn cản tổ đáp ứng mục đích. Mặc dầu Thầy Scrum Master không phải là người quản lí của tổ (Tổ là tự tổ chức và tự quản) nhưng trong thực tế và trong khi dịch chuyển, Thầy có thể hành động như người tạo điều kiện cho việc giải quyết vấn đề và cho trao đổi và thỉnh thoảng phải đóng vai trò tích cực hơn trong việc bảo đảm rằng tổ tuân theo qui trình Scrum, tạo điều kiện cho cộng tác, và hành động như “thầy kèm” cho tổ.
Tất nhiên trong Scrum, bạn không hành động như người quản lí dự án, chỉ đạo mọi thứ, quản lí mọi thứ và chịu trách nhiệm về mọi thứ. Trong Scrum mọi người chia sẻ trách nhiệm về thành công của dự án. Tuy nhiên, trong thực hành ai đó phải quan tâm tới lịch biểu, chi phí và ngân sách và tôi nghĩ là người quản lí dự án, mọi người sẽ mong đợi bạn hoàn thành vai trò đó. Lời khuyên của tôi là học nhiều nhất có thể về Scrum vì với kinh nghiệm của bạn, công ti của bạn sẽ cần ai đó như bạn.
—-English version—-
Scrum method
A person wrote to me: “I have been working as software developer for three years and just got promoted to project manager. Recently my company is adopting agile development (Scrum method). There is a rumor that they do not need project manager anymore and I could be laid-off. What can I do to maintain my position? Please advice.
Answer: The transition from traditional development to agile approach takes time and trainings to do it right. Everybody must understand their roles, responsibilities and be accounted for their works. This will require changes in the way the company operates from top to bottom where managers must understand which the “ideal situation” is and which is not. It is easy to say something like we do not need project manager anymore but in practice it does not happen that easily. Do not expect the transition from traditional development to agile approach to happen within few weeks or few months, there are many things your company must learn from this transition, and it will require a lot of efforts to do thing correctly. Personally, I think Scrum is a very good approach to software development. It differs from the traditional waterfall approach which requirements must be clear and understood. Scrum accepts that requirements may not be well defined up-front so they may change and the goal is to respond in a good manner to these changes by produce a working software incrementally to customers.
Basically, there are three roles in Scrum: Scrum Master, Product Owner, and Self-organized Team. Although there is no “Official” project manager position in Scrum, it does not mean you do not have a job. You could still learn to work as a Scrum Master to ensure that everyone follows the scrum rules; facilitate the meeting between the team and the product owner; and remove obstacles from the project so the team can focus to work on the product without disruption. The skills that you have learned as project manager is still applicable in Scrum method. For example, you can participate and facilitate the development of a Product Backlog of prioritized work to be done. The backlog is similar to the requirements specification of the traditional projects that you are familiar with. In Scrum, the Product Backlog is often jointly developed by the Product Owner and the Development Team but during the transition, they still need someone to manage it.
The project needs to have a Release Plan to deliver product across multiple Sprints with the highest priority first. The Release Plan is also similar to the traditional Project Schedule. It identifies product features and the corresponding time in which certain features will be delivered to customers. In Scrum, the Release Plan is jointly developed by the Product Owner and the Development Team but during the transition, they still need someone to facilitate and manage it.
Although, the Product Owners and the Development Team decide which features and related tasks to be done within each Sprint, somebody with more experience must come up with estimates as part of Sprint planning. Certain risks and issues must also be discussed during the Sprint Planning Meeting where the development, testing and release are determined and this is where your experience is needed.
When tasks are identified in the Sprint Planning Meeting, they are documented into the Sprint Backlog. The Sprint Backlog is similar to the Project Scope in the traditional development because it covers all activities that need to be completed within the Sprint.
The Sprint Backlog is updated at the Sprint Meeting where customers and users are invited to participate and it may need someone like you who can facilitate and manage the meeting.
In Scrum approach, there is a daily meeting where team members share their concerns and activities among the team, sometime they need someone to manage it until the team is really self-organized and be effective.
At the end of each Sprint, the team gets together and discusses what works and what did not work, this Retrospective meeting is similar to the traditional “lessons learned” or “Post mortem” review in traditional projects. Unless the team is experienced and effective, it may need someone to facilitate the retrospective meeting to make sure things work well.
If you compare the roles of traditional Project Manager with Scrum Master, you could see that there are certain tasks missing in Scrum Master because in an ideal situation, everything can be done by the Self-organized Team, assume that the team consists of experienced and well trained members. However in practice, it may not happen that way. The role of the Scrum Master could be expanding to cover some of these weaknesses. In Scrum approach, the processis facilitated by a Scrum Master whose primary responsibility is to guide and remove issues that prevent the team from meeting the goal. Although the Scrum Master is not the manager of the team (The team is self-organizing and self-managed) but in reality and during the transition, the Scrum Master could acts as a facilitator for issues resolution and communication and sometime must play a more active role in making sure that the team follows the Scrum process, facilitates collaboration, and acts as a “mentor” for the team.
Of course in Scrum, you do not act as a Project Manager, direct everything, manage everything and be responsible for everything. In Scrum everybody shares responsibility for the project’s success. However, in practice somebody must be concerned with the schedule, the cost and budget and I think as project manager, people would expect you to fulfill that role. My advice is to learn as much as possible about Scrum because with your experience, your company will need someone like you.
