Làm việc tổ là cái gì đó nhiều người nói tới nhưng rất khó đạt tới trong dự án phần mềm. Lí do mà mọi người không làm việc tốt trong tổ vì khác biệt trong ý kiến và mục đích. Tôi đã thấy nhiều thành viên tổ đấu tranh chống lại nhau vì họ bảo vệ ý kiến riêng của họ hay tin rằng họ là đúng và mọi người khác là sai.

Mọi người sẽ làm việc cùng nhau như một NHÓM nếu có những vai trò, trách nhiệm và thẩm quyền được xác định rõ. Chẳng hạn trong dự án phần mềm bạn có các vai trò như người quản lí dự án, người lãnh đạo kĩ thuật, người thiết kế phần mềm, người lập trình, người kiểm thử, chuyên viên đảm bảo chất lượng v.v. Chừng nào mọi người còn tuân theo các qui tắc, hiểu vai trò và trách nhiệm của họ thì nhóm làm việc được. Điều đó nghĩa là mọi người đang làm điều được mong đợi về từng vai trò đó, nhưng không cái gì vượt ra ngoài. Cách tiếp cận này có tác dụng tốt trong nhà máy, trong dây chuyền lắp ráp, trong công việc thủ công khi qui trình được xác định rõ và thấy được cao. Trong phần mềm thỉnh thoảng nó không làm việc tốt. Lí do là vai trò và trách nhiệm tạo ra “biên giới nhân tạo” giữa các thành viên nhóm. Chẳng hạn, người lập trình viết mã và “quẳng” sang cho người kiểm thử kiểm thử chúng. Cách nhìn của họ là “chúng tôi hoàn thành việc của mình như được yêu cầu và để người khác làm việc của họ.” Cách tiếp cận LÀM VIỆC NHÓM này cho phép mọi người duy trì cách nhìn RIÊNG của họ, vị trí RIÊNG của họ mà không có nhiều tương tác. Nó giúp tránh các xung đột giữa các thành viên và cho phép họ ở lại BÊN TRONG kĩ năng giới hạn riêng của họ mà không cần làm cái gì bên ngoài vai trò của họ.

Mọi người sẽ làm việc với nhau như một TỔ khi họ phụ thuộc vào kĩ năng và tri thức của nhau để tạo ra cái gì đó là ngoại lệ và bên ngoài năng lực cá nhân của họ. Điều này bao gồm nhiều học tập, hiểu biết, thương lượng, thách thức và tin cậy vào sức mạnh của mọi người lẫn nhau. Trong loại CÔNG VIỆC TỔ này, mọi người có thể thu được ích lợi lớn. Chẳng hạn: Người lập trình tin cậy vào đảm bảo chất lượng kiểm điểm công việc của họ để xác định vấn đề để cho họ có thể sửa chữa chúng sớm hơn làm nảy sinh sản phẩm chất lượng cao. Không có đào tạo đúng, không có trao đổi đúng, không có quản lí đúng, làm việc tổ sẽ KHÔNG xảy ra. Làm việc tổ là khó bởi vì các thành viên tổ phải giải thích cho người khác điều họ làm và tại sao. Đồng thời, họ phải sẵn lòng nghe các gợi ý và sẵn lòng thay đổi cách họ làm mọi thứ. Điều đó nghĩa là mọi thành viên tổ đều phải có mối quan tâm lớn tới người khác và cách họ làm việc của họ bằng tâm trí cởi mở, thái độ cởi mở, để cho họ có thể cải tiến.

Lúc bắt đầu dự án, các thành viên tổ không biết lẫn nhau. Họ tới từ các nền tảng đa dạng, với các kĩ năng và kinh nghiệm khác nhau và họ cũng có những thiên kiến nào đó. Họ cần thời gian để hiểu lẫn nhau, xây dựng mối quan hệ và cuối cùng tin cậy lẫn nhau. Đó là lí do tại sao đào tạo làm việc tổ vào lúc bắt đầu dự án là quan trọng thế. Tôi biết nhiều người quản lí thường bỏ qua việc đào tạo này để tiết kiệm tiền. Đó là sai lầm lớn vì họ sẽ phải giải quyết với xung đột cá nhân, vấn đề và tranh đấu giữa các thành viên trong dự án về sau. Làm việc tổ đặc biệt khó cho những người đã từng làm việc trong LÀM VIỆC  NHÓM một thời gian lâu, bởi vì có xu hướng quay trở lại cách làm cũ với mọi sự. Chẳng hạn, người lãnh đạo kĩ thuật có xu hướng nói với những người khác điều phải làm thay vì lắng nghe họ. Người lập trình không quan tâm tới cách người kiểm thử kiểm công việc của họ nhưng sẽ nổi giận khi người kiểm thử tìm ra nhiều lỗi.

Khi nhiều người hơn muốn dùng cách tiếp cận Agile, lời báo trước của tôi là cách tiếp cận này yêu cầu mọi người từ những kinh nghiệp khác nhau làm việc cùng nhau như một TỔ. Bằng việc tạo ra tổ “tự tổ chức”, mọi người phải làm việc cùng nhau bởi vì những rào chắn cá nhân như vai trò, trách nhiệm mất đi. Không có đào tạo cách làm việc tổ, cách tiếp cận này sẽ THẤT BẠI. Vì phải mất thời gian cho tổ làm việc cùng nhau, người quản lí cấp cao phải hội tụ vào việc có đào tạo cho mọi dự án Agile. Đào tạo kĩ thuật cho phương pháp Agile là KHÔNG đủ. Đào tạo LÀM VIỆC THEO TỔ phải là ưu tiên thứ nhất nếu bạn muốn thành công.

