Lời đồn 11: Trong Scrum, chúng ta dành quá nhiều thời gian vào cuộc họp

Khi Scrum được giới thiệu, nhóm phát triển có xu hướng nhiệt tình nắm lấy nó. Scrum thúc đẩy các nhóm tự tổ chức, tự trị, đa ngành và thừa nhận những phẩm chất cá nhân và đóng góp cho nỗ lực của một nhóm. Ai không muốn tham gia Scrum Team? Tuy nhiên khá thường xuyên, sau kỳ trăng mật với Scrum, mọi người bắt đầu đưa ra vấn đề:

• Kể từ khi giới thiệu Scrum, tất cả những gì tôi làm là tham dự các cuộc họp. Tôi đã không trở thành một nhà phát triển để tham dự các cuộc họp cả ngày dài
• Với Scrum tôi hy vọng chúng ta sẽ có được một nền văn hoá nhóm, nhưng thay vào đó nó cảm thấy giống như một nền văn hóa hội họp
• Tôi nghĩ Scrum cuộc họp đã được giới hạn thời gian, nhưng Scrum hàng ngày của chúng tôi có ít nhất 30 phút và sau đó chúng tôi vẫn không có một kế hoạch vững chắc như một đội

Những thất vọng này đẩy một số đội Scrum bỏ Scrum hoàn toàn. Hôm nay, chúng ta sẽ phá vỡ ý tưởng Scrum là một nguồn cơn của một văn hóa họp hành . Một nền văn hoá mà trong đó các đội Scrum bị mắc kẹt trong quá nhiều cuộc họp không hiệu quả ngăn cản họ tạo ra một sản phẩm có giá trị cho khách hàng của họ.

Phá vỡ lời đồn

Hướng dẫn Scrum mô tả năm sự kiện Scrum (không phải 'các cuộc họp') tạo ra sự thường xuyên và giảm thiểu nhu cầu các cuộc họp không được định nghĩa trong Scrum. Mỗi sự kiện có một mục đích rõ ràng và đóng một vai trò quan trọng trong chu trình kiểm tra và thích nghi của Scrum. Các sự kiện được đóng gói theo thời gian, có nghĩa là họ có thời lượng tối đa.

Hãy giải quyết hai vấn đề đằng sau câu chuyện thần thoại này một cách riêng biệt:

Thực tế, làm thế nào tốn nhiều thời gian là những sự kiện Scrum? Chúng ta có nên dành thời gian cho những sự kiện này không?

Thực tế, những sự kiện Scrum tốn thời gian như thế nào ?

Các hộp thời gian được quy định cho Sprint 1 tháng. Đối với Sprints ngắn, sự kiện này thường ngắn hơn. Hộp thời gian là:

• Daily Scrum: 15 phút;
• Sprint Planning: tối đa 8 giờ;
• Sprint Review: tối đa 4 giờ;
• Sprint Retrospective: tối đa 3 giờ;

Hoạt động tinh chỉnh Backlog sản phẩm yêu cầu trung bình 10% năng lực của Nhóm phát triển. Xem xét các hộp thời gian này, Scrum không có vẻ là một khuôn khổ nên kết quả là một văn hoá hội họp. Đối với nhà phát triển toàn thời gian trong Sprint 4 tuần, sự kiện Scrum mất tối đa 22,5% thời gian:

• Toàn thời gian: 160 giờ cho mỗi Sprint
• Sự kiện Scrum: 20 giờ
• Kiểm tra backlog: tối đa 16 giờ

Nếu chúng ta hình dung được các sự kiện Scrum cho một Sprint 2 tuần thì nó không phải là quá xấu phải không?

Chúng ta có nên dành từng đó thời gian cho những sự kiện này không?

