Agile 12 Principles....(ตอนจบ)

Agile 12 Principle....(ตอนจบ)

10. Simplicity—The Art of Maximizing The Amount of Work Not Done but Is Essential
11. The Best Requirements, Architecture, and Design Emerge From Self Organizing Teams
12. At Regular Interval, Team Reflects on How to Become More Effective and Tweak Behavior Accordingly

มนุษย์เราทุกคนมี 24 ชมเท่ากันใน 1 วัน
.
.
Warren Buffet อ่านหนังสือได้ปีละ 500 เล่ม (วันละ 1.36 เล่ม)
.
ประธานาธิบดีบารัค โอบามา ในเวลา 8 ปีที่ดำรงตำแหน่ง ทานข้าวกับครอบครัว อาทิตย์ละ 5 วัน
.
เราบ่นๆว่ายุ่ง..ไม่มีเวลา...เราคงไม่กล้าไปเปรียบเทียบกับท่านบารัคว่างานใครสำคัญกว่ากัน
.
Priority Matrix (Eisenhower Matrix) ที่คิดค้นขึ้นมาโดย ประธานาธิบดีสหรัฐคนที่ 34 Dwight D. Eisenhower โดยเครื่องมือนี้จะช่วยให้เราเข้าใจว่า ในวัน/สัปดาห์/เดือน เราทำกิจกรรมอะไรบ้าง

.
.
.
ถึงตรงนี้อยากให้ทุกคนลองเขียน Activities ที่ต้องทำใน 1 อาทิตย์ อย่างน้อยคนละ 20 activities ประชุม ออกกำลังการ งานต่างๆได้หมดทุกอย่าง
.
.
เมื่อได้ครบ 20 Activities แล้วให้นำไปเขียนไว้ใน Quadrant Q1, Q2, Q3, Q4
.
Q1 : สำคัญ, ด่วน
Q2 : สำคัญ, ไม่ด่วน
Q3 : ไม่สำคัญ, ด่วน
Q4 : ไม่สำคัญ, ไม่ด่วน

ส่วนที่ 1 (Q1) คือกิจกรรมที่มีความสำคัญ และเร่งด่วน (Important and Urgent) เช่น การแก้ไขเอกสารที่ผิดให้ลูกค้า การแก้ไขปัญหา server ล่ม การรักษาอาการป่วยของตนเอง เป็นต้น

ซึ่งถ้าใครต้องทำกิจกรรมที่อยุ่ในส่วนนี้เยอะๆ แม้ว่าเขาจะสามารถสร้างคุณค่า (value) ให้กับตนเอง หรือองค์กรได้ (เพราะทำงานที่สำคัญ) แต่มันคงไม่ค่อยดีกับสุขภาพจิตคนนั้นๆเท่าไร เพราะต้องคอยทำงานร้อน หรืองานดับไฟตลอดเวลา

ส่วนที่ 2 (Q2) คือกิจกรรมที่มีความสำคัญ แต่ไม่เร่งด่วน (Important but Not Urgent) เช่น การปรับปรุงกระบวนการทำงาน การพัฒนาคนในทีม การออกกำลังกาย การวางแผนการทำงานรายสัปดาห์ เป็นต้น ซึ่งถ้าเราสามารถบริหารจัดการให้งานส่วนใหญ่ของเราอยู่ภายใต้ส่วนนี้ได้ จะเป็นผลดีกับเรามากๆ เพราะงานหรือกิจกรรมที่เราทำนั้น สามารถสร้างคุณค่าให้ตัวเราเอง หรือองค์กรได้ และไม่มีข้อจำกัดเรื่องเวลามาบีบ และกดดันเหมือนในส่วนที่1

ส่วนที่ 3 (Q3) คือกิจกรรมที่ไม่สำคัญ แต่เร่งด่วน (Not Important but Urgent) เช่นเช็คอีเมล การประชุมที่ไม่ก่อให้เกิดคุณค่าใดๆ ไปดูหนังที่กำลังออกจากโรง เป็นต้น ซึ่งเอาเข้าจริงๆ คนส่วนมากมักจะทำกิจกรรมที่อยู่ในส่วนนี้ค่อนข้างเยอะ และผลที่ได้คือเรารู้สึกว่าตัวเองยุ่งตลอดเวลา แต่กลับไม่สามารถสร้างคุณค่า หรือประโยชน์อะไรให้ตนเอง และองค์กรเท่าที่ควร

ส่วนที่ 4 (Q4) คือกิจกรรมที่ไม่สำคัญ และไม่เร่งด่วน (Not Important and Not Urgent) เช่น เล่น facebook นินทาชาวบ้าน ตามข่าวดารา เป็นต้น ซึ่งคนที่มีกิจกรรมนี้ค่อนข้างเยอะ มักจะมีความรู้สึกว่า วันๆหนึ่งผ่านไปเร็วเหลือเกิน

แม้ว่ามนุษย์เราจะไม่ชอบทำงานที่มีความเร่งด่วน แต่ความจริงอย่างหนึ่งที่เลี่ยงไม่ได้ก็คือ ถ้าเราไม่ยอมทำกิจกรรมในส่วนที่ 2 (กิจกรรมที่มีความสำคัญ แต่ไม่เร่งด่วน) ไปก่อน วันใดวันหนึ่ง มันจะกลายเป็นกิจกรรมในส่วนที่ 1 (กิจกรรมที่มีความสำคัญ และเร่งด่วน) และเราต้องเข้าสู่สภาวะไล่ดับไฟ แก้ปัญหาเฉพาะหน้า ภายใต้สภาวะการทำงานที่กดดัน เพราะมีเงื่อนไขของเวลามาบีบไปโดยปริยาย

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

Priority Matrix สำหรับทีม
Q1 : สำคัญ, ด่วน
- Defect ที่เป็น Stopper, Server ล่ม, Production Issues

Q2 : สำคัญ, ไม่ด่วน
- Backlog ที่มี Value มากที่สุด ใช้เวลาน้อยที่สุด (Must have and should have)
- คุณภาพขง Backlog ส่งผลโดยตรง ถ้าคุณภาพงานไม่ดีเมื่อเราเจอทีหลังมันมักจะเป็นงานดับไฟเสมอ
- Backlog ประเภท Technical Improvement

Q3 : ไม่สำคัญ, ด่วน
- Backlog ประเภทอัพเดตฐานข้อมูลที่อยู่, แก้คำผิด

Q4 : ไม่สำคัญ, ไม่ด่วน
- งานพวกนี้มักรวมไปอยู่กับ Backlog ใน Q2 ถ้าไม่ทำการ Refinement ให้ดี

