ใช้ Scrum หรือ Mini-Waterfall ถามใจเธอดู?

ถ้าคุณกำลังประสบปัญหาเหล่านี้

1. User Story ที่ทำใน Sprint ไม่เคยเสร็จและต้องทำต่อใน Sprint หน้า....(Sprint1,2,3,4...n)
2. ใน Sprint Review Meeting นำเสนอผลงานเมื่อจบ Sprint ให้ Product Owner และ Stakeholder ดู

• BDD Document (Business Driven Development)
• API Doc 
• Design Document 
• Postman (Tools สำหรับ Test Connection กับ API)

       3. ใช้ Scrum แล้วไม่เห็นจะเร็วขึ้น ส่งมอบ Product ได้ตอนท้ายโครงการอยู่ดี
       4. คนในทีมได้รับงานไม่เท่ากันในช่วงเวลาเดียวกัน ทำให้เเกิดการว่างงาน อ๋อ ตำแหน่งนี้ว่างแล้ว               Utilize คนไปทำโครงการอื่นก่อน เมื่อตำแหน่งนี้ทำงานเสร็จค่อยกลับเข้ามาทำต่อ
       5. ปัญหาเกิดจากแผนกนั้น เป็นปัญหาของแผนกโน่น เป็นเพราะแผนกนั้นทำแบบนี้ ...

Mini-Waterfall
.
.
.
Doing Scrum
.
.
.
Potentially Shippable Product
.
.
.
Sprint Backlog
.
.
.
Product Backlog

นี่ไงเราทำ Scrum แล้ว ก็มี Sprint นี่ไง แถมมี Scrum Ceremonies ครบด้วยไม่ว่าจะเป็น

• Sprint Planning 

• Product Backlog Refinement (Optional)

• Daily Standup

• Sprint Review

• Sprint Retrospective

จินตนาการตามนะครับ สมมุติเป็น Product/Project แรกที่เราเริ่ม Adopt Scrum มาลองใช้ ด้วยการคิดในใจว่าไหน "ลองซิ Agile มันจะเร็วกว่าเดิมยังไง เห็นเค้าบอกว่าว่าเอามาใช้แล้วจะทำงานได้เร็วขึ้น"

เมื่อจบ Sprint7 คิดว่าจะเกิดอะไรขึ้นครับ?
.
คิดว่าปัญหาที่เราเคยทำแบบ Traditional จะหายไหมครับ?
.
ปัญหาด้านบนยังคงอยู่ไหมครับ?



ลองไล่คำถามเพื่อหาสาเหตุของต้นตอของปัญหาจริงกัน
1. เราทำงานแบบ Mini-Waterfall ใช่หรือไม่? (Yes/No)

If Yes -->  ไปดูต่อข้อ 2

2. เราทำงานแบบ Scrum ใช่หรือไม่? (Yes/No)

If Yes -->  ไปดูต่อข้อ 3

3. เรามี Potential Shippable Product ใช่หรือไม่? (Yes/No)

If Yes -->  ไปดูต่อข้อ 4

4. เรามี Sprint Backlog ใน Sprint ใช่หรือไม่? (Yes/No)

If Yes -->  ไปดูต่อข้อ 5

5. เรามี Product Backlog Items ใช่หรือไม่? (Yes/No)

 If Yes --> เรามีครบทั้ง 5 ข้อแล้ว มันไม่น่าจะมีอะไรผิดพลาดนี่หน่า สิ่งที่เราคาดหวังว่ามันจะมาช่วยทำให้ Product/Project เรามี Agility มากขึ้น แต่ทำไมมันไม่เป็นอย่างนั้น

เราช่วยกันไล่ปัญหากลับมาถึงต้นตอของปัญหาที่แท้จริงแล้ว Product Backlog นี่แหละตัวปัญหา
.
.
.
ปัญหาข้อที่ 1 :
นำ  Product Backlog ที่เป็นประเภท Epic/Feature เข้าใน Sprint ทำให้ไม่มีโอกาสงานใน Sprint จะเสร็จและมีโอกาสที่จะเป็น Potentially Shipable Product ได้เลย เพราะ Scope of work (SOW) ของงานมากกว่ากว่าเวลาใน Sprint อาจจะรวมถึงความไม่ชัดเจนของ Scope ด้วยที่อาจจะเป็นปัญหาที่เจอในระหว่าง Sprint

เรามาดูประเภทของ Product Backlog (PB) กันว่าคืออะไร และมีกี่ประเภทบ้าง
- Product Backlog (PB) แปลง่ายคือ จำนวนงานที่ต้องทำของ Product นั้น

Product Backlog แบ่งได้เป็น 4 ประเภท

   1. Epic : Scope of work > 4 Sprints

   2. Feature : Scope of work 1 - 4 Sprints

   3. User Story : Scope of work < 1 Sprints
        ตามทฤษฎีประมาณ 20% ของ Sprint ถ้าสมมุติ Sprint 2 Weeks (10 Man days) 20% ก็จะอยู่ที่ 2 วัน

   4. Task : Scope of work 1 Days (8 Hours)

ปัญหาข้อที่ 2 : User Story ที่นำเข้าไปใน Sprint แบ่งงานตาม Functional ของโครงสร้างบริษัท

ยกตัวอย่างเช่น

- User story 1 : Design1

- User story 2 : Design2

- User story 3 : Design3

แสดงว่าเรากำลังจะส่งมอบ User Story ที่เป็น Layer Cake ให้กับลูกค้า ลองคิดตามนะครับถ้าเราไปร้าน Bakery เราคงไม่อยากจะทานเค้กที่เป็นฐานเค้ก (Layer 1st) หรอกนะครับ เราเรียกการแบ่ง User Story แบบนี้ว่า Horizontal Slice

ในมุมมองกลับกันถ้าเราเป็นลูกค้าเราก็คงอยากทานชิ้นเค้กที่เป็นชิ้นสวยงามมีรสชาดความอร่อยของ Layer ที่ต่างกัน ทุกๆๆ Layer

เพราะฉะนั้น  User Story เราต้องหั่นให้เป็นชิ้นครบทุก Layer ที่เราเรียกว่า Vertical Slide

สรุปจากปัญหา 2 ข้อข้างต้น ถ้าเราเข้าใจในเรื่องและสามารถนำ User Story (Vertical Slide)  เข้าใน Sprint Backlog ได้ สิ่งที่เราจะเห็นหลังจากจบ Sprint คือ Potential Shipable Product ครับ