😎 Improving Waterfall Agility with Kanban

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

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

ลักษณะขององค์กรที่นี่มีความโชคดีที่มีการแบ่งทีมไอทีแยกตามกลุ่มธุรกิจอยู่แล้วระดับหนึ่ง ไม่ใช้ traditional resource pool แต่ถึงกระนั้นแต่ละทีมก็มีโปรเจคที่ทำอยู่พร้อมๆกันอยู่เป็นจำนวนมาก บางทีมทำอยู่มากกว่า 10 โปรเจค! การจะหา PO หนึ่งคนมาดู priority ให้ทีมแทบจะเป็นไปไม่ได้ เพราะไม่มีใครมีบารมีพอที่จะจัดการกับ stakeholder ทั้ง 10 โปรเจค ให้มาตบตีเพื่อตกลง priority พร้อมๆกันได้ สมาชิกส่วนใหญ่ที่เป็นพนักงานองค์กรมักจะทำงานทำนอง SA และมีเขียนโค้ดบ้าง แต่ส่วนใหญ่จะมี outsource ที่อยู่กันมานานเป็น dev ผมไม่แน่ใจแต่เดาว่าหลายๆองค์กรใหญ่ในบ้านเราก็ยังมีโครงสร้างและวิธีการทำงานไม่ต่างไปจากนี้มากนัก

ถ้าจะทำ Scrum ให้ได้ผล น่าจะต้อง reorganize กันพอสมควร ซึ่งยังไม่ใช่ตัวเลือกที่อยู่บนโต๊ะตอนนี้ เราจึงแนะนำให้ใช้ Kanban ที่มีกลิ่นอายของ Scrum เล็กๆ ตามแบบฉบับของ Lean In Way ที่เรียกกันเล่นๆเองว่า Kanban with Sprint

ที่เรียกว่า Kanban with Sprint ก็เพราะว่าเรายังแนะนำให้ทีมทำงานบน Timebox ยาว 2 สัปดาห์อยู่โดยทุกทีมในไอที เริ่มและจบ Sprint วันเดียวกัน เพื่อความง่ายในการสื่อสารข้ามทีม มี Planning ว่าจะทำอะไรต้น Sprint มี Review เพื่อสรุปงาน และมี Retro เพื่อคุยเรื่องปรับปรุง ในตอนจบ Sprint และก็มี Standup กันปกติทุกวัน

ด้วยความที่ principle ของ Kanban ข้อแรกนั้นคือ

Start With What You Do Now

เราจึงไม่ได้เปลี่ยนอะไรกันมากนัก แต่เริ่มจากการที่ให้แต่ละทีม visualize วิธีการทำงานในปัจจุบันออกมาก่อน ซึ่งหลายๆทีมก็จะทำ Kanban Board ออกมาหน้าตาคล้ายๆกับรูปตัวอย่าง Board ด้านบน แต่รายละเอียดของแต่ละ Column ก็อาจจะต่างกันไป โดยเฉพาะในส่วนของ DoD หรือ Definition Of Done ที่เป็นเงื่อนไขที่จะบอกว่า งานใน column นั้นเสร็จหรือยัง ถ้าเสร็จก็จะย้ายการ์ดข้ามเส้นประจากซ้ายไปขวาได้ ถ้า WIP Limit ของ Column หน้ายังไม่เต็มก็ย้ายการ์ดไป Column ถัดไปได้

ในแต่ละ Column ที่เห็นตัวเลขในวงเล็บนี่ก็คือ WIP (Work In Progress) Limit ที่จะเป็นตัวกำหนดว่าเราจะไม่เอางานมาใส่ใน Column นี้เกินกว่า Limit ที่เราตกลงกันไว้ อย่างในตัวอย่างจะเห็นว่าใน In Dev ถึงแม้ใบเขียวของ Project B จะเสร็จแล้ว (สังเกตจากการ์ดถูกย้ายมาฝั่งขวาของเส้นประแล้ว) แต่ก็ยังไม่สามารถย้ายเข้าไป In Verifying ได้เพราะที่ Column นี้มีการ์ด 4 ใบ ซึ่งเต็ม WIP Limit แล้ว

WIP Limit นี่เอง เป็นหัวใจสำคัญของ Kanban ที่จะช่วยจัดการให้ flow เกิดการลื่นไหล ลองจินตนาการว่าถ้าเราไม่มี Limit แล้วงานตรงนั้นใช้เวลานาน งานก็จะมากองพะเนินเต็ม Column ไปหมด แทนที่เราจะมุ่งโฟกัสไปแก้ปัญหาที่งานมากองตรงคอขวด (ภาษาลีนเรียกว่า Constrain) คือแก้ปัญหางานปัจจุบันที่ทำอยู่ให้เสร็จก่อน เราดันไปหยิบงานใหม่มาทำอีก มันก็ยิ่งส่งไปกองเรื่อยๆ ลองนึกภาพงานที่ dev ทำเสร็จแล้วโยนไปให้ tester ก็ได้ อาจจะพอนึกออก

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