ทีมที่ประสบความสำเร็จพวกเขามักเน้นทำกิจกรรมในส่วนที่ 2 มากกว่าส่วนอื่นๆเสมอ นั่นแหละครับหัวใจที่ว่า "The Art of Maximizing The Amount of Work Not Done but Is Essential"
.
.
.
เรื่องที่ 2
.
Behind the scene.
Netflix culture : Responsibility & Freedom (https://jobs.netflix.com/culture)

1. 1. encourage independent decision-making by employees
2. 2. share information openly, broadly, and deliberately
3. 3. are extraordinarily candid with each other
4. 4. keep only our highly effective people
5. 5. avoid rules
Our core philosophy is people over process. More specifically, we have great people working together as a dream team. With this approach, we are a more flexible, fun, stimulating, creative, collaborative and successful organization.

1. ให้อิสระ เพิ่มอำนาจการตัดสินใจให้แก่พนักงานในสิ่งที่ถูกต้อง สร้างความเป็นเจ้าของ
ให้แรงบันดาลใจมากกว่าเจ้ากี้เจ้าการ, Context not control หัวหน้าต้องให้วิสัยทัศน์และเป้าหมายวิธีการทีมเป็นคนคิดเอง เมื่อเกิดความผิดพลาดให้หัวหน้ามองย้อนกลับมามองดูตัวเองว่าได้ให้ Context ถูกต้องไหม เราได้ให้ข้อมูลลูกน้องดีหรือเปล่า พนักงานถามหัวหน้าให้น้อยที่สุด หัวหน้าคือสอนและให้ข้อมูลมากที่สุด
- ยิ่งโตกฎต้องยิ่งลดลง
- ความยืดหยุ่นในการทำงานสำคัญกว่าแค่ความสำเร็จระยะสั้น คนเราจะทำงานได้ดีก็ต่อเมื่อได้บริหารเวลาของตัวเอง
.
2. ทุกข้อมูล : ต้องเปิดเผยต้องแชร์ได้ กว้างขวางและเป็นระบบ
- พนักงานทุกคนต้องเข้าใจธุรกิจ รู้ตัวเลขรายได้ รู้ Business Model รู้คู่แข่งมีอะไร เปิดเผยให้หมด เพื่อที่ว่าเข้าจะรู้ว่าตัวเองอยู่ตรงไหนของฟันเฟืองของบริษัท และจะช่วยองค์กรได้อย่างไร
- ถ้าต้องตัดสินใจเรื่องใหญ่ๆเปิดเป็น Open Document เปิดเผยเลยว่าทำไมหัวหน้าตัดสินใจในวันนั้นเพราะอะไร เมื่อเกิดความผิดพลาดจะได้รู้ว่าเลือกแบบนั้นเพราะอะไร หัวใจของการเปิดเผยข้อมูลเพื่อสร้างความเป็นเจ้าของ เหมือนกับที่เรารู้สึกเป็นเจ้าของบ้าน เพราะเรารู้ทุกส่วนของบ้าน
.
3. พูด Feedback แบบ Constructive กันต่อหน้าตรงๆ ห้ามลับหลัง ยกตัวอย่างเช่น
- เราจะดีขึ้นได้อย่างไร
- มี Feedback อะไรบ้างที่ยังไม่ได้แชร์
- การให้ Feedback ที่ดี ทำให้ทุกคนได้เรียนรู้และเก่งขึ้น
- Data Driven ใช้ในการ Feedback โดยเอาลูกค้าเป็นที่ตั้ง ไม่ใช่แผนกเธอ หรือ ลูกน้องเธอ
.
4. เก็บแต่คนที่เก่งมีประสิทธิภาพไว้ ไม่เชื่อ Culture ทำงานแบบพี่น้อง ครอบครัว
ต้องทำงานแบบ Sport team เพราะมีเป้าหมายและความทะเยอทะยานไปด้วยกัน รักกัน ตัดสินกันด้วยผลงาน ทีมต้องมาการก่อนเสมอ มากกว่าเก่งตัวคนเดียว
.
5.เลี่ยงกฎให้ได้มากที่สุด (บริษัทยิ่งโต กฎยิ่งลด)
นโยบายการลางานพักร้อนไม่มีกำหนด, ลาคลอดได้ 1 ปี(ได้เงินเดือนด้วย), ไม่มีกำหนดเวลาเข้างาน เชื่อ Great work ส่งงานให้ครบ
.
.
.
ลองดูรูปนี้ครับ เมื่อ Autonomy : High, Alignment : High

พอเริ่มเข้าใจแล้วใช่ไหมครับว่าทีมจะเริ่ม Self-Organizing ได้ต้องมีปัจจัยด้านใดบ้าง
ไว้วันหลังผมจะลงลึกถึงวิธีการวัดผลของการทำทีมในฐานะ Scrum Master
.
.
เรื่องที่3
.
เด็กผู้ชายคนหนึ่งเข้าเรียนในโรงเรียนประจำ หลังจากนั้นไม่นานพ่อของเขาได้เสียชีวิต เขาก็ได้ย้ายโรงเรียนไปเรียนโรงเรียนศิลปะ และตัวเขาเองค้นพบว่าชื่นชอบการออกแบบมากกว่าเรียนศิลปะทั่วไป จึงไปเข้าเรียนต่อที่ Royal College of Art ในสาขาการออกแบบอุตสาหกรรม ซึ่งที่นี่เอง ที่ทำให้เขาได้ค้นพบความหลงใหลในการออกแบบเชิง Functional Design ที่เน้นประโยชน์ใช้สอยของผลิตภัณฑ์เป็นหลัก
.
.
ในวัย 23 ปี
ที่กำลังศึกษาอยู่ที่ Royal College of Art เด็กหนุ่มได้เริ่มมีโอกาสสร้างงานออกแบบ โดย Jeremy Fry ประธานของ Rotork ได้เสนองานออกแบบเรือบรรทุก Rotork Sea Truck เรือบรรทุกความเร็วสูงที่สามารถเดินทางได้ 50 ไมล์ต่อชั่วโมง และสามารถจอดได้โดยไม่มีท่าจอดเรือ ซึ่งเรือลำนี้ถูกนำไปใช้ในอุตสาหกรรมต่างๆ เช่น อุตสาหกรรมน้ำมันและการก่อสร้าง รวมทั้งใช้ในกองทหารของอังกฤษ.
.
ต่อมาในปี 1974 เด็กหนุ่มในวัย 27 ปี ได้คิดค้น Ballbarrow รถเข็นพลาสติกที่มีล้อเป็นลูกบอลแทนล้อปกติขึ้น ซึ่งนอกจากไม่ทำให้เกิดสนิมแล้ว ยังไม่จมไปกับดินอ่อน หรือติดกับคอนกรีตเวลาเข็นอีกด้วย ฟังดูเหมือนเรื่องราวเริ่มต้นได้ดี แต่ความสำเร็จนี้อยู่ได้ไม่นาน เขาถูกบีบให้ต้องขาย Ballbarrow ให้กับนักลงทุน เพราะความผิดพลาดด้านการจดสิทธิบัตร ซึ่งถือเป็นบทเรียนราคาแพง ที่ทำให้เขาตั้งใจว่าจะไม่พลาดซ้ำกับสิ่งประดิษฐ์ชิ้นต่อไป

.

.

การเริ่มต้นสร้างธุรกิจ 

การทำให้คนยอมรับในไอเดียแปลกใหม่ไม่ใช่เรื่องง่าย แม้แต่ตัวเขาเอง ที่ค้นคิดออกแบบเครื่องดูดฝุ่นที่มีประสิทธิภาพการทำงานอย่างแท้จริง หลายบริษัทให้ความสนใจ แต่ไม่มีบริษัทไหนเซ็นสัญญา เนื่องจากเทคโนโลยีที่ คิดค้น ขัดแย้งโดยสิ้นเชิงกับผลิตภัณฑ์เครื่องดูดฝุ่นของบริษัทที่มีถุงเก็บฝุ่นเป็นองค์ประกอบสำคัญ

.

.

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

.

.

ความล้มเหลว 5,126 ครั้ง

หลังจากวันที่เขาเริ่มจัดการกับเครื่องดูดฝุ่นอย่างจริงจัง เขาก็หมกมุ่น ใช้เวลาค้นคว้า ลองผิดลองถูกสร้าง prototype มากถึง 5,127 แบบ ในช่วงเวลาหลายปี แต่เขาก็ไม่เคยหยุดและยอมแพ้ จนในที่สุดเขาก็ทำสำเร็จ สามารถสร้าง DC01 (Dyson Cyclone) เครื่องดูดฝุ่นที่ไม่ต้องใช้ถุงกรองตัวแรกของโลก และหลังจากปล่อยสินค้าออกสู่ตลาดได้ไม่นาน DC01 กลายเป็นเครื่องดูดฝุ่นที่ขายดีที่สุดในอังกฤษ

เล่ามาถึงตรงนี้หลายคนคงนึกออกแล้วใช่ไหมครับว่าเด็กหนุ่มคนนี้ชื่ออะไร..ใช่ครับ "เจมส์ ไดสัน"

.

.

ปี 1980 เป็นหนี้มหาศาล ในวัย 33 ถูกโกงซ้ำแล้วซ้ำเล่า จนเฉียดล้มละลาย!

ในช่วงระหว่างที่กำลังพัฒนา DC01 James Dyson ต้องเผชิญกับปัญหาจากการทำธุรกิจมากมาย จนทำให้เขาต้องเป็นหนี้มหาศาล แทบล้มละลายเลยก็ว่าได้ แต่ถึงกระนั้น เขาก็ยังไม่หยุดยั้งความตั้งใจ เขาเดินหน้าหาบริษัทที่มีแนวทางเดียวกัน จนในที่สุดก็ได้มาเจอกับ Apex Inc. บริษัทสัญชาติญี่ปุ่น จนตกลงเซ็นสัญญาร่วมกัน และเริ่มก่อตั้งบริษัท Dyson ขึ้นเมื่อปี 1993

.

.

แล้วความสำเร็จก็มาถึงจนได้ผลิตภัณฑ์ของ Dyson ได้พิสูจน์แล้วว่าประสบความสำเร็จในเชิงพาณิชย์ โดยปัจจุบัน Dyson มีพนักงานมากกว่า 12,000 คนทั่วโลก ซึ่งในจำนวนนี้เป็นพนักงานอยู่ที่อังกฤษ 4,800 คน ในด้านผลกำไร เมื่อปี 2017 Dyson มีรายได้อยู่ที่ 801 ล้านปอนด์ เพิ่มขึ้นราวๆ 27% จากปีก่อนหน้านอกจากนี้ Forbes ยังได้ประเมินความมั่งคั่งของท่านเซอร์ ด้วยมูลค่าทรัพย์สินที่มีมากกว่า 5 พันล้านดอลลาร์สหรัฐ และจากการถือครองที่ดินจำนวนมากในอังกฤษ ทั้งที่อยู่ในเมือง Lincolnshire, Oxfordshire และ Gloucestershire

.

.

ปรัชญาในการทำธุรกิจ ของ "เจมส์" คือ "ต้องลงมือทำ" ตัวเลขรายได้ไม่ได้เป็นเครื่องชี้วัดความสำเร็จ เขาบอกว่า เขาลงทุนสูงกับสถานที่ทำงาน ให้ความสำคัญกับ "เก้าอี้" ไดสันลงทุนซื้อเก้าอี้ราคาสูงให้กับพนักงานทุกคน เพื่อให้ทุกคนนั่งทำงานได้อย่างสบาย ดีต่อสรีระ และสุขภาพ พื้นที่ในสำนักงานได้รับการออกแบบให้เปิดโล่ง เอื้อต่อการติดต่อสื่อสารระหว่างกัน ให้ทุกคนรู้สึกเป็นอันหนึ่งอันเดียวกัน เป็นส่วนหนึ่งของทีม โดยพนักงานออกแบบกราฟิกและวิศวกรจะมีพื้นที่ทำงานอยู่ตรงศูนย์กลางของทุกส่วน เนื่องจากจุดเริ่มของการปฏิบัติงานทั้งหมดจะออกมาจากส่วนนี้ และแต่ละแผนกจะไม่มีการกั้นโซน หรือแบ่งแยกด้วยการออกแบบ สภาพแวดล้อมที่ทำงานในลักษณะนี้ จะช่วยให้พนักงานมีความคิดสร้างสรรค์และมีไอเดียสดใหม่อยู่เสมอ
.
การทำงานโดยให้ความสำคัญกับเรื่องเล็กๆ น้อยๆ เป็นสิ่งที่ซีอีโอท่านนี้ทำต่อเนื่อง เขาเลิกใช้ระบบกระดาษ memo ในการติดต่อสื่อสาร เพราะคนที่ได้รับ memo จะอ่านหรือเปล่าก็ไม่รู้ หรือ อาจจะอ่านแล้วเข้าใจคลาดเคลื่อน การติดต่อสื่อสารที่ดีที่สุด คือ คุยกันต่อหน้า เพื่อความเข้าใจที่ตรงกันและปฏิสัมพันธ์อันดีระหว่างกัน ไม่มีใครใส่สูท ผูกเนกไท แต่ก็คำนึงถึงความสุภาพเรียบร้อยของเครื่องแต่งกาย
.

.

.

ข้อ 12 ใน Agile Principle เป็นสิ่งที่ผมชอบที่สุดและสำคัญมากสุดในการทำทีม มันคือ Feedback loop ยิ่งเราสามารถทำกระบวน Feedback บ่อยได้เท่าไร เรายิ่งมีโอกาสประสบความสำเร็จมากขึ้นทำนั้น เพราะเรามีโอกาสที่จะเรียนรู้จากสิ่งที่เราทำผิดพลาด

.

ใน Scrum เรามีการทำ Feedback loop 2 ส่วนที่สำคัญด้วยกัน

1. Feedback loop ในส่วนของ Product เราเรียก Meeting นี้ว่า Sprint Review

2. Feedback loop ในส่วนของ Process การทำงานทีม เราเรียก Meeting นี้ว่า Sprint Retrospective 

.

เราทุกคนเคยเป็นเด็กทารก...วันที่เราต้องการเดิน....เราล้มกี่ครั้ง ถึงเราจะเริ่มเดินได้ สมมุตินะครับถ้าตอนนั้นสั่งตัวเองตอนที่เป็นเด็กว่า เราจะล้ม 5 ครั้งพอ ..... เราทุกคนยังจะเดินได้อยู่ทุกวันนี้ไหมครับ

ขอให้โชคดีในการนำ Agile ไป Adopt กับองค์กรและทีมงานครับ

Reference :
- https://medium.com/readmoreth/ctc2019-part-1-ae6bf9e147be- K.รวิศ Podcast
- The secret sauce : Netflix (The standard)
- https://www.brandbuffet.in.th/2019/06/the-failure-lessons-of-james-dyson/
- http://www.thansettakij.com/content/32744

Agile 12 Principles....(ตอนที่3)

Agile 12 Principles.... (ตอนที่3)


Transparency
.
.
ปี 1968 นักวิจัยของบริษัทชื่อ สเปนเซอร์ ซิลเวอร์ (Spencer Silver)

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

.

.

สี่ปีต่อมา

ในเช้าวันหนึ่ง อาร์เธอร์ ฟราย (Arthur Fry) นักวิจัยอีกคน ได้เจอปัญหากระดาษคั่นหน้าหนังสือเพลง ปลิวหลุดทุกครั้งที่เปลี่ยนหน้า ระหว่างร้องเพลงในโบสถ์ สิ่งที่ฟรายต้องการคือ อะไรที่มายึดกระดาษติดกับหนังสือ และลอกออกไปใช้ใหม่ โดยไม่ทำให้หนังสือเสียหาย
.

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

.

.
จากการค้นพบครั้งนั้น ทำให้ “กาวพลังห่วย” ได้เกิดเป็นกระดาษโน็ตสีเหลือง ที่ใช้เป็นอุปกรณ์ช่วยเตือนความจำ นามว่า Post-it เล่ามาถึงตรงนี้หลายคนคงบางอ้อแล้วใข่ไหมครับว่าบริษัทที่เล่ามาคือ 3M นี่แหละคือความโปร่งใสการทำงานของบริษัท 3M

.

.

ฟรายได้รับการยกย่องด้วยตำแหน่งสูงสุดในด้านเทคนิคของบริษัท นั่นคือ นักวิจัยขององค์กร เขาบอกว่า "รางวัลใหญ่สุดของผมก็คือ การได้เห็นผู้คนมากมายชื่นชมและใช้ผลิตภัณฑ์ของผม"

.
.
ภายหลัง 28 ปีของการทำงานกับบริษัท สเปนเซอร์ ซิลเวอร์ ผู้ก่อตั้งร่วมของ Post-it® Notes ได้เกษียณอายุจากบริษัท 3M พร้อมด้วยสิทธิบัตรในสหรัฐฯ มากกว่า 22 รายการภายใต้ชื่อของเขา.
.
ทั้งซิลเวอร์และฟรายได้สิ้นสุดอาชีพการงานของตนเมื่อ 3M ได้รับเกียรติสูงสุดในด้านการวิจัย รวมทั้งได้รับรางวัลต่างๆ มากมายภายในวงการวิศวกรรมระดับสากล.

.

.
Time Management
.
.
กฎของพาร์กินสัน (Parkinson's Law)
“Work expands so as to fill the time available for its completion.”

แปลง่ายว่า "งานจะขยายไปเท่ากับเวลาที่อนุญาตให้มันทำ" ยกตัวอย่างเช่น
.
สมัยเรียนมหาวิทยาลัย อาจารย์ให้การบ้านซึ่งสามารถทำเสร็จภายใน 1 สัปดาห์ แต่อาจารย์กำหนดเวลาให้ 2 สัปดาห์ นักศึกษาส่วนใหญ่มักจะทำเสร็จในไม่กี่วันสุดท้ายก่อนถึงกำหนดส่ง
.
โปรเจคของบริษัทที่ตั้งไว้ 2 ปีเสร็จ พอถึงใกล้ถึงเวลากำหนดมักจะขยายออกมากกว่า 2 ปี อันนี้ Beyond กว่า Parkinson's Law อีกนะครับ
.
จะเห็นได้ว่า งานถูกขยายออกไปตามเวลาที่กำหนดให้เสร็จ เสมอๆ
.

.
ที่มาของกฎพาร์กินสัน
ไซริล พาร์กินสัน ( Cyril Parkinson ) นักประวัติศาสตร์ชาวอังกฤษ เริ่มสังเกตเห็นแนวโน้มในช่วงที่เขาทำงานอยู่กับหน่วยงานข้าราชการพลเรือน ว่า การปกครองระบบเจ้าขุนมูลนาย ทำให้ประสิทธิภาพการทำงานลดลง เขาพบอีกว่า ถ้ามอบหมายงานง่าย ๆ ให้พนักงานทำ แต่กำหนดเวลาส่งให้สั้นลงกว่าเดิม งานนั้นก็ดูเหมือนจะง่ายขึ้น เพราะพนักงานสามารถทำเสร็จทันกำหนดอยู่ดี จากผลงานนี้เองทำให้เขาได้รับการยกย่องให้เป็นผู้รอบรู้แห่งศาสตร์การบริหารธุรกิจ.
.

Sustainable Development ใน No.8 ของ Agile Principles สำหรับความคิดผมคือการที่เรากำหนดรอบระยะเวลาทำงานที่เท่าเดิมเสมอเพื่อป้องกัน Parkinson's Law และทำการหา Time Boxing และ Priority Matrix ในแง่ของการทำทีมให้เจอ

.
.
Time Boxing
คือการวางแผนการทำงานล่วงหน้าเพื่อกำหนดเวลาอย่างแน่นอนในการทำงานแต่ละงาน โดยกำหนดช่วงเวลางานแต่ละงานเป็นช่วงๆ หรือ ​Timebox และเมื่อเรามีการกำหนดเวลาที่แน่นอนแล้ว ก็เหมือนกับการกำหนด Dead Line ให้กับงานชิ้นนั้นๆเพื่อให้เสร็จสิ้นตามเวลาที่วางแผนไว้ จะได้ไม่ไปกระทบต่อเวลาของงานชิ้นต่อไป 

.

ใน Scrum เองจะกำหนดระยะเวลาของ Scrum Events ไว้ล่วงหน้าและตายตัวในแต่ละ Srpint และกำหนดขอบเขตช่วงเวลาในแต่ละ Scrum Events ยกตัวอย่าง Sprint 2 weeks

1. Daily Stand up (ไม่เกิน 15 นาที)

2. Sprint Planning (ไม่เกิน 4 ชั่วโมง)

3. Product Backlog Refinement (ไม่เกิน 8 ชั่วโมง)

4. Sprint Review (ไม่เกิน 2 ชั่วโมง)

5. Sprint Retrospective (ไม่เกิน 1.30 ชั่วโมง)

*ปล. ไม่เกินหมายความว่าไม่จำเป็นต้องใช้ครบตามเวลานะครับ

.

.

ทำไมเราต้องกำหนด Time Boxing? ทำไมไม่ขยาย Sprint ตามขนาดของเนื้องานเช่นในช่วงระยะเวลานั้นๆ Sprint 2 Weeks เดือนนี้ เดือนหน้าขอปรับเป็น Sprint 4 Weeks
.
.
ลองคิดตามนะ..ถ้าเราปรับเวลาไปตามใจของทุกคนในทีม เราจะไม่รู้เลยว่าจริงๆแล้วงานที่ทำเหมาะสมกับช่วงเวลานั้นหรือไม่ สุดท้ายทีมจะไม่เกิดการ Reflect แล้วจะหาแพะรับบาปคือเวลาเสมอ จุดนี้ต้องระวังให้มาก การทำ Time Boxing คือการทำสะพานเชื่อมไปหา Priotity Matrix สิ่งผมจะพูดในบทความต่อไปครับ
.
กฎของพาร์กินสันสามารถนำไปใช้กับเรื่องต่างๆ ในชีวิตประจำวันได้อีกหลายอย่าง เพียงแค่กำหนดเส้นตายให้กับสิ่งที่ทำ และตั้งใจมุ่งมั่นที่จะทำให้เสร็จตามกำหนดให้ได้ หนึ่งในบุคคลที่ใช้ชีวิตแต่ละวันด้วยการกำหนดเส้นตายให้กับตัวเองคือ สตีฟ จ๊อบส์
.
สตีฟ จ๊อบส์ ให้สัมภาษณ์อยู่บ่อยครั้ง เขามักคิดเสมอว่าวันพรุ่งนี้คือวันสุดท้ายของชีวิต ดังนั้นหากมีสิ่งใดที่สำคัญเขาจะรีบทำทันที และสิ่งใดที่ไม่กล้าทำ เขาจะนึกว่าในเมื่อพรุ่งนี้จะต้องตายแล้ว จะกลัวไปทำไม ความอาย ความล้มเหลว ความผิดหวัง ไม่มีผลอะไรเลยหากต้องตาย
.
.
“Time isn’t the main thing, It’s the only thing”
เวลาไม่ใช่สิ่งสำคัญ แต่มันเป็นเพียงสิ่งเดียวเท่านั้น - ไมล์ส เดวิส.
.
Focus คือการละทิ้งและหาสิ่งที่สำคัญให้เจอ
.
จ็อบส์เคยออกจากแอปเปิ้ลไปแล้วครั้งหนึ่ง แต่เมื่อเขาได้กลับมาทำงานที่นี่อีกครั้ง เขาก็พบว่าบริษัทนี้กำลังหลงทาง ในตอนนั้นแอปเปิ้ลมีผลิตภัณฑ์ถึง 350 ชิ้น แต่จ็อบส์มองว่าผลิตภัณฑ์ก็เหมือนกับบริษัทอื่นๆ ไม่มีอะไรโดดเด่นเป็นพิเศษ
.
.
จ็อบส์ตัดสินใจตัดผลิตภัณฑ์ทิ้งไป 340 ชิ้น เหลือเพียง 10 ชิ้นเท่านั้นที่ควรจะให้ความสนใจอย่างจริงจัง จ็อบส์บอกว่าการโฟกัสคือการปฎิเสธไอเดียดีๆ หลายร้อยไอเดีย แล้วเลือกไอเดียที่สำคัญจริงๆเท่านั้น เมื่อเราตัดไอเดียดีๆทิ้ง เราจะได้ไอเดียที่ยอดเยี่ยมที่สุด
.
.
ความคิดเห็นเช่นนี้ของจ็อบส์ถูกสะท้อนให้เห็นตอนที่แอปเปิ้ลกำลังจะทำไอโฟน (iPhone) เครื่องแรกให้เสร็จสมบูรณ์ก่อนที่จะถูกวางจำหน่าย แต่จ็อบส์พึ่งได้ไอเดียว่าสิ่งที่ควรให้ความสำคัญที่สุดคือหน้าจอ ส่วนประกอบอื่นๆ เป็นเรื่องรอง จ็อบส์จึงบอกทีมงานของเขาให้เริ่มออกแบบไอโฟนกันใหม่
.
จากไอเดียในครั้งนั้นของจ็อบส์ ทำให้แอปเปิ้ลได้สร้างไอโฟนที่ผู้คนนับล้านทั่วโลกได้ใช้กันในปัจจุบัน

คำว่า Continuous Attention นั้น เราทุกคนในทีมตกลงร่วมกันที่จะทำงานที่เราได้มีส่วนร่วมในการแชร์มุมมองความคิดเห็นทั้ง Business, Technical ใน Product Backlog Refinement และ Sprint Planning หมายความว่าทีมงานต้องโฟกัสและละทิ้งในสิ่งที่ไม่จำเป็นที่เกิดขึ้นในระหว่างวัน ตลอดการเดินทางจนกระทั่งจบ Sprint แต่ถ้าเกิดเหตุการณ์ที่ว่าสิ่งที่เราร่วมกันคิดมาด้วยกันมันไปผิดทาง เราก็สามารถยกเลิก Sprint นั้นได้ ประเด็นคือเราละทิ้งสิ่งที่สำคัญแต่น้อยกว่า แล้วหรือยัง
.
.
การวิ่งมาราธอน ถ้าเราไปถามนักวิ่งมาราธอนว่าเหนื่อยไหม?
ทุกคนคงตอบว่าเหนื่อยมาก แล้วถ้าเราถามเค้าว่ามีท้อบางไหม หลายคนของบอกว่าท้อมาก
คำถามถัดไป แล้วมีเทคนิคอะไรที่ทำให้มีกำลังใจไปถึงเส้นชัย? เขาบอกว่ามองเสาไฟฟ้า เขาไม่สนใจว่าเส้นชัยอยู่ที่ไหน แค่มองเสาไฟฟ้าต้นถัดไป พอผ่านไปก็มองหาต้นถัดไปอีก
.
.
เสาไฟฟ้าก็เหมือนเป้าหมายระยะสั้นที่ทำให้เรามีกำลังใจไปต่อ งานในแต่ละ Sprint ก็เช่นกันครับ พยายามหาเสาไฟฟ้าให้เจอครับ

ขอให้โชคดีในการนำ Agile ไปปรับใช้ในองค์กรครับ



ข้อมูลอ้างอิง
(หน้งสือพัฒนาองค์กรและชีวิตด้วยแนวคิด OKRs)
https://bingobook.co/book-summary/steve-jobs/
http://www.ayarafun.com/2011/04/story-of-post-it/
https://www.post-it.co.th/3M/th_TH/post-it-th/contact-us/about-us/
https://www.longtunman.com/13488
https://storylog.co/story/55c1e0c46670de20b48cfd82
https://th.wikipedia.org/wiki/%E0%B8%8B%E0%B8%B5%E0%B8%A3%E0%B8%B4%E0%B8%A5_%E0%B8%99%E0%B8%AD%E0%B8%A3%E0%B9%8C%E0%B8%97%E0%B9%82%E0%B8%84%E0%B8%97_%E0%B8%9E%E0%B8%B2%E0%B8%A3%E0%B9%8C%E0%B8%81%E0%B8%B4%E0%B8%99%E0%B8%AA%E0%B8%B1%E0%B8%99
https://missiontothemoon.co/mindset-and-time-management/
https://ahead.asia/2019/01/18/mission-to-the-moon-creative-talk-2019/

Agile 12 Principles....(ตอนที่2)

 Agile 12 Principles ตอนที่ 2

.
.
ในตอนเริ่มต้น ย้อนกลับไปในช่วง 10,000 ปีก่อนหน้า

มีอะไรบางอย่างในตัว โฮโม ซาเปียนส์ ที่ทำให้เราปรับตัวเพื่อความอยู่รอดและเจริญก้าวหน้าได้ดีในสภาวะยากลำบาก ดีกว่าสายพันธุ์อื่นที่ตัวโตและแข็งแรงกว่า เรามีสมองนีโอคอร์เท็กซ์ (neocortex) ที่ช่วยให้เรามีความสามารถในการติดต่อสื่อสารที่ซับซ้อน เราแตกต่างจากสัตว์อื่นเพราะเรามีโครงสร้างของภาษา มีไวยากรณ์ แต่อีกสิ่งหนึ่งที่เป็นเหตุผลสำคัญที่ทำให้เราอยู่รอดคือ ความสามารถของเราที่จะร่วมมือกัน พวกเราเป็นสัตว์สังคมชั้นสูงที่มีความสามารถในการอยู่รอดและก้าวหน้าขึ้นอยู่กับความช่วยเหลือของคนอื่น

ลองจินตนาการตามครับ สมมุติว่าเราเอามามนุษย์ไปปล่อยในป่ากับลิง ลองคิดดูว่าใครรอด
- มนุษย์ 1 : 1 ลิง ใครรอด?
- มนุษย์ 10 : 10 ลิง ใครรอด?
- มนุษย์ 100 : 100 ลิง ใครรอด?
- มนุษย์ 1,000 : 1,000 ลิง ใครรอด?
- มนุษย์ 10,000 : 10,000 ลิง ใครรอด?

ความสามารถของเราที่จะทำงานร่วมกัน ที่จะช่วยเหลือและปกป้องกันและกันนั้นทำงานได้อย่างดี ดีจนมากกว่าเราทำได้แค่อยู่รอด
.
.

วงกลมแห่งความปลอดภัย

.

มีสิงโตตัวหนึ่งที่มักจะเดิน ด้อมๆ มองๆ อยู่แถวๆ ทุ่งหญ้า ที่มีวัวอาศัยอยู่ 4 ตัว หลายๆครั้งที่สิงโตพยายามจะโจมตีพวกมันแต่เมื่อสิงโตเข้ามาใกล้ พวกมันจะส่งสัญญาณให้กันและเอาหางชนกันทำให้ไม่ว่าสิงโตจะเข้ามาจากทางไหนก็จะเจอเขาแหลมคมของวัวเสมอ แต่จนวันหนึ่งพวกวัวก็ทะเลาะกันเองและแต่ละตัวก็แยกกันเล็มหญ้าตามมุมต่างๆของทุ่งหญ้า นับตั้งแต่วันนั้นสิงโตก็เข้ากินพวกวัวทีละตัวและกินมันหมดทุกตัวในที่สุด

-นิทานอีสป หกร้อยปีก่อนคริสตกาล-

.
.
เดวิท มาร์เควท (David Marquet) เคยเป็นนักขับเรือดำน้ำอาชีพ เขาจบการศึกษาด้วยผลการเรียนเกือบเป็นอันดับหนึ่ง จากโรงเรียนกองทัพเรือ เขาเป็นคนฉลาดทีเดียว อันที่จริงจากความฉลาดนี่เองทำให้เค้าไต่ระดับอย่างรวดเร็วในกองทัพเรืออเมริกา
.
กองทัพเรือก็เหมือนกับองค์กรอื่นๆ อีกมากมาย พวกเขาให้รางวัลคนฉลาดที่มุ่งสู่เป้าหมายเสมอด้วยการยอมรับและการเลื่อนตำแหน่ง เพราะแบบนั้นเรือเอกมาร์เควทได้รับการยอมรับและได้รับเกียรติสูงสุดเท่าที่จะมีได้ เขากำลังจะได้เป็นกัปตันของ USS Olympia เรือดำน้ำพลังงานนิวเคลียร์โจมตีเร็ว หมวด Los Angeles
เพื่อเป็นการเตรียมตัวสำหรับงานใหญ่ เรือเอกมาร์เควทใช้เวลาเป็นปีเพื่อศึกษาระบบและข้อมูลส่วนตัวของลูกเรือของ Olympia แต่ละคน เขาทำงานหนัก รู้จักสายไฟทุกเส้น สวิตซ์ทุกอัน เหมือนคนจำนวนมากที่มีอำนาจควบคุม เขารู้สึกว่าเขาต้องรู้ให้มากเท่ากับหรือมากกว่าลูกเรือคนอื่นถึงจะเป็นผู้นำที่เชื่อถือได้
.
สองสัปดาห์ก่อนหน้าที่จะได้คุมเรือ Olympia เขาได้รับโทรศัพท์เปลี่ยนแปลงจากผู้มีอำนาจ เขาจะไม่ได้คุมเรือ Olympia แล้ว แต่จะได้คุมเรือ USS Santa Fe แทน ซึ่งเป็นเรือดำน้ำหมวด Los Angeles เหมือนกัน แต่สิ่งที่แตกต่างออกไปคือ ลูกเรือของ Santa Fe ทุกคนอยู่อันดับท้ายๆในด้านความพร้อม ในขณะที่ลูกเรือ Olympia คือที่สุดแล้วของลูกเรือ
.
และในวันที่ 8 มกราคม ปี 1999
เรือ Santa Fe  ได้แล่นออกจากท่าเรือ Pearl Harbor ในฐานะเรือที่ใหม่สุดของกองทัพเรือ เรือ Santa Fe มีเครื่องมือจำนวนมากที่ต่างจากสิ่งที่เรือเอกมาร์เควทได้ฝึกมาสำหรับเรือ Olympia และอย่างที่ปรากฎเสมอมา นิสัยเก่าๆ มักจะแก้ยาก แทนที่จะถามคำถามเพื่อช่วยให้ตัวเองได้เรียนรู้จากลูกเรือมากขึ้น เพื่อเติมเต็มช่องว่างในสิ่งที่เค้าไม่รู้ เรือเอกมาร์เควทเก็บความจริงนี้ไว้กับตัวเอง และเลือกที่จะทำสิ่งที่เขารู้ดีที่สุดคือเริ่มออกคำสั่ง
.
วันต่อมาในทะเล เรือเอกมาร์เควทตัดสินใจที่จะเริ่มลองการฝึก การฝึกลำดับที่ 1 ผ่านไป แต่เรือเอกต้องการกดดันลูกเรือของเขามากกว่านั้น เพื่อที่จะดูว่าเขาจะทำอย่างไรเมื่อมีแรงกดดันมากขึ้น เขาให้คำสั่งง่ายๆกับเจ้าหน้าที่ประจำเรือ คนที่ควบคุมทิศทางและมีประสบการณ์มากที่สุดบนนั้น "ไปข้างหน้าสองในสาม" เจ้าหน้าที่ประจำเรือรับคำสั่งจากกัปตันและทวนเสียงดังสั่งให้คนขับเรือเร่งความเร็วขึ้นอีก "ไปข้างหน้าสองในสาม" เขาพูดกับคนขับพวงมาลัย แต่ไม่มีสิ่งใดเกิดขี้น เรือดำนำ้ยังคงความเร็วเท่าเดิม
.
เรือเอกมาร์เควทละสายตาจากกล้องดูเหนือน้ำและหันไปหา "คนขับพวงมาลัย" ที่กำลังบิดตัวไปมาอย่างอึดอัด เรือเอกมาร์เควทตะโกนถาม "มีปัญหาอะไร?" กะลาสีหนุ่มตอบกลับมาว่า "ท่านครับมันไม่มีปุ่มสองในสามครับ" เรือลำนี้ไม่เหมือนกับลำอื่นที่เรือเอกมาร์เควทเคยผ่านมา เรือที่ใหม่อย่าง Santa Fe ไมได้มีปุ่มสองในสามสำหรับมอเตอร์ที่ใช้แบตเตอรี่
.
เรือเอกมาร์เควทหันไปถามผู้ควบคุมทิศทางซึ่งอยู่บนเรือลำนี้มากกว่าสองปีแล้วว่า "เขารู้ไหมว่ามันไม่มีปุ่มสองในสาม" รู้ครับท่าน เรือเอกมาร์เควทถามเขาอีกว่า "แล้วทำไมคุณถึงออกคำสั่งล่ะ?"
"เพราะคุณบอกให้ผมทำแบบนั้น" เจ้าหน้าที่ตอบ
.
จุดนั้นเองที่เรือเอกมาร์เควทถูกบังคับให้เผชิญหน้ากับความเป็นจริงของสถานการณ์ :
- ลูกเรือเขาถูกฝึกมาให้ทำตามคำสั่ง
- เขาถูกฝึกมาสำหรับเรือดำน้ำอีกลำ
หากว่าถูกคนทำตามคำสั่งเขาอย่างไม่ลืมหูลืมตา เมื่อนั้นสิ่งที่เลวร้ายมากอาจเกิดขึ้น
.
.
จะเกิดอะไรขึ้นเมื่อผู้นำทำพลาดในวัฒนธรรมที่ผู้นำทำพลาดจากบนลงล่าง? ทุกๆคนจะตกเหวตาย นั่นคือสิ่งที่เรือเอกมาร์เควทได้เรียนรู้

"คนที่อยู่บนตำแหน่งบนๆ" เรือเอกมาร์เควทอธิบาย "มีอำนาจควบคุมทุกอย่างแต่ไม่มีข้อมูลเลย แต่คนที่อยู่ระดับล่างมีข้อมูลทุกอย่างแต่ไม่มีอำนาจควบคุม ถ้าคนที่ไม่มีข้อมูลยังไม่ยอมสละอำนาจของตัวเอง องค์กรจะไม่มีทางไปได้ดีขึ้น ราบรื่นขึ้น เร็วขึ้นและไปถึงศักยภาพสูงสุดได้เลย"
.
เรือเอกมาร์เควทได้เข้าใจว่าบทบาทของผู้นำไม่ใช่การตะโกนออกคำสั่งและรับผิดชอบต่อความสำเร็จหรือล้มเหลวของภารกิจ แต่เป็น
- รับผิดชอบความสำเร็จของสมาชิกลูกเรือแต่ละคน
- มอบความรับผิดชอบแก่พวกเขาและเชื่อว่าพวกเขาจะทำภารกิจคืบหน้าไปได้
- ให้ทิศทางและมอบการปกป้อง
ลูกเรือก็จะทำในสิ่งที่ต้องทำเพื่อทำให้ภารกิจเดินไปข้างหน้า
.
.
สิ่งหนึ่งที่เรือเอกมาร์เควทเปลี่ยนแปลงคือวัฒนธรรมการขออนุญาตไปเป็นวัฒนธรรมแห่งความตั้งใจ เขาได้ห้ามคนในเรือพูดว่า "ขออนุญาต" และถูกแทนที่ด้วยสิ่งที่ง่ายๆ "ท่านครับผมตั้งใจจะเอาเรือลงน้ำครับ" ห่วงโซ่แห่งคำสั่งยังคงอยู่ สิ่งเดียวที่เปลี่ยนแปลงคือด้านจิตใจ คนที่ทำงานตอนนี้มีอำนาจของตัวเองแทนที่จะเป็นเพียงแค่ทำงานที่ได้รับคำสั่งมา
.
เรือเอกมาร์เควท เขาแบ่งปันสิ่งที่เขารู้ ขอให้คนที่มีความรู้ช่วยทำหน้าที่ของพวกเขาและเริ่มต้นสร้างความสัมพันธ์ใหม่ในเครือข่าย ผู้นำที่อ่อนแอจะหวงสิ่งเหล่านี้และมีความเชื่อผิดๆว่าความฉลาด ยศ หรือความสัมพันธ์ทำให้พวกเขามีค่า แต่ไม่ใช่กับในองค์กรที่มีวงกลมแห่งความปลอดภัยแข็งแรง ไม่เพียงแต่ผู้นำยินดีที่จะแบ่งปันความรู้ แต่คนอื่นๆก็เช่นกัน ผู้นำคือคนที่กำหนดบรรยากาศ
.
.
เมื่อผู้นำของเราเปิดเผยช่องว่างในเรื่องความรู้และความผิดพลาด ไม่เพียงแต่เรายินดีที่จะช่วยเหลือ แต่เรายินดีที่จะแบ่งปันเวลาที่เราทำผิดพลาดหรือมีบางสิ่งผิด ในวงกลมแห่งความปลอดภัย ความผิดพลาดไม่ใช่สิ่งที่ต้องกลัว ในองค์กรที่ไม่มีความปลอดภัยผู้คนจะปกปิดความผิดหรือปัญหาเพื่อเอาตัวรอด ปัญหาก็คือความผิดพลาดและปัญหาเหล่านั้น ถ้าไม่ได้รับการระบุแล้ว จะสะสมเพิ่มขึ้นและปรากฎมาเมื่อมันใหญ่เกินกว่าจะแก้ได้
.
.
นี่คือสิ่งที่เรือเอกมาร์เควทถูกบังคับให้เรียนรู้ เขาฝืนสัญชาตญาณที่ต้องการควบคุมทุกอย่าง ตอนนี้เขายินดีที่จะมอบให้คนอื่นและเห็นคนอื่นก้าวหน้าในความรับผิดชอบที่ได้รับ ความสัมพันธ์บนเรือดำน้ำแข็งแกร่งขึ้นและวัฒนธรรมโดยรวมของความเชื่อใจและความร่วมมือกันก็พัฒนาขึ้นอย่างมาก ซึ่งครั้งหนึ่งเคยอยู่ระดับล่างสุดของกองเรือสหรัฐอเมริกาก็กลายเป็นลูกเรือที่เยี่ยมที่สุดในประวัติศาสตร์กองทัพเรือ
.
.
.
จากเรื่องราวที่ผมเล่าโดยเอาเนื้อหาบางส่วนมาจากหนังสือ 2 เล่ม Sapiens: A Brief History of Humankind by Yuval Noah Harari, Leader eat last by Simon Sinek

คงพอจะเห็นภาพในสิ่งที่ Agile Principles ข้อที่ 4,5,6 กำลังจะบอกอะไรเรา
4) Work Together
5) Trust and support
6) Face-to-face conversation

