[แปล] Real-life Agile Scaling จากงาน Agile Tour Bangkok 2015

ปีนี้ไม่ได้ไปร่วมงาน Agile Tour Bangkok 2015 เลยได้แต่ตามอ่านจาก feed และ blog ต่าง ๆ แทน ซึ่งมีหนึ่ง blog ที่น่าสนใจเขียนไว้ที่ InfoQ.com คือ Real-life Agile Scaling - Henrik Kniberg's Opening Keynote at Agile Tour Bangkok จึงได้นำมาแปล และ สรุปตามที่เข้าใจ เป็นดังนี้

เริ่มต้นด้วยปัญหาในการขยาย Agile ออกไปมากกว่า 1 ทีม

ซึ่งมันเป็นเรื่องที่ยาก และ บ่อยครั้งผลที่ออกมากลับแย่ลงกว่าเดิมอีก ดังนั้นมาดูกันว่า Scaling Agile มันคืออะไร และมีสิ่งใดบ้างที่องค์การต่าง ๆ ต้องรับมือ ปรับเปลี่ยน เนื่องจากพบว่าคนที่ลงมือทำ กลับไม่รู้ และ ไม่เข้าใจว่า ผลกระทบจากการปรับเปลี่ยนมันเป็นอย่างไรบ้าง ? ดังนั้นมาเริ่มกันเลย ก่อนอื่นผมชอบรูปนี้มาก ๆ จาก Slide :: Scaling Agile at Lego

มาดูความเสี่ยง และ ค่าใช้จ่าย จากการ Scaling Agile กันว่ามีอะไรบ้าง ?

แสดงดังรูป โดยในการ Scaling Agile ต้องรู้และเข้าใจสิ่งต่าง ๆ เหล่านี้ มิเช่นนั้นจะนำไปสู่หายนะได้

• How to slice the elephant ?
• Team Structure
  • How to tackle dependencies across teams
• Feedback loop
  • How to keep teams synchronised and aligned

มาดูรายละเอียดในแต่ละเรื่องกัน

How to slice the elephant ?

นั่นคือการแบ่งงานใหญ่ ๆ ออกเป็นงานย่อย ๆ แล้วเรียงลำดับของงานที่ทำตามลำดับความสำคัญนั่นเอง คล้าย ๆ กับ MVP (Minimum Viable Product) แต่ได้แนะนำขั้นตอนการเลือก และ แบ่งงานดังนี้

• Earliest testable
• Earliest usable
• Earliest lovable

แสดงดังรูป

Team Structure

Feature team ดีกว่า Component team อย่างแน่นอน แต่มันมีความเสี่ยงอย่างมากต่อองค์กรที่เป็นแบบ Silo อย่างแข็งแกร่ง ดังนั้นจึงแนะนำให้ทีมเป็นแบบ hybrid ไปก่อน นั่นคือ ผสมผสานระหว่าง feature และ component team เพราะว่าในองค์กรใหญ่ มักจะมีความซับซ้อนเยอะ มีพวก blackbox technology เยอะ ดังนั้น จึงต้องการคนจาก component team มาด้วย แสดงดังรูป

How to tackle dependencies across teams ?

แน่นอนว่าในการทำงานต้องทำงานร่วมกันมากกว่า 1 ทีม บ่อยครั้งพบว่าจะเกิด dependency ระหว่างทีมเยอะมากมาย ตัวอย่างเช่น เราจะสร้าง feature A ไม่ได้ ถ้าอีกทีมไม่สร้าง B ขึ้นมาก่อน !! ดังนั้น จะแก้ไขปัญหาของ dependency ระหว่างทีมได้อย่าง ? โดยวิธีการที่แนะนำก็คือ Platform team แสดงดังรูป

รวมทั้งยังได้แนะนำการสร้างทีม ควรประกอบไปด้วย

