Bạn có bao giờ gặp những tình huống nhóm của mình đang đối mặt với những khó khăn, hay vấn đề không thể lường trước được. Lúc đó, thay vì tập trung tìm kiếm giải pháp thì các thành viên lại quay sang tập trung vào việc tìm hiểu vấn đề đến từ đâu. Rồi vì tập trung vào những lý do của vấn đề, mọi người vô tình quay sang chỉ trích, trách móc lẫn nhau? Không khí căng thẳng lên, mọi người bắt đầu mâu thuẫn, cãi vã nổi lên trong nhiều giờ liền, trong khi vấn đề vẫn chưa được giải quyết? Câu chuyện này có thể là một câu chuyện không mới, mà nhiều khi còn là chuyện “bình thường ở huyện” của rất nhiều Scrum team.
 
 
Vì sao lại như vậy? Từ đâu mà việc nhìn thẳng vào vấn đề và giải quyết mọi thứ từ cội nguồn, nghe có vẻ có lý lại trở nên khó khăn, và tạo ra nhiều ảnh hưởng tiêu cực đến vậy? Câu trả lời cho chuyện này là đến từ mức độ phức tạp của vấn đề bạn hay nhóm mình đang gặp phải. Ở những môi trường làm việc đơn giản, mọi thứ gần như rõ ràng thì khi vấn đề xuất hiện, truy cứu và giải quyết chúng sẽ dễ dàng và là cách tốt nhất để đưa công việc về lại kết quả tốt.

Ví dụ: Bạn có một công thức làm cơm chiên, và đã được ghi rõ các bước và định lượng nguyên liệu. Bạn cũng đã được ăn thử món ăn làm bởi công chức chi tiết này. Vậy nếu khi bạn dựa theo công thức mà làm để có được món cơm chiên, mà khi làm xong thì cơm không được ngon như mong đợi. Lúc này việc xem lại bạn đã làm sai bước nào trong công thức sẽ là cách hữu ích và nhanh chóng nhất để bạn có thể làm lại và nấu ra món cơm mà mình muốn.

Nhưng khi gặp phải những vấn đề phức tạp (Complex), trong một môi trường phức tạp thì sao? Lúc này sẽ có rất nhiều ẩn số, và kết quả sẽ luôn bị chi phối bởi nhiều yếu tố tiềm ẩn khác nhau, không có câu trả lời nào đúng cho tất cả, khiến việc tìm hiểu nguồn gốc của vấn đề thường trở nên vô ích.

 
Định nghĩa Complex theo từ điển Cambridge
 
Lấy ví dụ: Bạn và nhóm đã lên kế hoạch chi tiết cho Sprint tiếp theo. Nhưng giữa Sprint thì kế hoạch đề ra đã không đúng, và cần nhiều gấp đôi thời gian để hoàn thành. Lúc này bạn sẽ làm gì? Nếu truy vấn đề điều gì đã làm cho kế hoạch cần gấp đôi thời gian, chúng ta thường sẽ bị lạc lối, vì có rất nhiều vấn đề tiềm ẩn có thể ảnh hưởng đến kế hoạch: ​mức độ phức tạp của công việc, khả năng hiện tại của team, tinh thần của các thành viên trong những ngày qua, các thành viên có đang multitasks,Technical Debt … Khi những câu hỏi truy vấn được đặt ra: Vì sao kế hoạch lại không đúng? Sao không ai nói về mức độ phức tạp trước đây? Anh A, chị B sao không tập trung vào việc của team mình thôi? Những câu hỏi này sẽ là mồi lửa kích hoạt những vấn đề tranh cãi cá nhân sau đó, mất đoàn kết. Bởi lẽ không có một câu trả lời nào phù hợp cho vấn đề “vì sao team cần gấp đôi thời gian cho việc xây dựng” cả, nên việc tập trung vào root cause lúc này là vô nghĩa. Thay vào đó,  bạn hãy hướng cái nhìn vào giải pháp bằng cách đặt đúng câu hỏi: Chúng ta đang cần kết quả thế nào? Làm thế nào để chúng ta có thể đạt được kết quả đó?
 
 

