Nếu công ty/team của bạn đã Agile/áp dụng Scrum rồi, việc REMOTE sẽ nhẹ nhàng lắm! Đây là một statement quen thuộc của rất nhiều thành viên VFW (Vietnam Remote Workforce - 1 group khá mới nhưng đã có đến 4,2k members, đều rất chất) trong các cuộc thảo luận mùa Covid-19. Với tình hình Covid-19 diễn biến phức tạp, Remote đang là từ khoá hot trong cộng đồng kinh doanh. Qua khảo sát không chính thống, những doanh nghiệp/tổ chức đã áp dụng Agile & Scrum, việc Remote không quá khó nhằn. Điều gì đã làm nên điều này, hãy cắt những lát nhỏ hơn: - Agile cổ vũ tính phản ứng nhanh với sự thay đổi. Vì vậy khi đã ngấm Agile, bạn không than phiền, mà welcome sự thay đổi, thậm chí coi Covid-19 như một cơ hội để được đổi mới cách làm việc, chuyên nghiệp hoá đội ngũ.
- Agile nhấn mạnh vai trò tương tác collaboration và giao tiếp interaction, vậy nên dù Remote về mặt vật lý, nhưng tinh thần của anh em không remote chút nào, vẫn online call với nhau đều đều. Luôn sẵn sàng phối hợp với nhau
- Agile với Scrum Framework đưa ra một thói quen mới nhưng vô cùng hiệu quả trong công việc - đó là 4 sự kiện chính thống không tách rời với đội nhóm làm việc. Qua 4 sự kiện này, các thành viên trong team sẽ cùng nhau: minh bạch, thanh tra & thích nghi với điều kiện làm việc mới hướng đến kết quả chung.
Bài viết này, dành cho những team đã/đang và sắp đưa vào những thực hành Agile/Scrum cơ bản nhất. - Nếu đã, hãy cùng đọc và chia sẻ thêm những bí kíp của bạn để các buổi event này được diễn ra hiệu quả và ăn ý.
- Nếu đang, hãy soi chiếu với những tiêu chuẩn cơ bản, xem bạn đang thừa thiếu chỗ nào
- Nếu sẽ, đây là một hướng dẫn cơ bản nhất để bạn bắt đầu với 1 chuỗi các sự kiện của team trong tuần.
Hãy tin ở chúng mình, điều gì mới bắt đầu cũng đều khó cả. Nhưng một khi đã làm, bạn sẽ dần quen và chúng mình cùng điều chỉnh để đi vào quỹ đạo quen. Hình ảnh dưới đây là 3 Trụ cột của Scrum: Tính minh bạch, Thanh Tra & Thích nghi. Hãy khoan đi vào chi tiết vội, hãy dành một chút thời gian đọc lại ý nghĩa bản chất của các sự kiện này. - Tính minh bạch: Minh bạch process cho những người chịu trách nhiệm/liên quan đến kết quả của công việc
- Tính thanh tra: Check kịp thời tiến độ thực hiện để tìm ra những rủi ro/nguy cơ/hoặc cần trợ giúp
- Tính thích nghi: Điều chỉnh lại mục tiêu/quy trình để giảm thiểu tối đa các rủi ro gặp phải.
Có phải đây là những điều bạn muốn các team làm việc của mình sẽ thực hiện hiệu quả hàng ngày. Chuyện gì sẽ xảy ra nếu các bạn đồng ý với nhau 1 list công việc cần thực hiện và sau đó chỉ đến thứ 6 cuối tuần đồng bộ lại: - Khả năng đi lệch hướng sẽ rất cao
- Cách tiếp cận có thể chưa đúng dẫn đến phí thời gian và nguồn lực của cả tuần
- Nếu bạn khó không ai biết mà hỗ trợ
4 SỰ KIỆN CHÍNH THỨC CỦA TEAM AGILE4 sự kiện không thể thiếu của 1 team Agile, đó là: - Daily Meeting
- Sprint Planning
- Sprint Review
- Sprint Retrospective
Trong thời gian làm việc Remote, Magestore đã đưa ra những Agreement chung về các sự kiện của Agile Team - Mọi sự kiện đều được đưa lên lịch bao gồm tối thiểu: Planning/Review/Retro/Daily
- Mọi sự kiện đều có Link Hangout Meet, link này được team sử dụng cho buổi họp của mình, được để public (người khác có thể join để learn/govern)
- Điều nên làm: Cần chụp ảnh lại ảnh cả team tham gia trong họp team và post lên Magestore channel trên Slack. Đừng sợ Spam, đây là một động lực để cả công ty thấy kết nối trong cách làm Remote
1. DAILY MEETINGDaily Meeting là gì?Là buổi trao đổi ngắn mà Development Team thực hiện đều đặn hằng ngày nhằm cập nhật và đồng bộ công việc giữa các thành viên, nêu lên trở ngại (nếu có) đang gặp phải. Các thành viên trả lời 3 câu hỏi - Qua làm gì
- Nay làm gì
- Có gì khó khăn/cản trở
Sự kiện Daily thể hiện giá trị gì?- Tập trung (Nên dành thời gian đầu nhắc lại mục tiêu Sprint)
- Cởi mở (Đưa ra khó khăn kịp thời)
- Cam kết (Chia sẻ trung thực, nói ra kế hoạch & cố gắng hết sức thực hiện)
- Tôn trọng (Lắng nghe người khác trình bày)
Các nguyên tắc thực hiện Daily Meeting- Quay xung quanh 3 câu hỏi chính: Qua làm gì, Nay làm gì, Có gì cản trở?
- Trò chuyện tương tác trực tiếp hoặc video call trong đk Remote (Tool Daily Report chỉ là hỗ trợ tính minh bạch)
- Giữ buổi họp ngắn, tầm 15 phút.
- Bắt đầu đúng giờ, tạo thành nhịp quen thuộc
- Involve tất cả mọi người, nếu không tham gia, report đầy đủ theo format 3 câu hỏi.
- Với các vấn đề phát sinh phức tạp, tổ chức trao đổi nhóm hoặc 1-1 ngay sau daily
2. SPRINT PLANNINGÝ nghĩa buổi Sprint PlanningSprint Planning là sự kiện để khởi động, lập kế hoạch cho mỗi Sprint. Buổi này rất quan trọng đến hiệu suất của team. - Giúp PO điều phối backlog tốt hơn
- Dev team hiểu rõ giá trị người dùng kỳ vọng, đưa ra những đóng góp nhiều hơn cho cải tiến Quality
- Giúp đội phát triển nâng cao cả khả năng tự quản, trưởng thành và nâng cao hiệu suất làm việc.
Điều cần đạt sau Sprint PlanningSprint Planning là buổi làm việc của toàn team thường vào đầu tuần này hoặc cuối tuần trước, để làm rõ trong 1 tuần tiếp theo, chúng ta muốn làm những việc gì & cách làm việc đó như thế nào. Rút ngắn theo sơ đồ 2 phần & 3 câu hỏi như sau: Phần 1 - Xác định làm gì- Không phải đến buổi Sprint Planning mới ngồi xác định làm gì
- Nên có các buổi làm mịn Backlog để làm rõ dần các task khi đẩy vào Sprint Backlog
- PO làm rõ khoảng 5-8 mục tiêu theo thứ tự ưu tiên
- Xác định rõ năng lực của nhóm ở trong Sprint (bằng cách cập nhật thời gian làm việc của mọi người, tính ra hiệu suất) Ví dụ full cả 5 người đi làm, thời gian làm việc hiệu suất là 6/8 tiếng Total có 5 x 6 = 30 tiếng/ngày, 1 tuần = 150 tiếng.
Phần 2 - Team chủ động tìm cách làm- Dev Team đọc các yêu cầu từ PO, làm rõ nếu cần và estimate thời gian làm
- Việc estimate thời gian dựa trên thời gian trung bình làm việc đó trong Quá khứ
- Với tính chất công việc mới, chưa làm bao giờ, break nhỏ để estimate chi tiết hơn, hoặc cùng thống nhất 1 buổi làm Solution chi tiết hơn cho mục tiêu này
- Xong Phần 2, dev team hiểu rõ các việc cần hoàn thành & cách tiếp cận để triển khai được việc đó trong Sprint.
- Nếu có các cuộc họp khác trong tuần, cũng nên xác định date & time luôn trong buổi Sprint Planning này
- Cổ vũ tính Cross Functional trong team khi nhận task trong tuần, tránh để công việc dồn vào 1 mắt xích duy nhất.
Bí kíp hiệu quả cho hoạt động Sprint PlanningNhư đã nói ở trên, Sprint Planning ko phải đến buổi họp đó các bạn mới xác định tuần này làm gì, nếu thế cả team sẽ rất mất thời gian với nhau. Các bạn cần làm trước điều này rồi, hiểu là thinking hoặc set up hoặc nghiên cứu 1 vài điều cơ bản trước về điều chúng ta muốn làm. Có 1 event mang tính đệm, lót cho Planning, đó là Grooming mà các bạn có thể dành 10% thời gian Sprint để cùng work với nhau. Tiếng Việt hay gọi là Làm Mịn. Mục tiêu: Chia nhỏ các hạng mục lớn (những hạng mục sắp làm), phân tích các hạng mục, tái-ước lượng, tái-đánh giá độ ưu tiên của các hạng mục dành cho các Sprint sắp tới. - Ko dành cho hạng mục trong Sprint hiện tại, mà là các mục tiêu trong tương lai (thường là trong 1 hoặc 2 tuần kế tiếp)
- Áp dụng Grooming thì buổi Sprint Planning sẽ tương đối đơn giản
- Nếu ko có Grooming, phần Sprint Planning sẽ có tương đối nhiều câu hỏi, khám phá, bị lấn thời gian cho phép.
3. SPRINT REVIEWSprint Review là gìSprint Review là buổi họp sơ kết sprint, thực hiện đánh giá mục tiêu của sprint được xác định từ buổi Planning. - Team sẽ trình bày về kết quả trong Sprint và demo các chức năng đã thực hiện trong sprint lần lượt theo thứ tự các Backlog items.
- Lắng nghe các phản hồi từ Product Owner và thảo luận về các chỉnh sửa (nếu có) sẽ thực hiện trong Sprint tiếp theo.
- Sơ kết Sprint là một hoạt động thanh tra và thích nghi cho sản phẩm, xem xét và học những gì đã xảy ra rồi đưa ra cải tiến.
Nếu không thực hiện Sprint Planning thì sao?- Kết quả hoàn thành trong Sprint sẽ không rõ ràng với các thành viên của nhóm & PO, có thể sản phẩm chưa đạt được mục tiêu đưa ra
- Không khai thác, hiểu được mong muốn thực sự của khách hàng
- Bị chậm trễ trong việc nhận feedback, gây ảnh hưởng đến kết quả cuối cùng
- Không học được bài học gì/rút ra được kinh nghiệm về việc thiết lập mục tiêu & cách tiếp cận thực hiện mà nhóm đã lựa chọn
- Lưu ý: Việc phát hành trên các kênh chính thức của công ty không thay thế cho buổi Sprint Review của team
4. SPRINT RETROSPECTIVEÝ nghĩa của Sprint RetroNếu Sprint Review tập trung vào Product, thì Sprint Retro là thời gian để review & reflect Quy trình & Môi trường (Process & Contexts)
Mục tiêu: Khảo sát lại toàn bộ quy trình làm việc của Sprint vừa qua để tìm ra các cải tiến trong Sprint tới, nhằm mang lại hiệu suất cao hơn cho nhóm. Giá trị của Sprint Retro- Là cơ hội để các thành viên tự đánh giá, nhìn nhận lại các hoạt động vừa qua
- Là dịp để các thành viên trong team chia sẻ quan điểm, để hiểu nhau hơn, làm việc smooth hơn (Open to talk)
- Đưa ra phương pháp cải tiến dự án -> cải tiến để làm tốt hơn (yếu tố quyết định thành công của dự án)
Chia sẻ càng nhiều, team sẽ càng hiểu nhau hơn và phối hợp với nhau tốt hơn. 1 số Tips khi thực hiện Sprint Retro- Không nên tập trung quá sâu vào vấn đề. Dễ dẫn đến chán nản & tiêu cực. Điều phối giữa việc khắc phục điểm yếu và phát triển điểm mạnh/tích cực
- Nếu các buổi cải tiến cứ sử dụng mãi một kỹ thuật thì có thể dẫn đến buồn chán, do đó nên sử dụng một vài kỹ thuật để thay đổi theo thời gian. Tham khảo các phương pháp Retro khác nhau tại Agile Playbook ví dụ Glad Sad Mad; Fun/Learn/Done; 4, Start Fish
Agile Playbook là cuốn sách đã được Magestore nghiên cứu các phương pháp Retro hay được sử dụng nhất. Bản chất, Retro là dịp để chúng ta tâm sự sau 1 tuần làm việc, hãy nghĩ đây là buổi Bonding về mặt tinh thần cho anh em trong team, chúng mình sẽ thực hiện một cách willing/nhẹ nhõm hơn. Hy vọng với guideline này, các bạn sẽ điều phối các buổi họp team hiệu quả hơn! Thank mọi người nhé <3
|
