Để có thể đánh giá xem một công ty có “Agile” hay không là rất khó. Một công ty có thể “Agile” trong một số khía cạnh nhưng lại có thể không linh hoạt ở những khía cạnh khác. Và ngay cả khi một tổ chức “Agile” ở một khía cạnh nào đó, nó vẫn có thể phải nỗ lực nhiều trong những khía cạnh khác. Vì vậy, không có câu trả lời đơn giản, hoàn hảo nào cho việc một công ty có khả năng “Agile” hay không. Khái niệm “Agile” có tính liên tục. Một số công ty rất “Agile” trong việc phát triển phần mềm, trong khi những công ty khác không như thế nhưng họ vẫn đang cố gắng cải thiện.

Tuy nhiên, có một cách nhanh chóng để đánh giá liệu một tổ chức “Agile” ở mức vừa phải hay không và cố gắng cải thiện nó sẽ giúp ích rất nhiều. Ví dụ, một ứng viên xin việc có thể muốn biết liệu một công ty có “Agile” hay không trước khi quyết định làm việc tại công ty đó.

Để giúp đỡ trong những tình huống trên và tương tự, tôi muốn đưa ra một bộ câu hỏi nhỏ có thể tiết lộ mức độ “Agile” của một tổ chức (một công ty hoặc nhóm).

Tôi quyết định chỉ giới hạn trong 3 câu hỏi. Số lượng câu hỏi lựa chọn là tuỳ ý. Nhưng tôi đã cố tình muốn một số lượng câu hỏi đủ nhỏ để nếu một người nào đó khi phỏng vấn cho một vị trí có thể hỏi ứng viên trong lúc phỏng vấn.

Đánh giá chức năng nhóm Agile

Câu hỏi 1: Tần suất nhóm của bạn có thể thống nhất về việc ra mắt sản phẩm?

Với câu hỏi đầu tiên này, tôi muốn biết liệu các nhóm có đa chức năng và được xây dựng theo cách cho phép họ thực hiện tốt công việc thường xuyên không, Trước tiên tôi nghĩ về việc hỏi tần suất ra mắt sản phẩm mới cho khách hàng, Nhưng câu trả lời cho điều đó thực sự ít thông tin hơn vì nó phụ thuộc rất nhiều vào mức độ thường xuyên khách hàng muốn có một sản phẩm mới, Ví dụ: tôi thích khi bất kỳ sản phẩm SaaS nào tôi sử dụng cũng đều được thêm các tính năng mới. (Giả sử chúng có các tính năng tôi muốn và không hề phóng đại). Amazon – công ty mà tôi cho rằng nhận được nguồn chi của tôi – có thể cập nhật trang web của mình nhiều lần trong ngày và tôi hài lòng vì điều đó. Trường hợp tương tự nhưng không đúng, ví dụ đối với một nhà sản xuất điện thoại di động. Nếu tôi vừa mới mua một chiếc iPhone mới, tôi sẽ rất thất vọng nếu Apple phát hành hai mẫu điện thoại mới ngay trong khi tôi lái xe về nhà từ cửa hàng Apple. Vì vậy, tần suất phát hành sản phẩm thực sự có thể không cho tôi biết nhiều về khả năng của tổ chức. Tôi quan tâm nhiều đến tần suất mà chúng tích hợp hoàn toàn. Điều đó cho tôi biết tần suất tổ chức có thể ra mắt sản phẩm nếu khách hàng có nhu cầu.

Đánh giá cam kết lãnh đạo Agile

Câu hỏi 2: Làm thế nào để bạn ứng phó nếu có một cuộc khủng hoảng hoặc vấn đề khiến cho bạn không đạt được hạn chót hoặc cột mốc theo kế hoạch?

Một trong những chỉ số dự báo về việc tổ chức tin tưởng vào “Agile” như thế nào là cách nó phản ứng khi có một khủng hoảng xảy ra.

