LeSS ตอน Continuous Coordination

Chokchai Phatharamalai
odds.team
Published in
2 min readJul 26, 2021
Photo by Matt Bero on Unsplash

อ่านหนังสือ Large Scale Scrum ถึงบทที่พูดเรื่อง LeSS Coordination and Integration ได้เรียนรู้ว่า

การ coordinate กับ integrate สัมพันธ์กันแน่นหนามาก การ integrate อย่างสม่ำเสมอ จำเป็นต้อง coordinate อย่างสม่ำเสมอ และคนที่เราต้องคุยตอน coordinate กับตอน integrate ก็มักจะเป็นคนเดียวกัน

ในสกรัม การ coordinate ภายในทีม เป็นหน้าที่ของทีม ใน LeSS การ coordinate ระหว่างทีมก็ถือเป็นหน้าที่ของทีมเช่นกัน เพราะพวกเขาทำ product เดียวกัน

ใน LeSS ท่าที่นิยมที่สุดในการ coordinate เรียกว่า Just talk ซึ่งมีแค่ 4 step แบบนี้

  1. ผมพบว่าผมต้อง coordinate กับทีม B
  2. ผมลุกขึ้นยืน
  3. เดินไปทีม B
  4. ตะโกนว่า เฮ้ย มามุงกันเถอะ

ทำไมมันง่ายขนาดนี้

เพราะทีมทุกทีมใน LeSS มีเป้าหมายเดียวกัน การมีคนมาขัดจังหวะ ก็จะไม่หงุดหงิด เพราะเรากำลังทำ product เดียวกัน เวลาจบ sprint มันจะมีแค่ product ของเรา (ทุกทีม) เสร็จ หรือไม่ก็ไม่เสร็จ

พอ setup มันเป็นแบบนี้ ปัญหาเลยไม่อยู่ที่จะ coordinate ยังไง ปัญหาจะย้ายไปเป็น…

รู้ได้ยังไงว่าเมื่อไหร่ต้อง coordinate กับใคร?

communicate ผ่าน code ลองจินตนาการว่าทีมทำ single branch development นั่นคือทุกคน push และ pull code ไปยัง branch เดียวกัน และทุกคนหมั่น push และ pull สม่ำเสมอ (มากกว่าวันละครั้ง) เวลาที่เราแก้บรรทัดเดียวกัน code conflicit จะเป็นตัวบอกเองว่าใคร ทีมไหน ที่กำลังแก้ที่เดียวกับเรา ซึ่งนั่นเป็นจังหวะดีที่ทั้ง 2 คนจากคนละทีมจะมามุงกันเพื่อ resolve conflict ร่วมกัน

จังหวะนั้นเป็นจังหวะช้าสุดที่เราจะได้รู้ว่าอีกทีมทำอะไร ถ้าเราไม่ได้เจอสิ่งนี้มาตั้งแต่ตอน refinement หรือ sprint planning part 2

สิ่งที่สนับสนุนให้มันเวิร์คง่าย ๆ แบบนี้

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

item ใน backlog ไม่ได้เขียนจากมุมมองของลูกค้า

ส่วนใหญ่ทีมที่อยู่ในบริบทที่ทำงานแบบ fix time fix scope ก็มักจะเขียน item แบบ technical work (บางครั้งเป็นแค่ task ด้วยซ้ำ) ซึ่งทำให้มองออกยากว่า item นี้ส่งมอบคุณค่าอะไรให้กับลูกค้า

เพราะ task หรือ technical work มันระบุวิธีการแก้ปัญหาลงไปแล้ว มันข้าม problem domain เข้ามาอยู่ใน solution domain แล้ว พอวิธีแก้ปัญหา 2 วิธีมันตีกัน มันก็ปรับยาก แต่พอเราเขียนจากมุมมองของลูกค้า มันเปิดพื้นที่ให้ทั้งสองทีมหาวิธีการใหม่ที่จะแก้ทั้ง 2 ปัญหาตาม item ที่ตัวเองรับมา เพื่อส่งมอบคุณค่าทั้งสองอย่างให้กับลูกค้าได้

ไม่ได้ทำให้ coordination เป็นเรื่องง่าย

ทำให้มัน decentralize ไม่ต้องกังวลว่าจะรู้ไม่ครบทุกคน ไม่ต้องรอให้ถึง event ที่จะได้ sync กัน (เช่นรอหลัง daily Scrum พรุ่งนี้ค่อยคุย หรือรอ Scrum of Scrums) ไม่ต้องกลัวว่าจะไป inturrupt ทีมอื่น อย่าลืมว่าใน LeSS พวกเราอยู่ใน sprint เดียวกัน มี sprint review อันเดียวกัน มีเป้าหมายเดียวกัน

เราขัดจังหวะทีมอื่นเป็นเรื่อง casual เรื่องปรกติ เหมือนตอนเราขัดจังหวะกันเองในทีมสกรัม

ถ้าทำแบบนี้ได้เรื่อย ๆ information จะ flow แล้วปัญหามากมายจะหายไปเอง

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

หวังว่าจะเป็นประโยชน์กับคนอ่านไม่มากก็น้อยนะครับ ขอบคุณที่สละเวลาอ่านครับ ^/\^

บทความที่เกี่ยวข้อง

--

--