• ทีมมีจำนวนสมาชิกระหว่าง 3 - 9 คน
• สมาชิกทุกคนในทีมทำงานแบบ full time ทำงานด้วยกัน ซึ่งต้องเป็นทีมที่มั่นคง ไม่แยกออกจากกัน
• ทีมมีเป้าหมายเดียวกัน ร่วมกัน และ ชัดเจน
• ทีมต้องรู้ว่าใครคือลูกค้า ไม่ว่าจะทั้งจากภายใน หรือ ภายนอก
• บางทีมต้องการคนมาช่วยจัดเรียงลำดับความสำคัญงานของลูกค้า เช่น Product Owner
• ทีมต้องเป็นแบบ Cross-functional นั่นคือทีมต้องมีความสามารถทั้งหมดที่จำเป็นต่อการส่งมอบสิ่งที่มีคุณค่าให้ลูกค้า
• ทีมต้องมีความยืดหยุ่น ไม่มีใครเป็นคอขวดของทีม

แสดงดังรูป

Feedback loop

ในระดับทีมนั้น เรื่องของ feedback น่าจะพอเป็นที่เข้าใจกันดีใน Agile ไม่ว่าจะเป็น

• Continuous Integration
• Daily standup meeting
• Iteration planning
• Retrospective
• Showcase

ยิ่งใน Scaling Agile ยิ่งต้องการ feedback loop ที่รวดเร็วเช่นกัน แต่ละทีมต้องทำการ sync ข้อมูลกันเสมอ แต่ละทีมต้องมีช่วงของ iteration เหมือนกัน แต่ละทีมต้องทำการ integate product กันอยู่อย่างสม่ำเสมอ แต่ละทีมต้องทำการ sync การวางแผนงานต่าง ๆ แต่ละทีมต้องมีการทำ release checkpoint ร่วมกัน แสดงดังรูป

สิ่งที่ขาดไม่ได้เลยคือ Continuous Integration

เนื่องจากการทำงานร่วมกันหลาย ๆ ทีม เรื่องคุณภาพของงาน ของ product มันต้องอยู่ในระดับที่สูง มันจะทำให้เห็นว่ามี dependency อะไรบ้าง มันจะทำให้รู้ปัญหาได้อย่างรวดเร็ว ส่วน Continuous Delivery นั้นมันก็มีประโยชน์ เอาไว้สำหรับ product ที่ต้องการ feedback เร็วจากลูกค้า แต่ไม่ได้จำเป็นเท่า Continuous Integration แสดงดังรูป

ต่อมาคือเรื่องบทบาทของ Leadership

เป็นอีกหนึ่งส่วนที่ช่วยให้การ Scaling Agile ประสบความสำเร็จ ซึ่งจะช่วยสร้างสิ่งแวดล้อมที่เอื้อต่อการทำงานเป็นทีม ไม่ใช่เข้ามาสั่ง สั่ง สั่ง อย่างเดียว !! อ่านเพิ่มเติมเรื่อง What is an Agile Leader ได้ซึ่งอธิบายได้ละเอียดมาก ๆ แสดงดังรูป

Agile มันไม่ใช่เป้าหมายของการเดินทาง

แต่ว่ามันคือ การเรียนรู้ การลงมือทำอย่างต่อเนื่อง และ สม่ำเสมอ มันคือการเดินทางที่ยังต้องดำเนินต่อไป เพื่อหาจุดที่เหมาะสมสำหรับแต่ละองค์กร ว่าจะวางแผน และ โครงสร้างอย่างไร ซึ่งมันคือ หัวใจของความสำเร็จ อย่าทำน้อย ไป หรือ มากไป แสดงดังรูป

สุดท้ายทำการสรุปเป็น Key Take Aways ดังนี้

• Small as possible
• Agile is a means, not a goal
• No right to Wrong way
• No one-size-fit-all
• Build feedback loop at all level

แสดงดังรูป ไม่ได้ไปร่วมงาน แต่ได้อ่านได้แปล ก็ ok ล่ะ !!