Sprint เป็นสิ่งสมมุติ

เวลาทีมเอา Scrum มาใช้เป็นครั้งแรก เราอาจได้รับคำถามบ่อยๆว่า ถ้างานไม่เสร็จใน Sprint จะทำอย่างไรดี จะเลื่อนปิด Sprint ได้ไหม ก็มันเร่งคงต้องทำโอทีให้มันเสร็จ หรือยกไป Sprint หน้า อ้าวแล้วมันก็กระทบแผนใหญ่สิ ความสั่นไหวเริ่มมา จนบางทีผมก็ตอบไปขำๆว่า

งานคือเรื่องจริง Sprint เป็นสิ่งสมมุติ

Sprint เป็นสิ่งที่เราสมมุติขึ้นมา เหมือนกับที่ชาวยิวโบราณสมมุติขึ้นมาว่าสัปดาห์หนึ่งมี 7 วัน ถ้างานที่เราตั้งใจจะทำให้เสร็จในสัปดาห์นี้ืมันไม่เสร็จภายในวันอาทิตย์ เราก็คงจะไม่สามารถเลื่อนวันอาทิตย์ออกไปได้ เพราะเวลาก็เดินของเขาไปเรื่อยๆ เราก็คงต้องไปทำต่อวันจันทร์

บางทีก็จะมีคำถามต่อไปว่า อ้าวแล้วอย่างนี้ทำงานไม่เสร็จก็ยกไป Sprint หน้าอย่างนี้ต่อไปเรื่อยๆ มันก็เหมือนทำไปเรื่อยๆสิ แล้วมันจะต่างอะไรกับการทำงานแบบเดิมๆ จะทำงานเป็น Sprint ไปทำไม

Sprint นั้นเป็นการทำงานแบบ time boxed คือหยุดเวลาใส่กล่องไว้ไม่เลื่อนไปมา เพื่อสร้างจังหวะในการทำงาน ให้ทีมรู้ว่าต้น Sprint เรามาวางแผน ท้าย Sprint เรามาทบทวนมองย้อน และวงจรจะเป็นอย่างนี้ไปเรื่อยๆ เหมือนกับที่เรารู้จังหวะชีวิตเราว่าเราทำงานวันจันทร์ถึงศุกร์ และเสาร์อาทิตย์หยุดพักผ่อน (ภาษา Kanban เรียกจังหวะแบบนี้ว่า fixed cadance) เมื่อจับจังหวะได้แล้วและรู้กำลังทีมเองแล้ว ทีมก็พอจะวางแผนในระยะสั้นได้ดีขึ้น ประสานงานและสื่อสารกันในทีมได้ดีขึ้น

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

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

