Thông thường khi gặp kiến thức mới, bộ não sẽ tìm kiếm các mối liên hệ với những gì đã biết để hiểu và ghi nhớ nhanh hơn. Vì vậy khi tiếp cận về OKR tại kways.vn , do đã có kinh nghiệm thực hành Agile/Scrum trước đó nên bản thân mình cũng có xu hướng so sánh 2 phương thức quản trị này, như một cách đẩy nhanh việc tiếp thu kiến thức và chuyển đổi mindset. Dưới đây là những cảm nhận sau những ngày đầu “nhồi” lý thuyết OKR và chuẩn bị đi vào thực hành.

1. Vòng lặp tăng trưởng: Sprint vs Cycle

Trong Agile/Scrum là vòng lặp: Planning → Deliver (Daily Standup) → Review → Retro tạo thành các Sprint. Output của Sprint trước sẽ là Input cho Sprint sau để đóng góp vào quá trình phát triển sản phẩm.

Tương tự với OKR là vòng lặp: Setting Objectives & Key Results → Deliver (Checkin) → Retro tạo thành các chu kỳ (Cycle). Output của chu kỳ trước cũng sẽ là Input cho chu kỳ sau để đóng góp vào quá trình tăng trưởng của doanh nghiệp.

Về bản chất, có thể coi 2 vòng lặp trên là quá trình Thiết lập giả định → Thực thi giả định → Kiểm chứng giả định → Rút kinh nghiệm để lần Thiết lập giả định tiếp theo sẽ make sense hơn.

Điểm khác cơ bản là thời lượng vòng lặp Sprint của Agile/Scrum (trung bình 2 tuần) ngắn hơn nhiều so với vòng lặp chu kỳ của OKR (trung bình 3 tháng). Vì vậy, Agile/Scrum hướng tới kết quả ngắn hạn còn OKR là dài hạn. Cho nên trước mắt Agile/Scrum (có vẻ) tạo cảm giác gấp rút và hardcore hơn so với OKR (vì Sprint cỡ 2 tuần vèo cái là phải có kết quả để Review ).

2. Scrum Master vs OKR Master, Product Owner vs ?

Đây đều là 2 vị trí quan trọng nhằm đảm bảo việc triển khai Agile/Scrum và OKR được áp dụng đúng đắn và hiệu quả. OKR Master và Scrum Master đều cần đóng vai trò như một người servant leader (lãnh đạo mang tính hỗ trợ), hướng tới việc sử dụng sức ảnh hưởng (influence) hơn là quyền lực (power), tức là lắng nghe + giải đáp + hỗ trợ thay vì áp đặt + kiểm soát.

Tuy nhiên trong khi Agile/Scrum cần có Product Owner với trách nhiệm tối đa hóa giá trị do Delivery Team tạo ra, thì với OKR vai trò này (có vẻ) được phân bổ tới từng cá nhân. Bởi vì OKR hướng tới trách nhiệm giải trình cho từng cá nhân. Tức là khi bản thân đã đặt ra OKR mục tiêu cá nhân, bạn cần có trách nhiệm với giá trị công việc mà bản thân mình tạo ra, chứ không thể trông đợi ai cả.

Xem thêm: Vai trò quan trọng của OKR Master trong tổ chức

3. Niềm tin

Theo mình thấy, Agile/Scrum và OKR đều sẽ cần một khoảng thời gian rất dài (có thể tính bằng năm) để giúp đội ngũ thực hành thành thạo và cảm nhận được hết ý nghĩa và giá trị của nó tạo ra.

Cho nên, sẽ có những lúc bản thân thành viên tham gia Agile/Scrum và OKR cảm thấy mù mờ, chưa hiểu rõ tại sao mình phải làm cái này cái kia, kiểu “Vì Scrum Master/OKR Master bảo em làm thì em làm theo thôi” .

Vì vậy trong thời gian đầu khi triển khai, đội ngũ sẽ cần đến niềm tin rất lớn để thực hành, thử sai. Tức là một dạng “Fake it until you make it”, nói nôm na là tinh thần “Kệ m* nó, cứ làm đi rồi biết”

Trên đây là vài cảm nhận đầu tiên mà mình ghi lại, có thể coi là một dạng nhật ký OKR. Để sau này khi bước vào thực hành và hiểu rõ OKR hơn thì mới thấy, những ngày đầu mình đã tỏ ra nguy hiểm (hoặc ngây ngô) như nào