ทำยังไงให้ทีม Scrum ต้นอ่อนรอดตาย
หลังจากที่ผมได้มีโอกาสสวมหมวก Scrum Master มาระยะหนึ่ง ผมพบว่าถ้าอยากให้ทีม Scrum ได้ทำงานต่อไปและไม่ล่มสลายไปก่อนเวลาอันควร มันมีหลักสำคัญตาม Principle ของ Agile ที่จะต้องทำให้ได้ ก็คือข้อนี้ครับ
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
… trust them? … ยังไงนะ?
ถ้าทีมจะทำงานได้อย่างยั่งยืน สมาชิกในทีมก็ควรจะถูก build ให้เกิด motivation โดยจะต้องสร้างสภาพแวดล้อมที่เอื้อให้เกิด motivation ด้วย และ “ไว้ใจ” ทีม ให้เค้าทำงานของเค้าให้เสร็จเอง
ปัญหาก็คือ การสร้างความไว้วางใจนี่แหละที่เป็นเรื่องยาก เพราะถ้าองค์กรต้องการเอากระบวนการแบบ Agile มาใช้ ก็เป็นไปได้ที่เดิมมันมีปัญหาบางอย่างอยู่ พอหัวหน้าถูก assign ให้แก้ปัญหา วิธีการแบบ command & control มันก็ตามมาโดยอัตโนมัติเพราะทุกฝ่ายต้องการความมั่นใจว่าวิธีใหม่ต้องแก้ปัญหาได้จริงๆ ความไว้ใจมันก็เลยหายไป
ซึ่งแนวทางที่จะทำให้เกิดความไว้ใจ ถูกพูดถึงใน principle ของ Agile ตั้งแต่ข้อแรกเลยนะ ที่บอกว่า…
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
มาถึงตรงนี้ทุกคนก็คาดหวังละว่ามันจะดีขึ้น ทีม Avenger … เอ้ย ทีม Scrum ต้นอ่อน ก็ถูกเกณฑ์มาละ ส่วน product ที่จะเอามาลองทำก็ถูกกำหนดเรียบร้อย แนวทางที่ผมเคยทำมาก็จะประมาณนี้ครับ
Small Achievement
ใน Sprint แรกๆ (โดยเฉพาะ Sprint แรก) ผมจะขอ PO อย่าได้คาดหวังว่าจะได้อะไร เพราะทีมยังไม่เคยทำงานแบบนี้เลย ผมจะให้ PO ลองคิดว่า “ที่ผ่านมาเคยเห็น project ไหนที่ทีมนี้เริ่มทำแล้วได้ของขึ้น production เลยภายใน 2 สัปดาห์ไหม? ถ้าไม่เคยก็ไม่ต้องคิดมากนะ มาลองดูกัน ถ้าพังก็แค่ 2 สัปดาห์ เดี๋ยวตอนโดนด่าผมไปด้วย” เค้าก็จะจำยอมผมแบบงอนๆ และอวยพรกลับมาว่า “จะรอดูแล้วกัน” … ขอบคุณครับ ^_^
จากนั้นใน Sprint แรก ผมจะขอให้ทีม release ให้ได้ เอาแบบไม่มี bug เลยนะ โดยอย่าเพิ่งกังวลว่า PO จะให้งานมากี่ feature แต่ขอให้ release feature ที่มี priority สูงๆ ให้ได้ก่อน ให้มันพร้อมทำงานอยู่บน environment ที่ใกล้ถึง production ที่สุดตามที่ตกลงกันกับฝ่ายที่เกี่ยวข้อง ถ้าขึ้น production server ได้ก็เอา คือเน้นไปที่ DoD กับให้มันทำงานได้จริงให้ได้นั่นแหละ ไม่ว่า feature นั้นจะเล็กแค่ไหนก็ตาม
Sprint Planning
จากนั้นก็ให้ทีมกับ PO ทำ Sprint Planning ตามปกติ โดยต้องไม่เกินเวลาตาม timebox นะ และจะต้องทำทีละ Product Backlog Item ประมาณนี้ครับ
- Sprint Planning Part 1 — ให้ PO เล่ารายละเอียดใน Product Backlog Item “ทีละใบ” ทีมถามตอบและจดรายละเอียด และเขียน Acceptance Criteria เอง เมื่อ confirm กับ PO เข้าใจตรงกันแล้วค่อยเริ่มทำ item ที่ 2 ทำไปเรื่อยๆ จนครบทุก item แต่ถ้าหมดเวลาตาม timebox ของ Sprint Part 1 ก่อนก็หยุด พวก Item ไหนคุยไม่จบก็ไปว่ากันใหม่ใน Product Backlog Refinement หรือ Sprint หน้า
- Sprint Planning Part 2 — ให้ทีมเอา Product Backlog Item ที่มีรายละเอียดแล้วจาก part 1 มาออกแบบและแตก task โดยให้ทำทีละ Item เหมือนกัน เสร็จแล้วก็ไปหยิบ Item ต่อไปมาทำ ทำไปเรื่อยๆ จนครบ หรือหมดเวลาตาม timebox ของ Sprint Part 2 ก็หยุด ใบไหนคุยไม่จบก็บอก PO ว่า ขอยังไม่รับเข้า Sprint นะครับ แฮ่ๆ
- สิ่งที่สำคัญมากตอนทีมทำ Task Breakdown ก็คือ DoD โดยต้องแน่ใจว่า task ที่ทีมแตกย่อยออกมาต้องเป็นไปตาม DoD คือมากพอที่จะขึ้น Production ได้จริงๆนะ
Sprint
ระหว่างการทำงานใน Sprint ก็จะคุยกับทีมว่า ลองค่อยๆ implement ไปทีละ Product Backlog Item ให้เสร็จ แล้วขึ้น Production Environment ให้ได้เลย (ตาม DoD และ Acceptance Criteria) ถึงแม้ว่าทีมจะทำไม่เสร็จทุก Product Backlog Item ตามที่ commit ไว้ก็ไม่เป็นไร
Sprint Review
ถึงตอน Sprint Review ของ Sprint แรก ถ้ามันไม่โชคร้ายสุดๆ เราจะได้ increment ที่ deploy แล้วบน environment ที่เราตกลงกันและ run ได้จริงๆ ถึงแม้ว่าจะได้ไม่ครบทุก Product Backlog Item ตามที่ PO อยากได้ แต่อย่างน้อยก็ยังได้ Item ที่ priority สูงๆ ให้ review กันได้
ระหว่างที่ review กันก็ต้องอาศัย skill การเล่นตลกคาเฟ่กันหน่อย เพื่อดึงบรรยากาศและให้ทุกคนไป focus ที่การสนุกกับการ review working software แทนที่จะมา focus กับของที่ทำไม่เสร็จ
Get Motivation with Positive Feedback
ถึงตอนนี้ผมก็จะขอ feedback จาก stakeholder ว่าเป็นยังไงบ้าง ชอบไหมที่ได้เห็น working software ที่ทำงานได้จริง หลังจากที่ทีมทำงานแค่ 2 สัปดาห์ก็ได้เล่นแล้ว (ถึงจะนิดเดียวก็เถอะ) ส่วนใหญ่ก็จะเป็นคำชมนะ (ถ้ารู้ว่าจะมีคำด่า ผมก็จะ groom ทั้งทีมและ management ก่อนเรื่องการให้ positive feedback)
เมื่อผู้บริหารเริ่มเห็นว่าทีมสามารถ release ได้ทุก sprint เค้าจะเริ่มวางแผนได้คร่าวๆ ว่าแต่ละรอบทีมทำได้แค่ไหน ความมั่นใจก็จะมากขึ้นเรื่อยๆ และความไว้วางใจก็จะค่อยๆ เพิ่มขึ้นเรื่อยๆ มันก็จะตรงกับ principle ตามที่ผมยกมาข้างต้นว่า ลูกค้า (ในที่นี้คือผู้บริหาร) จะพึงพอใจจากการที่ทีมสามารถ deliver software ที่มีคุณค่าอย่างสม่ำเสมอ เค้าจะรู้สึกว่ามัน “เร็ว” จริงๆ แต่ไม่ได้เร็วแบบทำทั้งหมดเร็วขึ้น แต่ “เห็นของเร็ว” เพื่อให้เกิดความคล่องตัวเมื่อเกิดความเปลี่ยนแปลง
สิ่งที่จะตามมาก็คือ ความคาดหวังแบบ “เฮ้ย เรามี Avenger ทีมแล้ว ลุย!!!” … มันก็เป็นเรื่องที่เหล่า Scrum Master ต้องไปทำงานกันต่อนะครับ ไม่งั้นต้นอ่อนที่มีโอกาสโตก็จะตายไปด้วยสาเหตุอื่นอีก ^_^
Conclusion
สิ่งนึงที่ผมได้เรียนรู้จากการเข้าไปทำงานร่วมกับหลายๆองค์กรที่อยากเอากระบวนการแบบ Agile ไปใช้ในทีม IT ก็คือ เค้าคาดหวังว่าจะได้ของเร็ว ซึ่งในช่วงแรกเค้าอาจจะยังไม่เข้าใจว่า “เร็ว” คืออะไร แต่ในขณะเดียวกันเค้าก็อาจจะไม่เข้าใจว่า ณ เวลานั้น องค์กรกำลังมีปัญหาอะไรด้วยซ้ำ แต่ไม่ว่ายังไงก็แล้วแต่ เค้าก็คาดหวังที่จะเห็นความเปลี่ยนแปลงอยู่ดี
ทีมที่เพิ่งเริ่มปรับกระบวนการทำงาน ไม่มีทางสร้างความเปลี่ยนแปลงอะไรได้เร็วอยู่แล้ว แต่จะให้ผู้บริหาร support ทีมต่อไป ทีมก็ต้องพิสูจน์ให้เห็นว่า “เราทำได้นะ” วิธีที่เร็วที่สุดก็คือ ทำให้เห็นผลลัพธ์ของการทำงานตั้งแต่เนิ่นๆ นั่นก็คือ สร้างworking software หรือ product ให้ออกมาได้เร็วที่สุดไม่ว่ามันจะเล็กแค่ไหน เพื่ออย่างน้อยทีมจะได้แสดงให้เห็นว่า สิ่งที่ทีมทำอยู่มันต่างออกไปจริงๆนะ มันจับต้องได้จริงๆ และเพื่อให้เกิดความเชื่อมั่นว่าเรามาถูกทาง เมื่อเกิดความไว้ใจแล้ว ต่อไปทีมอยากแก้ปัญหาอะไรก็ฟังขึ้น เพราะผู้บริหารเห็นแล้วว่า เขาไว้ใจทีมได้จริงๆ ครับ