ผมทิ้งคำถามไว้ 4 ข้อเพื่อให้ลองไปคิดดูกันครับ
1. เราเชื่อใจและปกป้องทีมหรือเพื่อนเรา หรือไม่?
2. เราคุยกันผ่าน Chat Application มากกว่าเจอหน้ากันหรือไม่?
3. เราทำงานร่วมกันในทุกๆวันเพื่อแชร์ข้อมูลกันและกัน ยกตัวอย่างเช่น Business Knowledge, Technical Knowledge หรือไม่? หรือเราแค่ส่งอีเมลถามกันทั้งที่นั่งทำงานอยู่ฝั่งตรงข้ามกัน
4. เรา Blame กันและกันเมื่อเกิดข้อผิดพลาดขึ้นหรือไม่?

Quote ดีดีของเรือเอกมาร์เควท
"เป้าหมายของผู้นำคือไม่ออกคำสั่งใดๆ ผู้นำต้องให้ทิศทางและความตั้งใจและปล่อยให้คนอื่นค้นหาสิ่งที่ต้องทำและวิธีที่จะไปถึงให้ได้"

แล้วทีมงานคุณหรือองค์กรคุณมี Agile Mindset แล้วหรือยัง...

Agile 12 Principles....(ตอนที่1)

วันนี้ผมอยากมาแชร์มุมมองผมในคำว่า Agile ที่ทุกคนพูดถึงในหลายมุมมอง
ยกตัวอย่างเช่น