Tư Duy Hướng Đến Giải Pháp cần cho Scrum không?

Việc tập trung vào tìm hiểu root cause thường sẽ khiến chúng ta đi lạc và chỉ nhìn vào những vấn đề một cách tiêu cực. Giống như việc bạn đang chạy xe trên đường đèo, một bên là vực thẳm và lúc nào cũng lo sợ nghĩ rằng mình sẽ rơi xuống vậy. Thay vào đó, hướng cái nhìn vào con đường và mục tiêu phía trước sẽ giữ cho bạn đi đúng hướng và an toàn hơn. Scrum cũng vậy! Scrum được xây dựng trên chủ nghĩa kinh nghiệm: Transparency, Inspection, Adaptation. Chủ nghĩa kinh nghiệm giúp chúng ta, Scrum team giải quyết những vấn đề phức tạp. Nhưng Scrum không phải là giải pháp, mà nó chỉ giúp làm rõ, hiện ra những vấn đề đang được ẩn đi một cách cố tình hay vô tình. Sau đó trách nhiệm để giải quyết chúng là trách nhiệm của Scrum team.

Lúc này, như ví dụ ở trên tôi đã chia sẻ, nếu một Scrum team có thiên hướng tập trung vào việc tìm root cause thường sẽ gặp phải những vấn đề ở đầu bài hơn là tập trung vào giải pháp, khi đối mặt với tình huống phức tạp (Complex). Vậy chìa khoá ở đây là, chúng ta cần áp dụng Chủ Nghĩa Kinh Nghiệm cùng với Tư Duy Hướng Đến Giải Pháp (Solution Focused). Như vậy Chủ Nghĩa Kinh Nghiệm sẽ được định lại đúng hướng mà nó thuộc về, là tập trung vào giải pháp:

 

Transparency: Minh bạch về tình huống nhóm đang phải đối mặt.Inspection: Đưa ra giải pháp làm thế nào để vượt qua tình huống hiện tại.Adaptation: Thực thi giải pháp đã đồng thuận.​

 

​Chỉ hiểu khái niệm là không đủ, bạn sẽ cần nhiều hơn

Nếu bạn một Scrum Master, nhận ra được thay đổi cách tiếp cận giải quyết vấn đề thành tập trung vào giải pháp là chìa khoá cho Scrum team của mình thì xin chúc mừng bạn! Nhưng như vậy là chưa đủ, vì bản thân của chúng ta không thể thay đổi cách nghĩ chỉ sau một vài dòng blog. Bạn cần thời gian để thay đổi, tự trau dồi và giúp cho các thành viên khác cùng thay đổi. Việc thay đổi chính mình đã không dễ dàng, thì việc giúp người khác thay đổi sẽ càng khó khăn hơn. Lúc này có thể bạn sẽ tự hỏi: Vậy sẽ cần làm như thế nào?

Tôi đã tìm được câu trả lời trong Coaching (Khai mở), và kỹ năng Coaching đã giúp tôi có thể giúp cho những cá nhân đội nhóm, thay đổi tích cực hơn mỗi ngày, mỗi giờ để nhận được giá trị mình muốn. Là một Scrum Master, hay Agile Leader bạn cũng sẽ mang lại được giá trị tương tự như vậy cho Scrum team của mình qua Coaching (Đọc thêm: Scrum Master như là một Coach (người khai vấn)). Hơn hết khi việc khai vấn còn được tập trung và giải pháp, nó sẽ còn phù hợp và trở nên mạnh mẽ hơn bao giờ hết cho việc tối ưu hỗ trợ chủ nghĩa kinh nghiệm trong Scrum team. Đó cũng là lý do vì sao tôi đã chọn Solution Focused Coaching, và áp dụng vào Scrum, song song. Qua đó giúp các cá nhân, đội nhóm có thể nhận được giá trị cao nhất từ Scrum, và Coaching mang lại.

Hi vọng bài viết này đã giúp bạn hiểu rõ phần nào giá trị của việc tập trung vào giải pháp, và qua đó giúp cho Scrum team của mình nhận được nhiều giá trị hơn bằng việc tập trung vào những gì có thể.

 

Leave a Reply