Scrum được xây dựng trên quan sát rằng phát triển phần mềm là một nỗ lực rất phức tạp. Khi chúng tôi làm việc cùng nhau, sự hiểu biết của chúng tôi về cả vấn đề và giải pháp phát triển. Điều này đòi hỏi sự hợp tác giữa những người đang làm việc. Bằng cách đưa quan điểm cá nhân, chuyên môn, sự sáng tạo và trí tuệ của mình, chúng tôi có cơ hội tốt hơn để hiểu được vấn đề phức tạp này mà chúng tôi đang cố gắng giải quyết. Trung tâm hợp tác này là các cuộc đối thoại, như Tobias Meyer đặt nó trong cuốn sách của ông "The People's Scrum". Cuộc trò chuyện về những gì đã được thực hiện, những gì cần được thực hiện tiếp theo và có hay không mà thực sự làm việc.

Scrum cung cấp một số ranh giới tối thiểu (năm sự kiện, ba vai trò, ba hiện vật) để có các cuộc trò chuyện thích hợp vào thời điểm thích hợp với những người thích hợp. Nó tập trung vào các cuộc đối thoại về những gì là quan trọng tại thời điểm đó, như là một phần của quá trình thực nghiệm của Scrum.

Dành thời gian vào các sự kiện Scrum rất có giá trị vì nó giúp chúng tôi lên kế hoạch cho công việc, sắp xếp công việc của chúng tôi với vấn đề mà chúng tôi đang cố gắng để giải quyết và liên tục cải tiến quy trình của chúng tôi thông qua phản hồi kịp thời. Trong lĩnh vực phức tạp của phát triển phần mềm, điều này không phải là một sang trọng nhưng là một điều cần thiết.

Nguồn gốc của lời đồn này

1. Văn hoá cuộc họp đã có ở đó

Hình ảnh của Sprint 2 tuần với các sự kiện Scrum có lẽ không phải là thực tế cho nhiều đội Scrum. Hướng dẫn Scrum cho biết rằng các sự kiện Scrum nên được sử dụng để tạo ra sự thường xuyên và giảm thiểu nhu cầu các cuộc họp không được định nghĩa trong Scrum.

Nhưng các đội Scrum thường phải tham gia các cuộc họp bên ngoài các sự kiện Scrum thường lệ. Ví dụ: các buổi thuyết trình của công ty, các buổi chia sẻ kiến thức, cập nhật tiến độ để quản lý, họp mặt, các cuộc họp đánh giá hành động, các cuộc họp cadence về quản lý, các cuộc họp về các thế hệ sáng kiến, hội thảo, các buổi giải quyết vấn đề, các cuộc họp ra quyết định, các cuộc họp thu thập thông tin, người quản lý nhóm, giới thiệu, ra các cuộc họp giải quyết, cộng đồng về các cuộc họp thực hành, các buổi tập huấn vv Các cuộc họp, các cuộc họp, các cuộc họp và các cuộc họp nữa. Điều này làm cho lịch trình Sprint gọn gàng của chúng tôi trở nên phức tạp hơn:

Các sự kiện Scrum thực sự là vấn đề ở đây hay Scrum đơn giản chỉ làm cho văn hoá hội nghị hiện tại minh bạch? Tất cả các cuộc họp này thực sự là cần thiết? Hoặc họ chỉ là kết quả của việc triển khai không tối ưu của Scrum, với những người tham gia vào nhiều đội, những đội không thực sự có chức năng chéo (và có nhiều sự phụ thuộc) và những chủ sở hữu sản phẩm mà không có sự ủy thác thực sự. Đây là nơi mà vai trò của Scrum Master trở nên quan trọng; giúp xác định những cuộc họp đó không cần thiết, và loại bỏ chúng khỏi lịch trình. Giúp tổ chức tìm ra các cách khác để tổ chức công việc phù hợp hơn với Scrum, do đó có thể giảm thiểu được sự cần thiết cho các cuộc họp bổ sung

2. Thiếu sự tạo điều kiện thuận lợi cho các sự kiện Scrum