• Agile Methodology
• Agile Process
• Agile Project Management
• Agile Software Development

Agile Methodology? (อ้างอิงจาก Wikipedia)

Is the systematic, theoretical analysis of the methods applied to a field of study. It comprises the theoretical analysis of the body of methods and principles associated with a branch of knowledge. Typically, it encompasses concepts such as paradigm, theoretical model, phases and quantitative or qualitative techniques.

อไจล์คือ ขั้นตอนวิธี กฎ และการคาดการณ์อย่างมีหลักการ จริงหรือ?

Agile Process?

A process is a series of steps and decisions involved in the way work is completed.

อไจล์คือขั้นตอนการทำงานรวมการตัดสินใจเพื่อให้งานสำเร็จ จริงหรือ?

Agile Project Management?

อไจล์คือวิธีการจัดการโครงการ จริงหรือ?

Agile Software Development?

อไจล์คือการพัฒนาซอฟแวร์ จริงหรือ?

.

.

.

เราลองมาดูหลักการ 12 ข้อของอไจล์กันครับ?

1) Our highest priority is to satisfy the customer through early and continuous delivery of value software.

ข้อที่ 1 สำหรับผมมันหมายถึง Customer Centricity เราส่งมอบ Project/Product บนความพอใจลูกค้าหรือความพอใจของทีมเรา บริษัทเรา ผลตอบแทนของเรา ความสะดวกสบายของเรา