เมื่อเราเริ่มรู้แล้วว่างานไม่น่าจะทัน ทางเลือกที่เรามักจะทำกันคือ

  1. ให้เพื่อนช่วย — ท่านี้เป็นท่าปกติของการทำงานเป็นทีมแบบอไจล์ ทีมที่เริ่มทำใหม่ที่เคยชินกับที่ต่างคนต่างทำก็จะทำท่านี้ยากหน่อย เพราะเราแทบจะไม่เคยได้แตะ code ที่ไม่ใช่ส่วนที่เราไม่เคยได้รับมอบหมายเลย หรือบางทีมก็มีทักษะที่ต่างกันมาก ทำงานกันคนละอย่าง ไม่รู้จะเริ่มต้นไปช่วยคนอื่นอย่างไร แต่ถ้าไม่เริ่มตอนนี้แล้วจะไปเริ่มตอนไหน ในเมื่อเราไม่สามารถกำหนดได้อยู่แล้วว่างานที่วิ่งเข้าทีมจะมีความสมดุลย์ที่แต่ละคนจะมีงานพอๆกันอยู่ตลอดเวลา ปัญหาของการทำงานแบบเดิมคือมักจะมีบางคนโหลดมากมายจะตายแล้ว ในขณะที่บางคนก็ว่างจนไม่มีอะไรจะทำ โอกาสนี้จึงเป็นโอกาสที่ดีที่คนไม่เคยทำจะได้ลองทำ จะเรียนรู้งานหรือทักษะใหม่ๆ แน่นอนแหละว่ามันก็จะช้าลง ก็มันไม่เคยทำ แต่ถ้าเราทำงานกันแบบเดิมก็จะเจอแต่ปัญหาเดิมๆ วันหนึ่งเพื่อนเราออกไปพร้อมกับความรู้ของงานนั้น และไม่มีใครรับช่วงต่อได้ ก็เสียเวลางมกันไป จนบ้างครั้งธุรกิจก็เสียหาย จริงๆแล้วการช่วยกันทำควรจะเกิดขึ้นก่อนเป็นปกติ ก่อนที่เราจะรู้ว่างานมันไม่ทันด้วยซ้ำ แต่ก็ต้องยอมรับว่าการสร้างพฤติกรรมใหม่นั้นอาจต้องใช้เวลา
  2. ทำล่วงเวลา — ท่านี้เป็นท่ายอดนิยมอีกท่าหนึ่ง ที่พบเห็นกันได้ทั่วไป นานๆเราจะช่วยกันทีถ้ามันจำเป็นก็คงไม่ใช่เรื่องแปลก แต่เราจะกลับบ้านสามสี่ทุ่มกันได้สองสามเดือนติดกันจริงๆหรือ ใช้ท่านี้บ่อยๆก็ไม่ต่างกับเป็นการชวนให้คนออกไปทำงานที่อื่น ที่ออฟฟิตสวยกว่า ทำงานที่ตัวเองชอบมากกว่าในเวลาที่เขาเลือกได้ บางที่มีข้าวกลางวันให้ฟรี ยุคนี้โปรแกรมเมอร์ดีนั้นมีแต่คนอยากได้ ท่านี้ควรเก็บไว้ใช้เวลาจำเป็นจริงๆ ไม่ใช่ทำเป็นปกติ
  3. เอางานออก — ถ้ารู้แล้วว่า Sprint นี้มีแนวโน้มปิดงานได้ไม่หมด งานไหนที่ยังไม่เริ่ม แนะนำว่าก็อย่าเพิ่งเริ่ม โยกไป Sprint หน้าหรือเอาไปเก็บใน Backlog ก่อน ทั้งนี้เพราะว่าการที่มีงานที่เสร็จจริงๆ 3 อย่าง พร้อม demo เพื่อเอา feedback จริงๆจาก user ได้นั้นดีกว่าการเริ่มงานไป 10 อย่างแต่ไม่มีอะไรเสร็จสักอย่างเป็นไหนๆ ท่านี้คือท่าที่ทำให้เกิดโฟกัสจริงๆกับการทำงาน ให้เราอยู่กับปัจจุบัน ทำเสร็จทีละงาน ถ้าเอางานออกแล้วมีคนว่างก็มาช่วยคนอื่นทำ อย่างที่บอกไว้ในข้อแรก ถ้าศึกษา Kanban ด้วยมักจะได้ยินประโยคที่พูดกันบ่อยๆว่า — Stop Starting Start Finishing! แน่นอนว่าเอางานออกจาก Sprint มันจะกระทบแผนใหญ่ แต่เนื่องจากเราจะหยิบสิ่งที่สำคัญที่สุดที่ใช้งานได้จริงมาทำก่อนเสมอ ผลกระทบนี้ในระยะยาวจริงไม่ได้เป็นปัญหาอะไรซักเท่าไหร่เลย
  4. หลอกตัวเองว่าทัน — ท่านี้เรียกได้ว่าเป็นท่ายอดนิยมอีกท่าของมือใหม่หัดอไจล์ ไม่ว่าจะด้วยความเคยชินหรือมีคนบังคับให้หลอกตัวเองก็ตาม ไม่น่าเชื่อว่าบางทีมขนาดทำมาหลาย Sprint แล้ว ทั้งที่ก็เห็นๆกันอยู่ว่าไม่เคยทำได้เสร็จตามแผนเลยติดๆกันหลายๆ Sprint ก็ยังพยายามยัดงานเข้ามากกว่าที่ทีมทำได้ ทำแบบนี้ไปสักพักก็เป็นไปได้สูงที่ทีมจะถามว่า แบบนี้จะทำงานเป็น Sprint ไปทำไม สู้กับไปทำ work breakdown เหมือนเดิมแล้วจ่ายงานมาให้ผมเลยดีกว่า ไม่ต้องมาเสียเวลาคุยกันให้วุ่นวาย

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

Sprint นั้นเป็นเพียงสิ่งสมมุติ ความสำคัญจริงๆนั้นอยู่ที่การทำงานที่ตอบโจทย์ความต้องการของลูกค้าจริงๆ ไม่ใช่การที่ต้องทำ Sprint ให้ทัน หรือทำ burndown ให้สวย ไม่อย่างนั้นการทำงานเป็น Sprint ก็จะไม่ต่างอะไรกับกับย้าย due date มาให้เรา burnout กันเร็วขึ้นเป็นทุกๆ 2 สัปดาห์ สุดท้ายเราก็ส่งของไม่มีคุณภาพออกไปให้ลูกค้า แล้วก็ต้องกลับมาแก้เหมือนเดิม

ขอให้ความกล้าในการทำสิ่งที่ถูกต้องเกิดขึ้นกับทุกคนและขอให้สนุกกับการทำอไจล์นะครับ

ป.ล. : ฝากข่าวว่าเดือนนี้ผมเชิญคุณ Maria Matarelli มาสอน Certified Agile Marketing Specialist วันที่ 22–23 ก.ค. กับ Certified Scrum Master วันที่ 25–26 ก.ค. นี้ ถ้าสนใจติดต่อมาที่ kulawat@leaningroup.com นะครับ