Các thực hành Agile như lập kế hoạch đưa ra tăng dần, lập kế hoạch chặng nước rút, và họp hàng ngày cung cấp thời gian cho tổ làm việc cùng nhau và xây dựng quan hệ lẫn nhau. Họp hàng ngày giúp các thành viên tổ nhận diện các cơ hội tiềm năng mà họ có thể tương tác lẫn nhau. Chặng nước rút và lập kế hoạch đưa ra cung cấp nhiều cơ hội có cấu trúc cho công việc tổ. Qua “hoạt động nội quan”, các thành viên tổ có thể kiểm điểm về công việc của họ và cung cấp phản hồi cho nhau cho nên cùng nhau tổ có thể liên tục cải tiến. Tổ đánh giá kết quả từ sản phẩm của chặng nước rút để xác định liệu làm việc theo tổ thêm có thể tạo ra kết quả tốt hơn không. Mọi chặng nước rút sẽ cho tổ cảm giác về hoàn thành và động viên tổ về giá trị của làm việc theo tổ. Điều đó bao giờ cũng là điều kì diệu khi người phát triển, người chủ sản phẩm, thầy scrum, người kiểm thử cùng nhau xây dựng để tạo ra cái gì đó có chất lượng cao, đúng thời gian và trong chi phí. Đó là lí do tại sao đào tạo LÀM VIỆC THEO TỔ có lẽ là quan trọng nhất trong phần mềm vì nó xác định thành công hay thất bại của dự án.

—-English version—-

Groupwork and Teamwork

Teamwork is something many people talk about but very difficult to achieve in software project. The reason that people do not work well in team because of differences in opinions and goals. I have seen many team members fighting against each other as they protect their own opinions or believe that they are right and everybody else is wrong.

People will work together as a GROUP if there are well defined roles, responsibilities and authority. For example in software project you have roles like project manager, technical leaders, software designer, programmers, testers, quality assurance specialist etc. As long as people follow the rules, understand their roles and responsibilities than the group will work. It means people are doing what is expected of each of the roles, but nothing beyond. This approach work well in the factory, in assembly line, in manual works when the process is well defined and highly visible. In software sometime it does not work well. The reason is roles and responsibilities create an “artificial boundary” between group members. For example, programmers write code and “throw over” to testers to test them. Their view is “we complete our jobs as required and let others do their jobs”. This GROUPWORK approach allows people to maintain their OWN view, their OWN place without much interacting. It helps avoid conflicts among members and allow them to stay WITHIN their own limiting skills without the need to do anything beyond their roles.

People will work together as a TEAM when they depend on each other’s skills and knowledge to create something that is exceptional and beyond their individual abilities. This involves a lot of learning, understanding, negotiating, challenging and trusting on each other’s strengths. In this kind of TEAMWORK, everybody can gain significant benefits. For example: Programmers trust Quality assurance to review their works to determine problems so they can fix them earlier resulting in high quality products. Without proper training, without proper communication, without proper managing, teamwork will NOT happen. Teamwork is difficult because team members must explain to others what they do and why. At the same time, they must be willing listen to suggestions and be willing to change the way they do things. That means every team member must have significant interest in others and how they do their work with an open mind, open attitude, so they can improve.

At the beginning of project, team members do not know each other. They come from various backgrounds, with different skills and experiences and they also have certain biases. They need time to understand each other, build relationship and eventually trust each others. That is why teamwork training at the beginning of the project is so important. I know many managers often skip this training to save money. It is a big mistake because they will have to deal with personal conflicts, issues and fighting among members in the project later. Teamwork is especially difficult for people who have been working in GROUPWORK for a long time, because there is a tendency to go back to the old way of doing things. For example, a technical leader has tendency to tell others what to do rather than listen to them. A programmer does not care how tester check his work but will get upset when tester find more defects.

As more people want to use the Agile approach. My caution is this approach requires people from different experiences to work together as a TEAM. By creating “self-organized” team, everybody must work together because personal barriers such as roles, responsibilities go away. Without teamwork training, this approach will FAIL. Since it takes time for the team to work together, senior manager must focus on having trainings for every Agile project. Technical training for Agile method is NOT enough. TEAMWORK training must be the first priority if you want to succeed.

Agile practices such as incremental release planning, sprint planning, and daily meetings provide the time for teams to work together and build relationships with each other. Daily meetings help team members to identify potential opportunities that they can interact with each others. Sprint and release planning provide more structured opportunities for teamwork. Through “retrospectives activity”, team members can review on their works and provide feedback to each other so together the team can continue to improve. The team evaluate results from the sprint product to determine if more teamwork could produce better results. Every sprint will gives the team a sense of accomplishment and motivating the team on the value of teamwork. It is always a wonderful thing when developers, product owners, scrum masters, testers build off each other to create something of high quality, on time and within costs. That is why TEAMWORK training is probably the most important in software as it determines project success or failure.