Nếu vì một lý do nào đó, một nhóm không thể hoàn thành được một cột mốc đã được thống nhất trước đó, dựa trên phản ứng của tổ chức mà nói, thì “chúng tôi không có thời gian cho mấy thứ như “Agile”; chúng ta cần phải giải quyết deadline?” Hay các nhân viên nhận ra rằng xảy ra khủng hoảng là thời điểm để khuyến khích “Agile” hơn nữa?

Hỏi về cách tổ chức đối phó với khủng hoảng như vậy cho thấy nếu “Agile” là một kì vọng hay chỉ là một cái gì đó lãnh đạo muốn thử.

Phát hiện những hoạt động Agile khác thường bị khuất

Câu hỏi 3: Hãy cho tôi biết người bạn nghĩa là Scrum Master hay Product Owner tốt nhất. Yêu cầu được nghe về người mà ai đó nghĩ là Scrum Master hoặc Product Owner tốt nhất tiết lộ rất nhiều về cách mọi người trong công ty đó nghĩ về nhanh nhẹn.

Khi hỏi về một Scrum Master giỏi, tôi chỉ đang muốn tìm một số vấn đề cụ thể đáng chú ý. Ví dụ: Scrum Master trong tổ chức có phổ biến trong quá nhiều nhóm không? Có tranh luận về vai trò của Scrum Master có cần là toàn thời gian không, nhưng một nhà quản lý nói với tôi rằng Scrum Master tốt nhất của họ đang làm việc với 20 nhóm.

Một điểm khác cần phải chú ý đó là về một Scrum Master quá chỉ huy hoặc quá nguyên tắc. Hoặc mặc dù tuyên bố sử dụng Scrum, tổ chức đã quyết định cho phép các nhà quản lý dự án giữ lại danh hiệu của mình thay vì đổi tất cả thành Scrum Masters.

Như với câu trả lời về một Scrum Master tuyệt vời, có những điểm phải lưu ý khi ai đó đang mô tả một product owner tuyệt vời.

Có lần khi tôi hỏi để biết thêm về một product owner tuyệt vời trong tổ chức, tôi đã được kể về một người có thể đảm nhận vai trò product owner mà không ảnh hưởng đến công việc thực sự của cô ấy. Đó chắc chắn là một điểm cần phải lưu ý.

Tương tự như vậy, tôi sẽ hy vọng được nghe về một product owner tham gia với các nhóm trong các quy trình lặp lại của họ thay vì chỉ lập kế hoạch và tham gia các cuộc họp. Nếu tôi không làm thế chắc chắn sẽ còn nhiều điểm phải lưu ý hơn nữa.

Ba câu hỏi tuy không đủ phản ánh hết nhưng nó là sự bắt đầu

Chắc chắn chúng ta không thể biết một tổ chức “Agile” như thế nào chỉ với ba câu hỏi. Với thời gian cho một cuộc phỏng vấn kỹ lưỡng hơn, bạn có thể có được một cái nhìn đầy đủ và sắc thái hơn về một tổ chức “Agile”.

Nhưng tôi nghĩ ba điều này cung cấp ít nhất một nền tảng vững chắc cho quan điểm của bạn. Bạn có thể sử dụng chúng để quyết định xem xét việc nhận một công việc trong tổ chức đó có đáp ứng mong đợi của bạn về “Agile” hay  không. Tôi đã sử dụng những câu hỏi này trước khi tham gia cuộc hẹn đầu tiên với khách hàng để biết những gì có thể mong đợi được trước khi tôi bắt đầu.

Bạn có câu hỏi gì không?

Bạn nghĩ gì về ba câu hỏi của tôi? Công ty của bạn sẽ trả lời chúng như thế nào? Nếu bạn chỉ có thể hỏi ba câu hỏi để đánh giá tính “Agile” của tổ chức, bạn sẽ hỏi gì? Hãy chia sẻ suy nghĩ của bạn bằng cách bình luận bên dưới.

Xem thêm

MỌI KIẾN THỨC VỀ PMP^®

Agile Gaps in PMP® exam