Agree to pursue improvement through evolutionary change

แต่จะรู้ว่าปรับปรุงอะไรได้จริงไหม เราก็ต้องวัดผลได้ด้วย ซึ่งใน Kanban นั้น ตัววัดผลหลักๆคือ Lead Time หรือเวลาที่งานใช้อาศัยอยู่บนบอร์ด กับ Throughput หรืออัตราความเร็วที่เราสามารถทำงานได้เสร็จ

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

พอเริ่มทำกันไปสองสาม Sprint หลายๆทีมจะเริ่มเห็นว่า งานจะมาค้างเติ่งอยู่ที่ In Verify หรือที่มีชื่อเรียกกันติดปากว่า UAT เพราะส่งให้ user แล้วยังไม่ test ซักที! บางทีมก็มีคำถามว่า เอา UAT ออกไปนอกบอร์ดเลยได้ไหม จบที่ dev พอ มันแทงใจ แต่ผมก็จะชวนให้เอาไว้อย่างนั้นนั่นแหละดีแล้ว

เมื่อเราเริ่มวัด lead time เราก็จะเริ่มเห็นว่างานชิ้นหนึ่งใช้เวลานานแค่ไหน ที่เราจะส่งมอบให้ลูกค้าได้จริงๆ และถ้าเราอยากจะปรับปรุงให้ดีขึ้น ก็ควรมุ่งเป้าที่จะลด lead time และ เพิ่ม throughput ซึ่งจะทำได้ก็ต่อเมื่อเราปรับลดให้ขนาด release ให้เล็กลง และเพิ่มคุณภาพของงานให้ดีขึ้น เพื่อลด defect และสามารถส่งมอบได้อย่างรวดเร็ว ซึ่งเทคนิคในการลด lead time ก็มีหลายหลายวิธี ตั้งแต่ทำ ATDD ไปจนถึง DevOps ที่กำลังฮิตติดตลาดกันอยู่ตอนนี้

อ้าวแล้ว user คนดีของเราอยู่ตรงไหน มี Product Owner ไหม แล้ว Scrum Master หล่ะ ไม่เห็นได้กล่าวถึง Sprint Demo เลย

เนื่องจากว่าทีมยังทำหลายโปรเจค การที่จะให้ user มา standup ด้วยทุกวันก็ไม่ค่อยเหมาะนัก เพราะมีหลายเรื่องที่เขาไม่น่าจะสนใจ แต่อยางไรก็ตาม การที่ dev กับ user ได้มา sync up ทำงานร่วมกันบ่อยๆนั้นเป็นเรื่องจำเป็น แต่จะบ่อยได้แค่ไหนนั้นก็ขึ้นกับหลายๆอย่าง ตั้งแต่บริบทขององค์กร ไปจนความสัมพันธ์ระหว่างคน คำแนะนำคือควรจะมี Sync Up, Planning, Demo และ Retro ในระดับ project อย่างสม่ำเสมอ ในระดับความถี่ที่เหมาะสมของแต่ละ project และในบริบทนี้ หัวหน้าทีมทำหน้าที่เป็น team facilitator และประสานกับฝ่าย user ซึ่งบางโปรเจคก็มี Product Owner เป็นเรื่องเป็นราว บ้างมีหลายคน บ้างไม่เลยเพราะไม่เคยได้ยิน

Kanban นั้นพยายามชวนเราปรับ mindset ให้มาเป็น

Stop Staring Start Finishing

คือแทนที่จะไปเอางานใหม่มาเริ่มทำ ทำงานเก่าที่ค้างอยู่ให้เสร็จก่อน การที่เรามี WIP Limit นั้นไม่ใช่การปฏิเสธงาน เพียงแต่ยังไม่เริ่มทำงานใหม่เท่านั้นเอง ไม่น่าเชื่อว่าแค่ทำได้เท่านี้ ก็ได้ agility เพิ่มมามหาศาลแล้ว และยังเป็นพื้นฐานที่ดีที่จะทำให้เราปรับปรุงให้ดีขึ้นได้ต่อๆไป

สนใจศึกษา Kanban เพิ่มเติมอย่างลึกซึ้ง กลางเดือน ม.ค. ปี หน้า 2019 เราจะมีกูรูระดับโลก คือคุณ Klaus Leopold บินมาเปิดคลาส Certified Kanban Foundation กันเป็นปีที่ 4 ถ้าสนใจก็ทักมาได้ที่ contact@leaningroup.com นะครับ