Screen Shot 2558-11-22 at 3.28.35 PM
ปีนี้ไม่ได้ไปร่วมงาน 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
Screen Shot 2558-11-22 at 2.10.49 PM

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

แสดงดังรูป
1 Risks of Scaling

โดยในการ 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

แสดงดังรูป
2 Earliest Testable Product

Team Structure

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

แสดงดังรูป
3 Team Structures

How to tackle dependencies across teams ?

แน่นอนว่าในการทำงานต้องทำงานร่วมกันมากกว่า 1 ทีม
บ่อยครั้งพบว่าจะเกิด dependency ระหว่างทีมเยอะมากมาย

ตัวอย่างเช่น
เราจะสร้าง feature A ไม่ได้ ถ้าอีกทีมไม่สร้าง B ขึ้นมาก่อน !!
ดังนั้น จะแก้ไขปัญหาของ dependency ระหว่างทีมได้อย่าง ?

โดยวิธีการที่แนะนำก็คือ Platform team
แสดงดังรูป
4 Dependencies

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

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

แสดงดังรูป
5 teams of teams

Feedback loop

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

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

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

แสดงดังรูป
6 Feedback Loops

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

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

ส่วน Continuous Delivery นั้นมันก็มีประโยชน์
เอาไว้สำหรับ product ที่ต้องการ feedback เร็วจากลูกค้า
แต่ไม่ได้จำเป็นเท่า Continuous Integration

แสดงดังรูป
7 CI CD

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

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

อ่านเพิ่มเติมเรื่อง What is an Agile Leader ได้ซึ่งอธิบายได้ละเอียดมาก ๆ

แสดงดังรูป
8 Aligned

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

แต่ว่ามันคือ การเรียนรู้ การลงมือทำอย่างต่อเนื่อง และ สม่ำเสมอ
มันคือการเดินทางที่ยังต้องดำเนินต่อไป

เพื่อหาจุดที่เหมาะสมสำหรับแต่ละองค์กร
ว่าจะวางแผน และ โครงสร้างอย่างไร
ซึ่งมันคือ หัวใจของความสำเร็จ
อย่าทำน้อย ไป หรือ มากไป
แสดงดังรูป
9 Good 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

แสดงดังรูป
10 Summary

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