เรื่องนี้เป็นเหตุการณ์ที่เกิดขี้นกับตัวผม....ผมเป็นคนชอบสั่งสินค้าออนไลน์ เพราะว่าสั่งทิ้งไว้ เดี๋ยวก็มีคนมาส่งของให้ที่บ้านสะดวกดี ผมสั่งหนังสือออนไลน์ผ่าน Website และต้องการออกใบกำกับภาษีเต็มรูปแบบเพื่อนำไปใช้ลดหย่อนภาษี ก็ทำขั้นตอนปกติซึ่งไม่น่าจะมีอะไร พอถึงขั้นตอนสุดท้าย คิดในใจ อ้าว....ทำไมไม่เห็นมี Section ให้กรอกข้อมูลส่วนตัวเพื่อออกใบกำกับภาษีเลย แต่ด้วยโปรโมชั่นส่วนลดที่ยั่วใจก็ชำระเงินไป

.

.

หลังจากนั้น

ผมเปิด Google และค้นหาวิธีการขอใบกำกับภาษีของบริษัทนั้น หายังไงก็หาไม่เจอครับ 

1. [วันเสาร์] เข้าไปที่หน้าสอบถามเพิ่มเติมข้อมูลของ Website ที่ผมทำการสั่งหนังสือ และกรอกคำถามที่หน้าเว็บ และพร้อมทั้งส่งเมลล์ไปหา Customer Service และ....หาวันที่ และเวลา Call Center เปิดทำการ พบว่าเป็นทำการวันธรรมดา 09.00-17.00