Nếu chúng ta quyết định dành thời gian vào một sự kiện Scrum, cần tạo điều kiện thuận lợi theo cách tôn trọng đầu tư đó. Trong thực tế, hầu hết các sự kiện Scrum được tạo điều kiện một cách khá nhàm chán. Đánh giá Sprint là một bài trình bày dài các tính năng mới, không có cơ hội để tương tác và khám phá. Kế hoạch Sprint có đội ngũ ngồi xung quanh một bảng trong bốn giờ tốt, lắng nghe hai người mà hầu hết các nói chuyện. Daily Scrum đã tham gia vào các cuộc thảo luận chuyên sâu giữa một vài người, chạy đến 30 phút hoặc hơn. Và bởi vì không sàng lọc được thực hiện trong Sprint, Sprint Planning có xu hướng kéo và trên như là công việc được xác định và chia nhỏ.

Việc tạo điều kiện thuận lợi đòi hỏi phải tập trung vào mục đích của sự kiện và sự tôn trọng của khung thời gian. Chúng ta nên nói chuyện gì? Làm thế nào chúng ta có thể có những cuộc hội thoại theo những cách hiệu quả hơn việc ngồi quanh bàn, lắng nghe một vài người? Vai trò của người hướng dẫn là để giữ cho các cuộc đối thoại về chủ đề, để tạo ra một không khí an toàn và để thúc đẩy thảo luận cởi mở. Nếu không có sự chuẩn bị thích hợp và tạo thuận lợi cho các sự kiện Scrum sẽ là (và cảm thấy như) một sự lãng phí thời gian.

3. Thành viên bán thời gian hoặc những người thuộc nhiều đội

Đối với các thành viên bán thời gian của đội Scrum, các sự kiện Scrum rõ ràng sẽ tiêu thụ một phần lớn hơn trong tuần làm việc của họ. Điều này xảy ra khi mọi người là một phần của nhiều đội, hoặc làm nhiều công việc bên ngoài đội của họ. Một số người có kỹ năng khan hiếm cần thiết cho một số Đội Scrum - như quản trị cơ sở dữ liệu hoặc nhà phát triển 'rockstar'. Nếu người đó phải tham gia mọi sự kiện Scrum, chắc chắn nó sẽ giống như một con quái vật gặp gỡ 5 đầu.

Scrum thực sự là vấn đề ở đây? Hoặc Scrum chỉ đơn giản là lướt qua các chức năng tổ chức hiện tại - giống như ý tưởng đặt người vào càng nhiều đội càng tốt là "hiệu quả hơn" hoặc các tổ chức phụ thuộc vào các cá nhân có kỹ năng quan trọng.

4. 'Chỉ ngồi sau máy tính xách tay là công việc' (hoặc hiệu quả công việc tốt hơn)

Trong nhiều tổ chức, có một niềm tin mạnh mẽ rằng 'chỉ ngồi phía sau máy tính xách tay của bạn là công việc'. Đối với các nhà phát triển, điều này giống như nói rằng 'chỉ mã là công việc'. Những niềm tin này thường được củng cố bằng cách phân loại 'công việc máy tính xách tay' làm công việc có thể trả hóa đơn, trong khi các cuộc họp không thể lập hóa đơn. Các giả định cốt lõi ở đây là chúng tôi chỉ tạo ra giá trị khi ngồi phía sau máy tính xách tay của chúng tôi, và rằng chúng ta nên tối đa hóa thời gian này.

