Chúng ta có bỏ lại những lo ngại về trách nhiệm giải trình và ROI khi áp dụng quy trình liên tục hoặc phân phối lặp lại không? Các số liệu linh hoạt cung cấp cho chúng tôi cái nhìn sâu sắc về cách thức hoạt động của quy trình để chúng tôi có thể thấy rõ các lĩnh vực cần cải thiện và can thiệp trước khi những trục trặc nhỏ trở thành rào cản lớn. Các nhóm Agile quan tâm không chỉ đến kết quả của những gì họ cung cấp mà còn cả cách thức phân phối nó.
KPI và ROI linh hoạt
Trước khi chúng ta bắt đầu khám phá các số liệu Agile để đo lường cụ thể các nhóm, điều quan trọng là phải nhắc nhở bản thân rằng các dự án Agile vẫn tuân theo các thước đo thành công kiểu cũ.
Các số liệu kinh doanh, KPI (các chỉ số chính của dự án) và bằng chứng cơ bản về lợi tức đầu tư (ROI) vẫn quan trọng trong môi trường Agile, vì vậy chúng tôi phải theo dõi các số liệu đó cũng như các số liệu Agile của mình. Những điểm dữ liệu này đặc biệt quan trọng trong quá trình thí điểm Agile, khi bạn đang muốn chứng minh tác động của một thay đổi nghiêm trọng, cụ thể là việc chuyển sang quản lý công việc bằng phương pháp Agile.
Nếu trước đây bạn chưa theo dõi các số liệu hiệu suất cơ bản cho nhóm của mình thì sẽ rất khó để định lượng tác động của việc triển khai Agile. Vì vậy, ngay cả trước khi bạn chọn số liệu Agile phù hợp, hãy đảm bảo rằng bạn đã đặt nền tảng cho việc đo lường hoạt động tiếp thị của mình.
Năm số liệu Agile đáng đo lường
Bây giờ chúng ta đã đề cập đến những điều cơ bản, đã đến lúc đi vào các số liệu dành cho nhóm Agile . Chúng tôi sẽ đề cập đến năm lựa chọn khác nhau, hầu hết trong số đó sẽ áp dụng cho bất kỳ loại nhóm nào. Đối với những phương pháp phù hợp nhất với một phương pháp cụ thể , chúng tôi chắc chắn sẽ lưu ý điều đó trong quá trình giải thích.
Khi chọn số liệu Agile nào để theo dõi, hãy nhớ rằng rất khó để tối ưu hóa thứ gì đó mà bạn không đo lường. Nhưng bạn cũng không muốn lãng phí hàng giờ đồng hồ để lấy số. Hãy xem xét những gì bạn sẽ làm với dữ liệu bạn thu thập và liệu bộ công cụ hiện tại của bạn có cung cấp cho bạn quyền truy cập dễ dàng vào thông tin bạn đang theo dõi hay không. Nếu bạn không định hành động theo số liệu của mình hoặc việc thu thập số liệu đó phức tạp, bạn có thể muốn thử số liệu khác.
Agile velocity
Agile velocity chỉ đơn giản đo lượng công việc mà một nhóm hoàn thành trong một khoảng thời gian nhất định, thường là chạy nước rút hoặc lặp lại. Nó thường được tính bằng điểm, có nghĩa là nó yêu cầu nhóm xác định quy mô từng phần công việc mà họ đưa vào sprint backlog của mình.
Bất kỳ nhóm Agile nào sử dụng các bước lặp được đóng khung theo thời gian đều có thể đo được vận tốc của họ. Điều này có nghĩa là cả nhóm Scrum và Scrumban đều có thể dễ dàng sử dụng số liệu Agile này, mặc dù nó thường không hoạt động tốt khi triển khai Kanban.
Về cốt lõi, mục tiêu của việc đo tốc độ là để xem liệu nhóm có tiến bộ theo thời gian hay không, nhưng nó có thể bị lạm dụng. Nếu vận tốc trở thành một đòn bẩy để đánh bại cả nhóm, họ có thể bắt đầu đánh lừa những ước tính của mình để có vẻ như họ đang làm được nhiều việc hơn ngay cả khi thực tế không phải như vậy. Hãy đảm bảo rằng vận tốc chỉ đơn giản là một cuộc kiểm tra sức khỏe cho cả nhóm chứ không phải là một kỳ vọng vô lý.
Khi bạn theo dõi vận tốc, hãy tìm bất kỳ khoảnh khắc thất thường nào. Nếu những điều này trở thành chuẩn mực chứ không phải là ngoại lệ, hãy giúp nhóm điều tra nguyên nhân gốc rễ. Một số câu hỏi hồi tưởng có thể bao gồm:
- Có những thách thức không lường trước được mà chúng ta chưa tính đến khi ước tính công việc này không?
- Làm thế nào chúng ta có thể chia nhỏ công việc tốt hơn để khám phá một số thách thức này?
- Có áp lực kinh doanh bên ngoài đẩy nhóm vượt quá giới hạn của nó không?
- Kết quả là việc tuân thủ các phương pháp hay nhất có bị ảnh hưởng không?
- Với tư cách là một nhóm, chúng ta có quá hăng hái trong việc dự báo cho sprint không?
Burndown chart
Vận tốc là một chỉ báo theo sau—nó sẽ không cung cấp cho bạn bất kỳ dữ liệu nào về một lần lặp cho đến khi nó kết thúc. Mặt khác, biểu đồ burndown cung cấp cho bạn dữ liệu hàng ngày về tình hình hoạt động của nhóm trong suốt giai đoạn chạy nước rút.
Giống như vận tốc, biểu đồ phân tích hiệu quả yêu cầu ước tính các dự án đang được sử dụng.
Tại đây, nhóm đã cam kết đạt 160 điểm, và khi thời gian trôi qua và họ hoàn thành một số công việc của mình, biểu đồ sẽ “cháy hết” cho đến khi nước rút kết thúc. Tại thời điểm đó, hy vọng họ sẽ không còn công việc nào nữa và các thanh dọc sẽ biến mất.
Biểu đồ Burndown rất hữu ích đối với các nhóm Agile trẻ, những người cần một số hướng dẫn về mức độ họ thực sự có thể hoàn thành trong mỗi lần chạy nước rút. Họ có thể cho chúng tôi biết nếu:
- Nhóm không cam kết thực hiện đủ công việc vì biểu đồ burndown của họ “cháy hết” từ đầu sprint này đến sprint khác.
- Nhóm đang cam kết quá nhiều vì họ còn nhiều điểm trên biểu đồ của mình vào cuối mỗi lần chạy nước rút.
- Nhóm không chia công việc thành những phần đủ nhỏ vì đường burndown tạo ra những bước nhảy vọt thay vì giảm dần.
- Những gián đoạn bên ngoài đang làm nhóm chệch hướng vì đường thẳng đứng biểu thị các điểm đi lên giữa chặng nước rút khi công việc mới được thêm vào.
Khi nhóm ổn định và hoàn thành khối lượng công việc ổn định, biểu đồ burndown có thể trở nên ít hữu ích hơn. Tất nhiên, thật khó để có được những loại số liệu này về trước, vì vậy việc giữ chúng trong tầm kiểm soát có thể giúp giải quyết các vấn đề trước khi chúng vượt quá tầm kiểm soát.
Biểu đồ suy giảm chiến lược hàng quý/chiến lược
Biểu đồ đốt cháy cung cấp thông tin chi tiết về mọi thứ đang diễn ra như thế nào trong một lần lặp cụ thể, nhưng chúng tôi cũng cần đảm bảo rằng chúng tôi đang từng bước hướng tới các mục tiêu lớn hơn.
Trong nhóm phần mềm Agile truyền thống, quỹ đạo này có thể được theo dõi thông qua biểu đồ hoành tráng hoặc biểu đồ phát hành. Trong nhóm tiếp thị Agile , họ thích gọi nó là biểu đồ chiến lược hoặc biểu đồ phân tích hàng quý. Đây là cái nhìn dài hạn hơn về những gì nhóm đang làm và nó liên quan như thế nào đến chiến lược theo thời gian.
Bạn có thể thấy trong biểu đồ trên rằng một số mục mới đã được thêm vào lượng tồn đọng lớn hơn của nhóm sau mỗi lần chạy nước rút. Mặc dù chúng tôi không cho phép điều đó xảy ra với một sprint tồn đọng ở giữa quá trình lặp lại, nhưng điều đó hoàn toàn có thể chấp nhận được trong bối cảnh này.
Theo thời gian, người quản lý và lãnh đạo có thể quyết định thêm hoặc bớt một số mục dựa trên những gì họ học được hoặc dựa trên việc thay đổi mục tiêu của tổ chức. Khi điều đó xảy ra, quá trình đốt cháy chiến lược giúp mọi người nhận thức được “sự thăng trầm của công việc” trong chiến lược dài hạn.
Việc theo dõi biểu đồ phân tích chiến lược có thể giúp bạn hiểu rõ hơn liệu công việc của nhóm có đang đóng góp tích cực cho các mục tiêu lớn hơn hay họ chỉ đang thực hiện công việc bận rộn.
Cờ đỏ cần chú ý trên biểu đồ này bao gồm:
- Dự báo chiến lược không được cập nhật khi nhóm thực hiện công việc
- Không có thay đổi nào được hiển thị sau vài lần lặp
- Sự leo thang phạm vi thường xuyên , có thể là dấu hiệu cho thấy các nhà lãnh đạo không hiểu đầy đủ vấn đề mà nhóm Agile đang cố gắng giải quyết
- Phạm vi chiến lược phát triển nhanh hơn mức nhóm có thể tiếp thu, nghĩa là họ sẽ không bao giờ có thể hoàn thành mục tiêu chiến lược
Thời gian chu kỳ
Cho đến nay, các số liệu Agile của chúng tôi chủ yếu liên quan đến công việc ở cấp độ nhóm, nhưng chúng tôi cũng có thể muốn biết thêm về việc nhóm phải mất bao lâu để hoàn thành các dự án nhỏ hơn. Thời gian chu kỳ có thể mang lại cái nhìn sâu sắc này
Thời gian chu kỳ chỉ đơn giản là đo khoảng thời gian cần thiết để hoàn thành một công việc nào đó từ đầu đến cuối. Joel Bancroft-Connors của AgileConnection gọi đó là “thời gian thực hành trên bàn phím”.
Tốt nhất, việc đo thời gian chu kỳ được thực hiện tự động thông qua phần mềm Agile hoặc công cụ bạn chọn, nhưng ngay cả việc đo thủ công cùng với bảng tác vụ vật lý hoặc bảng Kanban cũng sẽ cung cấp cho bạn dữ liệu hữu ích.
Chỉ cần theo dõi xem dự án/nhiệm vụ/câu chuyện mất bao lâu để được ghi vào cột “hoàn thành” sau khi nó được lấy ra khỏi hồ sơ tồn đọng. Mức trung bình cho tất cả công việc của bạn là thời gian chu kỳ của bạn.
Nó được đo ở cấp độ câu chuyện của người dùng (hoặc một nhiệm vụ hoặc dự án, tùy thuộc vào cách bạn cấu trúc bảng Agile của mình), vì vậy đây là số liệu chi tiết hơn nhiều so với bất kỳ thứ gì chúng ta thấy trên biểu đồ burndown.
Thời gian của chu kỳ cũng mang lại cho chúng tôi nhiều phản hồi tức thì hơn vì chúng tôi có thể thấy ngay kết quả của bất kỳ thay đổi nào. Khi chúng ta điều chỉnh hệ thống, thời gian chu kỳ sẽ tăng hoặc giảm ngay lập tức, nhờ đó chúng ta biết thử nghiệm thành công hay thất bại trong thời gian ngắn. Mục tiêu của chúng tôi là thời gian chu kỳ vừa nhất quán vừa ngắn, bất kể loại công việc đang được thực hiện.
Thời gian chu kỳ nhất quán có nghĩa là chúng tôi có thể dự đoán chính xác khi nào chúng tôi có thể phân phối từng phần công việc riêng lẻ, cho dù chúng tôi đang sử dụng dòng thời gian liên tục hay hộp thời gian giống như chạy nước rút để xử lý các dự án lớn hơn.
Agile team happiness
Số liệu Agile cuối cùng của chúng tôi hoàn toàn không liên quan đến quy trình Agile. Thay vào đó là cái nhìn về niềm hạnh phúc của cả đội.
Không cần bất kỳ hệ thống theo dõi ưa thích nào ở đây. Chỉ cần bắt đầu quá trình hồi tưởng của bạn bằng cách yêu cầu từng thành viên trong nhóm Agile cho điểm mức độ hạnh phúc của họ theo bất kỳ thang điểm nào bạn chọn. Sau đó theo dõi mức trung bình từ lần hồi cứu này đến lần hồi cứu tiếp theo.
Các nhóm vui vẻ tạo ra công việc tốt hơn, mang lại nhiều khách hàng hài lòng hơn, vì vậy đây thực tế là một thước đo kinh doanh quan trọng. Nhưng điều quan trọng là phải nhận ra rằng nếu tất cả các số liệu quy trình Agile của bạn đều hoàn hảo nhưng nhóm lại không hài lòng thì bạn đang gặp phải một số rắc rối. Nhóm có thể đang che giấu các vấn đề của mình trong khi vẫn duy trì hiệu suất cao, đồng nghĩa với việc tình trạng kiệt sức và doanh thu cao có thể sắp xảy ra.
Các thành viên mới của nhóm luôn làm gián đoạn nhóm Agile, vì vậy chúng tôi muốn giữ cho mọi người hài lòng và cấu hình nhóm ổn định bất cứ khi nào có thể.
Mất bao lâu để theo dõi số liệu Agile
Bạn có thể quyết định theo dõi một hoặc tất cả số liệu mà chúng ta đã thảo luận cho đến nay, nhưng bất kỳ sự kết hợp nào bạn chọn đều đảm bảo bạn nhận được nhiều thông tin hơn là một ảnh chụp nhanh ngắn gọn. Theo dõi số liệu trong ít nhất sáu tháng để xác định các xu hướng lớn hơn.
Điều đó không có nghĩa là bạn không thể thực hiện bất kỳ hành động nào đối với những phát hiện của mình cho đến khi sáu tháng trôi qua (điều đó sẽ không linh hoạt lắm). Nhưng việc xem xét liên tục các điểm dữ liệu khác nhau này có thể giúp bạn biết điểm này tác động đến điểm khác như thế nào.
Những cạm bẫy số liệu linh hoạt cần tránh
Trước khi bạn bắt đầu đo lường các số liệu Agile, hãy cân nhắc thực hiện những việc sau:
- Giữ các số liệu Agile trong các nhóm. Cả nhóm lẫn người quản lý đều không nên so sánh số liệu giữa các nhóm và điều đó áp dụng cho mọi thứ, từ tốc độ đến mức độ hạnh phúc. Những số liệu này chỉ dành cho từng nhóm.
- Hãy đo lường, đừng nhắm mục tiêu. Khi một biện pháp trở thành mục tiêu thì nó không còn là biện pháp tốt nữa. Mục tiêu của số liệu Agile là phát hiện và hiểu các xu hướng chứ không phải tạo ra những con số kỳ diệu mà nhóm cố gắng đạt được bằng mọi giá.