2. [วันจันทร์] โทรเช้าไปหา Call Center และถามว่าถ้าต้องการออกใบกำกับภาษีต้องทำอย่างไรบ้าง เจ้าหน้าที่แจ้งมาว่าให้ผมส่งเมลล์เข้าไป ทางร้านค้าจะส่งใบกำกับภาษีมาพร้อมหนังสือ

.

.

ถ้าทุกอย่างเป็นไปตามจากที่ผมเล่ามา วันที่ผมได้รับหนังสือก็คงจะมีใบกำกับภาษีแนบมาด้วย

ลองคิดตามนะครับ ข้อ 1,2 ที่ผมเล่ามา ผมชำระเงินเสร็จผมต้องทำอะไรบ้าง

- ผมเองต้องเสียเวลาหาข้อมูล ว่าขอใบกำกับภาษีมีวิธีการยังไง

- กรอกข้อมูล เพื่อสอบถามการออกใบกำกับภาษีบนหน้า Website

- ส่งเมลล์ไปที่ Customer Service สอบถามเรื่องการขอใบกำกับภาษี (เพราะไม่มั่นใจว่าการกรอกข้อมูลเพื่อสอบถามที่หน้าเว็บไซด์ จะมีเจ้าหน้าที่รับเรื่อง)

- โทรไป Call Center เพื่อสอบถามวิธีการขอใบกำกับภาษี

- ส่งเมลล์ข้อมูลส่วนตัว ชิ่อ ที่อยู่ เลขบัตรประชาชน ไปทางเมลล์ เพื่อออกใบกำกับภาษี

.

.

...แต่...มันไม่เป็นอย่างงั้นครับ

วันที่ผมได้รับหนังสือ เปิดกล่องออกมาพบแต่ใบเสร็จรับเงิน ไม่พบใบกำกับภาษีในกล่อง...ผมถอนหายใจพร้อมกันมีความโมโหเลเวล 3/10 ...เฮ้อ....

ผมดูในใบเสร็จรับเงินครับว่าเบอร์โทรศัพท์ที่ติดต่อได้คืออะไร พร้อมทั้งโทรไปทันที... เสียงระบบอัตโนมัติดังขึ้นและระบบอัตโนมัติได้เล่าเรื่องราว Funtion การทำงานภายในองค์กรว่าจะติดต่อแผนกไหนอะไรยังไง ประมาณ 1 นาที ผมรอฟังจนผมหมายเลขที่ผมต้องการคือ กด 0 เพื่อติดต่อ Operator  หลังจากที่ Operator รับสาย ผมก็ได้บอกเล่าความต้องการและปัญหาที่มันเกิดขึ้น Operator ตอบกลับผมมาว่าต้องโทรไปสาขานะคะ

ผมถาม...สาขาไหนครับ ผมสั่งออนไลน์ สาขาไหนก็ได้ค่ะ ที่นี่สำนักงานใหญ่...ผมก็เลยว่างสายไปพร้อมกับความงุนงง

ผมกลับมาที่โทรศัพท์มือถืออีกครั้ง เพื่อเสิร์ชหาว่ามีสาขาอะไรบ้างๆ ในสมองตอนนั้นคิดวิเคราะห์คือเลือกเบอร์สาขาที่ใหญ่ที่สุด เสียงอัตโนมัติดังขึ้นอีกครั้ง ผมต้องรอระบบอัตโนมัติบอกผมว่ามีหน่วยงานอะไรบ้างภายในบริษัท (รอบนี้ไม่มี กด 0 เพื่อติดต่อ Operator) สมองผมต้องประมวลผลอีกครั้งว่าเรื่องที่เราจะสอบถาม คือเบอร์ภายในอะไร และแผนกอะไรที่ควรจะติดต่อ ผมกด 19 เพื่อติดต่อแผนก Online