Ý tưởng rằng "chỉ ngồi phía sau máy tính xách tay là công việc" là một ý tưởng lỗi thời. Phát triển sản phẩm không phải là công việc thông thường. Chúng ta thường xuyên cần phải có cuộc đối thoại về nơi chúng ta đang đứng, để hiểu được những gì đang xảy ra và suy nghĩ xem bước kế tiếp có ý nghĩa gì. Những cuộc hội thoại này là cần thiết và có giá trị. Mặc dù có thể cảm thấy không hiệu quả để dành thời gian với toàn bộ nhóm trong một phòng ('đó là 3 giờ với 6 người, 18 giờ làm việc không phải trả tiền!'), Nó sẽ có hiệu quả hơn trong các kết quả mà nó sinh ra. Rốt cuộc, sự sáng tạo, sự khôn ngoan và chuyên môn của mọi người đã được sử dụng để đạt được một sự hiểu biết chung được thực hiện bởi tất cả mọi người. Chúng ta không cần phải dành thời gian sau cuộc họp nhằm tạo dựng sự đồng thuận, đưa các thành viên lên nhanh về những gì được quyết định hoặc khởi động lại cuộc hội thoại vì các thành viên không tham gia đưa ra những điểm tốt.

Lời khuyên

Bạn có thể làm gì để nâng cao hiệu quả của Scrum Events? Làm thế nào bạn có thể làm cho họ thú vị hơn? Dưới đây là một số mẹo, dựa trên kinh nghiệm của chúng tôi:

1. Không tổ chức cuộc họp. Tổ chức các hội thảo thúc đẩy các cuộc hội thoại

Các cuộc họp có mùi nhàm chán, tẻ nhạt và tiết kiệm năng lượng - một nhóm người ngồi xung quanh bàn đợi đồng hồ báo hiệu kết thúc cuộc họp. Thay vào đó, hãy làm cho các sự kiện Scrum của bạn thành một cái gì đó thú vị để làm, giữ năng lượng và thúc đẩy sự tương tác và các cuộc trò chuyện.

Tạo điều kiện cho các sự kiện như hội thảo chứ không phải là các cuộc họp. Bắt đầu với một mục tiêu rõ ràng và thiết kế một loạt các định dạng và kỹ thuật tạo thuận lợi để giúp đạt được mục tiêu đó. Sử dụng năng lượng để duy trì năng lượng và tạo bầu không khí tốt. Cho phép mọi người tham gia bằng cách sử dụng mô hình hội tụ phân chia các nhóm lớn theo cặp hoặc ba và cho họ tham gia lại để chia sẻ thông tin chi tiết. Đóng sự kiện bằng cách hỏi những gì nổi bật cho người tham gia; họ đã làm gì? Họ học gì? Những gì có thể được cải thiện để làm cho sự kiện này hiệu quả hơn?

2. Đưa các cuộc họp vào lịch trình của Nhóm Phát triển

Đối với hầu hết các nhà quản lý, tham dự các cuộc họp cả ngày dài là khá nhiều công việc của họ. Họ được sử dụng để đi từ một cuộc họp khác. Đối với một nhà phát triển, điều này là khác nhau. Viết phần mềm yêu cầu tập trung và tập trung không thể tin được. Có nhiều cuộc họp (bất thường) trong ngày - ngay cả khi chỉ một phút - phá vỡ tập trung và yêu cầu nhà phát triển xây dựng lại trọng tâm này. Quá trình này có thể mất 30 phút hoặc lâu hơn, ngay cả đối với các nhà phát triển có kinh nghiệm.

Paul Graham đã viết một bài đăng blog xuất sắc về vấn đề này trong "Lịch trình của Maker, Lịch trình của Người quản lý". Các sự kiện Scrum nên đã giảm thiểu sự cần thiết của các cuộc họp không được định nghĩa trong Scrum. Những cái còn lại cần được lên kế hoạch theo cách mà họ đưa ra cho Nhóm phát triển tập trung càng nhiều càng tốt và tránh việc chuyển đổi nhiệm vụ không cần thiết.

3. Thử các công trình giải phóng

Các cấu trúc giải phóng là 33 cấu trúc nhỏ cho phép bạn liên quan đến mọi người trong một nhóm - từ hướng ngoại đến người hướng nội và từ các nhà lãnh đạo đến những người theo đuôi. Bạn có thể sử dụng các cấu trúc giải phóng để gia tăng các sự kiện Scrum của bạn. Di chuyển ra khỏi stickies và bảng trắng trong một thời gian, và khám phá những kỹ thuật thúc đẩy mới

