Doing Agile Right – Transformation without chaos เป็นหนังสือที่รู้จักจากการอ่าน articles เกี่ยวกับ Agile บน Harvard Business Reviews โดยคณะผู้เขียนประกอบไปด้วยบรรดา consult จาก บริษัท Bain & Company อันได้แก่คุณ Darrell Rigby คุณ Sarah Elk และคุณ Steve Berez โดยทั้งสามมีวัตถุประสงค์ในการเขียนหนังสือนี้ก็เพื่อตั้งใจจะขาย service consult ตัว เอ่อ ตั้งใจที่จะนำ research ที่สำรวจมากกว่าเจ็ดร้อยกลุ่มตัวอย่างเพื่อเอามาแชร์ประสบการณ์ในการเอากระบวนการ Agile ไปใช้ ซึ่งก็แน่นอนว่ามีทั้งพัง และปัง แตกต่างกันออกไป
ทำไมถึงเลือกอ่านเล่มนี้?
คือโดยส่วนตัวเป็นคนที่ยี้กับศัพท์แสง Agile ค่อนข้างมาก แล้วก็คิดว่าคนไทย และหลาย ๆ องค์กรโดน “หลอกขาย” จากคำว่า Agile Methodology ค่อนข้างเยอะ ส่วนตัวเลยอยากเปิดโลกของ Agile เพื่อให้เราเข้าใจว่ามันดีหรือไม่ดีอย่างไร เวลาเอามาใช้จะได้เข้าใจ และไม่เสียรู้ consult นั่นเอง โดยเฉพาะ foundation ของมันก่อนที่จะเอามายำผสมกับเรื่องอื่น ๆ เช่น Agile HR??? (มันทำได้เหรอ หรือถ้ามันทำได้ มันมีประโยชน์อะไร เป็นต้น)
สรุปเนื้อหา
- ไม่ควร copy and paste กับใด ๆ ก็แล้วแต่ที่เกี่ยวกับ Agile เพราะว่าคนจาก Spotify ย้ำเสมอว่าอย่าได้ริอ่าน copy ไปเด็ดขาดเพราะสำหรับพวกคนที่ Spotify ก็ยังคิดว่ากระบวนการ transformation นี้ยังไม่เสร็จ
- อย่าเริ่มต้นด้วย toxic Agile เช่น เอะอะก็เอาคำว่า Agile ไปเติมกับหน่วยงานต่าง ๆ เช่น Agile marketing บลา ๆ หรือหวังว่า Agile มันจะใช่ได้กับทุกคนทั้งองค์กร เพราะสุดท้ายมันก็จะกลายเป็น toxic ใหม่ เป็น silo ใหม่ ไม่ได้ช่วยให้เกิดอะไรดี ๆ ขึ้นมาเลย
- Leader เป็นเรื่องสำคัญ (มีใครเคยบอกว่ามันไม่สำคัญบ้างมั้ย) จะทำ Agile ควรจะเริ่มที่หัว ๆ ก่อนเลย (เอาให้เคลียร์ด้วยนะ)
- หากจะนำเอา Agile ไปใช้ มันไม่ใช่แค่หยิบไปใช้ได้เลยนะ มันต้องทำการ plan ทำการเตรียมการ รวมถึงเรื่องหลังบ้านอื่น ๆ อีกมากมาย
- สุดท้ายหนังสือก็จะเน้นให้เรา “เริ่มต้นทำ Agile ให้ถูกตั้งแต่แรก”
สิ่งที่ชอบ
- รู้สึกว่ามันไม่ได้ยัดเยียด Agile มากเกินไป คือไม่ได้มาพร่ำสอนวิธีการเช่น kanban, scrum บลา ๆ แต่เน้นไปที่การเล่าประสบการณ์ของการนำไปใช้แล้วมันพังพินาศมากกว่า
- หนังสือเล่มนี้เป็น research based กล่าวคือ มีการยกตัวอย่างที่เป็นรูปธรรม และมีผลงานวิจัย และศึกษามาค่อนข้างเป็นระบบ
- ไม่ได้อวย Agile ราวกับมันเป็นยารักษาโรค แล้วก็ไม่ได้บอกว่าระบบการบริหารงานแบบปัจจุบันมันเลวระยำขนาดที่แบบถ้ามึงไม่เปลี่ยนคือมึงตาย มันไม่ได้เว่อร์ขนาดนั้น อ่านแล้วไหลลื่นไปได้เรื่อย ๆ ไม่ได้รู้สึกขยะแขยงจนอยากอ้วก jargon ประหลาด ๆ ออกมา
- มีการยกตัวอย่างองค์กรที่นำเอา Agile ไปใช้จริง และก็บอกข้อควรระวังเสมอว่าถ้าจะเอาไปใช้ มีอะไรบ้างที่เป็นจุดที่ต้องคอยระวังเอาไว้
- ชอบที่บอกว่ามีเสาหลัก 5 ต้นที่ค้ำยันการทำ Agile เอาไว้คือ strategy, organization, leadership, process – methods และ culture
- ชอบการที่บอกว่า HR อ่ะพวกมึงอ่ะ ถ้าองค์กรเรา hype เรื่อง Agile ก็จงไปหาความรู้มาใส่ตัวกันด้วย ไม่งั้นจะไม่เข้าใจเชี่ยอะไรเลย
- พอและไม่อยากเขียนเยอะเดี๋ยวจะกลายเป็นอวย (จริง ๆ ก็แอบให้คะแนน 4/5 อ่ะนะ)
สิ่งที่ไม่ชอบ
- มันยิงเนื้อหายาวววววววววววววววววววววววววววววววววมากเกินไป อ่านแล้วแบบง่วงมาก คือเล่าวนไปวนมา เดี๋ยวก็กลับมาประโยคเดิม เรื่องเดิมๆ
- งานวิจัยท้ายบทมันอ่านยากกกกกกกกกกกกกกกกกกกกมาก ต้องแบบปริ้นท์มานั่งอ่านบนกระดาษ A3 ใหญ่ ๆ อ่ะถึงจะเข้าใจมันทั้งหมด มันควรจะทุ่มเทการ visualize ให้มันอ่านง่ายกว่านี้หน่อย แต่เข้าใจว่าขี้เกียจแหละ หรือไม่งั้นก็ถ้าได้เป็นลูกค้าเค้าอาจจะทำให้ก็ได้
รวม High-Light ที่ชอบ (บางส่วน)
and in fact the bigger impact may have been on ways of working.
In effect, the internal market system discouraged teamwork, with predictable effects on productivity. “It took just 600 Apple engineers less than two years to develop, debug, and deploy OS X, a revolutionary change in the company’s operating system. By contrast, it took as many as 10,000 engineers more than five years to develop, debug, deploy, and eventually retract Microsoft’s Windows Vista.”
What we fear is loss.
Remember, too, that agile is a tool, not a strategy.
We likewise believe that doing agile right means choosing where not to use it.
If you tell people to innovate without making mistakes, you will kill innovation. But if you tell people to innovate and not worry about mistakes that are quickly reversible, you free them to test and learn in more agile ways. Jeff talks about two-way doors, where you can always come back if you don’t like what you see on the other side. Service-oriented architectures enabled thousands of two-way doors.
Working backward from the customer forces you to think about every activity as a service to the customer.
The teams are self-governing because autonomy increases motivation
At the beginning of an agile journey, the hardest truth for many executives to accept is that where to go and how to get there are not just unknown, they are unknowable.