เจ้าหน้าที่รับสาย...ผมเล่าเรื่องให้ฟังอีกครั้ง เจ้าหน้าที่ขอเลขที่สั่งซื้อ เจ้าหน้าที่แจ้งกับผมว่า  หน่วยงาน Pack สินค้าน่าจะลืม ให้ผมแจ้งรายละเอียดที่อยู่เพื่อออกใบกำกับภาษีอีกครั้งหนึ่ง กระบวนการนี้ใช้เวลาประมาณ 2-3 นาทีเพราะต้องมีการทวนข้อมูลกลับไปกลับมา เพราะถ้าข้อมูลใบกำกับภาษีผิดจะใช้เวลาแก้ไขอีกเยอะมาก หลังจากนั้นผมก็วางสายไปพร้อมกับรอลุ้นว่าจะได้หรือไม่....

จากที่ผมเล่ามายาวๆ จริงๆแล้ว Website สั่งจองหนังสือควรจะมี Section สำหรับขอใบกำกับภาษีที่หน้าสั่งซื้อได้เลย ในแง่ของการพัฒนาซอฟแวร์ไม่ได้ทำยากเพราะมันก็คล้ายกับ Section ที่อยู่เพื่อส่งสินค้า ซึ่งบางทีทางบริษัทหนังสืออาจจะมิได้มองตรงนี้เป็นส่วนสำคัญ ทางบริษัทอาจจะมองเรื่องการบริหารสต็อคสินค้า Summary Transaction ยอดขายสินค้า

สมมุตินะครับ...สมมุติถ้า แค่เพิ่ม Section ของการขอใบกำกับภาษีที่หน้าเว็บกับ Process การพิมพ์เอกสารใบกำกับของลูกค้าที่ Back Office สิ่งที่บริษัทได้นะครับ

1. Customer Experience จากผมได้เป็นเต็มๆ (ลองมองย้อน Action ที่ผมได้ทำที่ผ่านมา)

2. Reduce Operation Cost : เวลาที่พนักงานใช้รับโทรศัพท์ เช็คอีเมลล์ ค่าส่งไปรษณีย์รอบสอง ค่าซองเอกสาร

จากที่ผมเล่ามาทั้งหมด บางทีเราได้เอาตัวเราไปลองเป็นมุมลูกค้าหรือไม่....

มีเรื่องเล่าที่กล่าวถึงด้าน Customer Centric และประสบความสำเร็จอย่างมาก ซึ่งผมได้ฟังจาก Podcast : The secret sauce ของคุณเคน จาก The Standard

ย้อนกลับไปในสมัยปี 1936 (83 ปีที่แล้ว)

.

.

มีเด็กผู้ชายคนนึง ชื่อออเตก้า เกิดที่คอรุนญา ประเทศสเปน ในสมัยนั้นพึ่งจะผ่านสงครามการเมือง พ่อของออเตก้ามีอาชีพกรรมกรก่อสร้างทางรถไฟ แม่เป็นแม่บ้าน

. 

ออเตก้าในวัย 14 ปี 

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

.

.

เมื่ออายุได้ 16 ปี

เค้าได้ย้ายไปทำงานในโรงงานเย็บผ้า และมีความคิดที่ว่า "ทำไมเสื้อผ้าในท้องตลาด ไม่ตอบสนองความต้องการลูกค้า" และเค้าได้เก็บไอเดียนี้เอาไว้

.

.

เวลาผ่านไป 20 ปี ออเตก้ามีอายุได้ 36 ปี 

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

.

.

เมื่ออายุได้ 39 ปี (1975)

ออเตก้าได้ตัดสินใจเปิดร้านขายเสื้อผ้า โดยตั้งชื่อร้านว่า Zoba แต่ไปซ้ำกับร้านในละแวกนั้น จึงตัดสินใจเปลี่ยนชื่อร้านเป็น "Zara" ซึ่งตำนานของได้ถือกำเนิดนับตั้งแต่วันนั้นเป็นต้นมา

.

.

ปัจจุบัน Zara มี

- ร้านค้า 7,500 ร้าน ใน 96 ประเทศ

- มีพนักงานมากว่า 165,000 คน

- 2017 มีรายได้ 29,400 ล้านดอลล่าล์สหรัฐ เป็นอันดับ 1 ในด้านธุรกิจเสื้อผ้าแฟชั่น (มากกว่ายูนิโคล)

.

.

Key Success ที่ทำให้ Zara ประสบความสำเร็จ มีอยู่ 2 ข้อด้วยกัน

1. มอบในสิ่งที่ลูกค้าต้องการ ไม่ใช่ที่คุณต้องการ (Customer Centric)

2. เร็วที่สุด เพื่อตอบสนองความต้องการของลูกค้า

เรามาดูข้อที่ 1 มอบในสิ่งที่ลูกค้าต้องการ ไม่ใช่ที่คุณต้องการ (Customer Centric) ว่า Zara ทำได้ยังไงกันครับ

.

วิธีการทำงานของ Zara

- ทุกๆวัน Designer จะ Design เสื้อผ้า 3 ชิ้น/วัน 

- นักออกแบบลายผ้าจะเลือกมา 1 แบบ 

- ข้อมูลที่ Designer ออกแบบมาจาก 

1. ผู้จัดการภูมิภาค
2. ผู้จัดการฝ่ายขาย
3. ผู้จัดการร้าน
4. พนักงานร้าน ที่คอยสังเกตลูกค้า
5. นักการตลาด

1 ปี Zara ออกแบบเสื้อผ้า 12,000 แบบ และมากกว่า 450,000,000 ชิ้น/ปี

"ลูกค้าคือผู้ขับเคลื่อนโมเดลธุรกิจ ลูกค้าต้องเป็นศูนย์กลางการออกแบบเสมอ"

.

.

ข้อ 2 ความรวดเร็ว

- Zara เปลี่ยนสต็อคสัปดาห์ละ 2 ครั้ง

- ยอดคนเดินร้าน Zara 17 ครั้ง/ปี (ร้านเสื้อผ้าทั่วไป 3 ครั้ง/ปี) มากกว่า 6 เท่า

- ฐานการผลิตส่วนมากอยู่ที่ Europe (ทั่วไปจะอยู่ที่ จีน เวียดนาม กัมพูชา อินเดีย เนื่องจากค่าแรงที่ถูกกว่า) ต้นทุนการผลิตสูงกว่าแน่นอน แต่สิ่งที่ Zara คิดต้นทุนคือเวลา ทำยังไงจะตอบสนองความต้องการลูกค้าได้รวดเร็ว นั่นคือสิ่งที่ Zara คิด และแน่นอน เมื่อขายได้ไว ไม่ค้างสต็อค Cashflow ที่รวดเร็ว นี่เป็นหัวใจหลักที่ Zara คำนึงถึง

ออเตก้า ในวัย 82 ปี เค้ายังไปทำงาน ประชุมสำคัญเหมือนเดิม ใช้ชีวิตเรียบง่าย ไม่มีห้องทำงานส่วนตัวที่บริษัท ทานกาแฟร้านเดิม ทานข้าวในโรงอาหารกับพนักงานบริษัท

ทิ้งท้ายด้วย Quote คมๆ ของออเตก้า 

"ความพอใจคือหายนะ ความสำเร็จในอดีตไม่เคยการันตีอนาคตได้เลย ผมไม่อนุญาตให้ตัวเองเชยชมความสำเร็จที่ผ่านมา"

Agile Principle ข้อ 1,2,3 บอกว่า

1. Satisfy the customer

2. Welcome Change

3. Deliver frequently

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

Why we need DOR, DOD?

ทำไมเราต้องมี DOR และ DOD

Credit Picture : http://www.ontheagilepath.net/2015/04/the-waste-of-the-definition-of-done-and-definition-of-ready-when-not-actively-used-in-your-daily-work.html

ถ้าเราไม่มี DOR (Definition of Ready) จะเกิดอะไรขึ้น?

1. ความเสี่ยงสูงที่ Product Backlog จะไม่เสร็จใน Sprint เพราะ Product Backlog ไม่มีความพร้อมเนื่องจาก Requirement ไม่ชัดเจน
2. Scope of work (SOW) ของ Product Backlog กว้างเกินกว่าที่จะทำให้สำเร็จใน Sprint3. Scrum Team คิดว่า Product Backlog เสร็จแต่ที่จริงแล้วยังเหลืองานบางส่วนที่หลงลืมและอาจจะส่งผลกระทบ เมื่อต้องการส่งมอบ Product ให้กับลูกค้าตามเวลาที่กำหนด

DOR - Definition of Ready
คือคำนิยาม ความพร้อมของ Product Backlog Item ที่จะสามารถดึงเข้าใน Sprint โดยที่ทาง Scrum Team จะช่วยกันกำหนด Check list คำว่าพร้อมของ Product Backlog และตามหลักการแล้ว DOR จะต้องมีความชัดเจนประมาณ 80% ขึ้นไป ถึงจะลดความเสี่ยงของการดึง Backlog เข้าไปทำใน Sprint

ยกตัวอย่างเช่น
DOR - Team A

• หน้าจอ Design (UX/UI) ผ่านการ Approve เรียบร้อยแล้ว
• System Architecture ผ่านการ Approve และสร้างไว้แล้ว
• Requirement Document มีและคลอบคลุม Product Backlog นั้นๆ

ถ้า Product Backlog ผ่าน Criteria ด้านบน แสดงว่า Product Backlog นั้นพร้อมที่จะดึงเข้าใน Sprint และมีโอกาสสูงที่จะ Develop สำเร็จได้ภายใน Sprint

Credit Picture : http://lcarvalho.pt/2019/01/definition-of-done-vs-definition-of-ready/

ถ้าเราไม่มี DOD (Definition of Done) ปัญหาที่เกิดตามมาคืออะไร?