4. Tôn trọng hộp thời gian

Các sự kiện Scrum tạo cơ hội minh bạch, kiểm tra và thích ứng. Các sự kiện này được đặt theo thời gian, sao cho mọi sự kiện đều có thời lượng tối đa. Hộp thời gian tạo ra sự tập trung và giảm thiểu chất thải. Gắn bó với khung thời gian, mặc dù mục tiêu của sự kiện Scrum chưa đạt được, buộc nhóm nghiên cứu tìm ra giải pháp cho thời gian tới. Nếu bạn không tôn trọng khung thời gian, không có nghĩa là khẩn cấp để sửa nó.

5. Chuẩn bị các sự kiện Scrum.

Là một đội Scrum, dành thời gian chuẩn bị đúng cho mọi sự kiện Scrum. Thống nhất về chương trình nghị sự, cơ cấu và kết quả mong muốn. Ví dụ: chúng ta muốn sử dụng cấu trúc nào cho Daily Scrum? Bạn sẽ sử dụng "ba câu hỏi" hoặc thảo luận về Backlog của Sprint như một điểm khởi đầu? Giữ cho nhau trách nhiệm về hành vi được hiển thị. Nếu ai đó không được chuẩn bị, đó là trách nhiệm của nhóm để hành động. Một công cụ tốt để giúp nhóm hiểu được mục đích và kết quả dự kiến của các sự kiện Scrum được cung cấp bởi Crisp với họp Agile Cube

6. Tận dụng tối đa các sự kiện Scrum

The Scrum events have clear goals:

• Sử dụng Sprint Planning để đặt mục tiêu cho Sprint và chọn và xác định công việc cần thiết để đạt được mục tiêu đó;
• Sử dụng Sprint Review để thu thập phản hồi từ các bên liên quan và (cùng với họ) xác định những bước tiếp theo nào có ý nghĩa nhất dựa trên những gì đã học được trong Sprint;
• Sử dụng Sprint Retrospective để phản ánh Sprint trong quá khứ và xác định ít nhất một cải tiến khả thi trong Sprint tiếp theo;
• Sử dụng Daily Scrum để tạo ra một kế hoạch hàng ngày về cách nhóm sẽ làm việc cùng nhau để đạt được mục tiêu Sprint;
• Sử dụng Sàng lọc để phá vỡ khối lượng lớn công việc và làm rõ những gì có thể là cần thiết;

Nếu các sự kiện Scrum được thực hiện theo cách để đạt được những mục tiêu này, nhu cầu họp bên ngoài những sự kiện này sẽ giảm đáng kể. Cập nhật tiến độ, các cuộc họp đánh giá hành động, các cuộc họp thế hệ ý tưởng, giải quyết vấn đề, ra quyết định, thu thập thông tin; điều này tất cả có thể là một phần của các sự kiện Scrum và tạo không gian trong chương trình Scrum Teams.

Nếu đội Scrum tham dự một cuộc họp khác, họ nên tự hỏi mình:

• Tại sao nó không phải là một phần của một sự kiện Scrum?
• Làm thế nào chúng ta có thể làm cho cuộc họp này là một phần của các sự kiện Scrum trong tương lai?
• Sự kiện Scrum có đem lại giá trị mong muốn không?

Để cho Nhóm phát triển làm việc tập trung và tập trung, các cuộc họp bổ sung nên được giảm thiểu tối đa, ngoại trừ những gì cần thiết để giúp đội đạt được mục tiêu Sprint của họ. Toàn bộ mục đích của các sự kiện Scrum là cung cấp một nhịp điệu, nhịp điệu và tập trung rõ ràng để ngăn chặn việc chuyển đổi nhiệm vụ không cần thiết