1. Product Backlog ที่ทำใน Sprint ทิ้ง Undone work ส่งผลกระทบถึงคุณภาพโดยตรงต่อ Product  และทำให้เกิดควมเสี่ยงโดยตรงต่อการส่งมอบ
2. ส่งผลถึงความร่วมมือกันในทำงาน เนื่องจากไม่ได้มองคุณภาพของ Backlog เป็นภาพเดียวกัน ทำให้เกิดเหตุการณ์ที่เรียกว่าหลาย Done เช่น Done Done / Done Done Done ทีมไม่มีเป้าหมายคุณภาพเดียวกัน
3. โดยความเป็นจริงแล้ว Product Backlog ต้องการทำให้เป็น User Story แต่กลับกลายเป็น Task แทน ทำให้เกิด Dependencies ระหว่าง Product Backlog Items

DOD - Definition of Done
คือคำนิยาม ที่จะบ่งบอกว่า Done ของตัว Product Backlog และของทีม ต้องประกอบ Criteria อะไรบ้าง ถึงจะเรียกว่า Done

ยกตัวอย่างเช่น
DOD  ของ Team A

• Front end finished
• Back end finished
• Unit test finished
• Test cases created
• Execute test finished
• Automate test created

Product Backlog Item ถ้าจะ Done ได้ ต้องได้รับการติ๊กถูกจาก Criteria ด้านบนทั้งหมด จะเห็นว่า DOD จะส่งผลถึงคุณภาพของ Product โดยตรง และเป็นหัวใจในการสร้างทีมทางอ้อมเพื่อให้มีเป้าหมายด้านคุณภาพเดียวกัน ทำให้ทีมเกิดความเป็นน้ำหนึ่งใจเดียวกันในการช่วยกันทำงานใน Sprint

Credit Picture : https://www.quora.com/What-is-the-difference-between-the-Definition-of-Done-DoD-and-the-Definition-of-Ready-DoR-in-Agile-processes

สมการ Potentially Shippable Product

Potentially Shippable Product = Definition of Done + Undone Work

Credit : https://innovagility.com/2018/07/17/understanding-undone-work-part-2/

ถ้า Definition of Done ของทีมไม่แข็งแรงพอ จะมี Undone work เกิดขึ้นเสมอ และเมื่อยิ่งเวลาผ่านไปนานขึ้นงาน Undone work ยิ่งพอกพูนมากเรื่อยๆ Undone work คือ ความเสี่ยงที่อาจจะทำให้เราส่งมอบ Product ไม่ได้ตรงตามกำหนด (Unknown risk) ลองคิดสภาพว่าถึงเวลาที่ต้องการส่งมอบแล้วจะมีเหตุการณ์ที่ว่า โอ้ว......ลืม......, อ๋อ........ขาดอันนั้น, ทำไมปัญหามันเยอะจัง

ดังนั้นถ้าเรา Build Scrum Team ขึ้นมาใหม่ ห้ามลืมการกำหนด DOR และ DOD นะครับ

ใช้ 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 ครับ

Sprint Retrospective: Scrum Events ที่ผู้คนส่วนใหญ่ละเลย

หลายท่านอาจสงสัยว่าทำไมผมเปิด Topic แบบนี้ จากประสบการณ์ที่ผมได้เข้าไปทำทีม Scrum ในบทบาท Scrum Master ก็ดี หรือ Agile Coach ก็ดี Scrum Events ที่ผู้คนส่วนใหญ่ละเลยและให้ความสำคัญน้อยที่สุด หรือถ้าต้องเลือก ก็จะยกเลิกเป็นอันดับแรก จากทั้งหมดของ Scrum Events คือ “Sprint Retrospective”

พูดกันง่าย Scrum Events ก็คือ Meeting ที่จะจัดในช่วงระยะเวลา 1 Sprint (1 Sprint = 1-4 Weeks แล้วแต่ความต้องการที่จะ Interact กับลูกค้า หรือ บริบทของธุรกิจในแต่ละประเภท)

Scrum Events ประกอบไปด้วย (4 + 1) ตามรายละเอียดด้านล่าง

1.   Sprint Planning

2.   Product Backlog Refinement (Optional)

3.   Daily Standup

4.   Sprint Review

5.   Sprint Retrospective *

(Credit Picture: https://www.visiontemenos.com/blog/agile-learning-series-scrum)

ณ วันสุดท้ายของ Sprint (Day 10)  ผมจะได้ยินเสียงจากน้องๆ ที่ดูแล Scrum Team ว่า

• พี่ครับ งานใน Sprint ยังไม่เสร็จ ขอยกเลิก Retro ได้ไหม?
• พี่ครับ ผมว่า Sprint นี้จบสวยมาก ปิด User Stories ได้หมด ผมว่าทีมดีอยู่แล้ว เลื่อน Retro ไป Sprint หน้าแล้วกันนะครับ?
• Uhm....วันนี้เราจะทำ Retro สนุกๆ อะไรกันดีนะ Retro การละเล่นไทยดีไหม?
• เพื่อนในทีมมากันไม่ครบ ผมขอยกเลิก Retro นะครับพี่? 

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

ก่อนอื่นให้ตั้งคำถามและมองย้อนกลับไปว่าทำไมเราเลือก Scrum Framework มาใช้ เราต้องการได้อะไรจากการใช้ Scrum? ถ้าคำตอบของเราคือ การทำงานเป็นทีม (Teamwork) เพื่อส่งมอบ Product ที่ตอบสนองความต้องการของลูกค้า เพื่อความพึงพอใจสูงสุดของเรา เอ้ย!!! ของลูกค้า คำตอบอยู่ด้านล่างแล้วล่ะ.........

ความลับของการใช้ Scrum ก็คือ Shortest feedback loop and keep going to continuous เพื่อหาสิ่งที่ทีมต้องปรับปรุง และคาดหวังให้ดียิ่งขึ้น (ที่ใช้คำว่าคาดหวัง หมายความว่า เพราะไม่รู้ว่าสิ่งที่ทีม  Agreed ร่วมกันว่าจะ Improve จะแก้ปัญหาได้หรือไม่) ผมอยากให้ดูรูปด้านล่าง เป็นรูปจากที่ผมได้อ่านหนังสือ Principle ของ Ray Dalio (ฉายา Steve Job ด้านการลงทุน) นี่คือสิ่งสำคัญที่ Ray ได้แชร์วิธีการที่ทำให้เค้าประสบความสำเร็จใน Bridgewater คือทุกครั้งที่ Ray ได้ทำผิดพลาด เค้าจะหาว่าตัวเค้าเองได้เรียนรู้อะไรจากความผิดพลาดนั้นและสาเหตุคืออะไร วงจรที่ Ray ทำไม่ได้เกิดขึ้นเพียงแค่ 1 ครั้ง เค้าทำต่อเนื่องจนกระทั่งถึงปัจจุบัน

(Reference: Principle Book)

Sprint Retrospective ก็เช่นเดียวกันครับ ถ้าเราอยากให้ทีมเริ่มปรับปรุงการทำงานภายในทีมให้ดีขึ้น เราควรจะให้ความสำคัญกับการทำ Retrospective ให้มากที่สุด ผลลัพธ์ที่เราคาดหวังจาก Retrospective คือ Level of improvement  เหมือนในรูปแรกครับ

(Reference: Principle Book)

หลายๆท่านคงรู้จัดแนวคิด PDCA ได้รับการพัฒนาขึ้นเป็นครั้งแรกโดย Walter Shewhart ซึ่งถือเป็นผู้บุกเบิกการใช้สถิติสำหรับวงการอุตสาหกรรม และต่อมาวงจร PDCA ได้เป็นที่รู้จักอย่างแพร่หลาย มากขึ้น เมื่อปรมาจารย์ด้านการบริหารคุณภาพ อย่าง W.Edwards Deming ได้นำมาเผยแพร่ ให้เป็นเครื่องมือสำหรับการปรับปรุงกระบวนการ วงจรนี้จึงมีอีกชื่อหนึ่งว่า “Deming Cycle” ผมจะลองเปรียบเทียบให้เห็นภาพมากขึ้น

Deming Cycle (PDCA)	Scrum
Plan	Sprint Planning
Do	Sprint Backlog
Check/Study	1.     Sprint Retrospective: Team Process 2.     Sprint Review: Product
Act	Improvement on next sprint

ทุกท่านคงเริ่มมองเห็นหัวใจของ Scrum และวิธีการนำมาใช้แล้วใช่ไหมครับ ผมชอบคำคมคำนึงที่ได้มากจาก Podcast (Nopadol Story) ของ ศ.ดร. นภดล ร่มโพธิ์ อาจารย์ชอบพูดเสมอว่า “ไม่มีเวลา….แสดงว่าเราไม่ได้ให้ความสำคัญ” หมายความว่า “ถ้าเราเห็นความสำคัญ เราจะมีเวลาให้กับเรื่องนั้นๆ”  ขอให้ทุกท่านโชคดีกับการ Adopt Agile ไปใช้ครับ

_______________________________________________________

อ้างอิง

Ray Dalio

ในปี 1975 คือจุดเริ่มต้นของ Ray Dalio ที่ได้ก่อตั้ง Bridgewater Associates ภายในอพาร์ตเมนต์สองห้องนอนของเขา ณ เมืองนิวยอร์ก สี่สิบปีให้หลัง Bridgewater ได้เติบโตขึ้นจนกลายเป็นเฮดจ์ฟันด์ที่ใหญ่ที่สุดในโลก และนิตยสาร Fortune ยังจัดอันดับให้เป็นบริษัทเอกชนที่มีความสำคัญที่สุดอันดับห้าในสหรัฐอเมริกา และตัวของ Ray Dalio ยังได้รับการยกย่องจากนิตยสาร Time ว่าเป็นหนึ่งในร้อยคนที่ทรงอิทธิพลที่สุดในโลก