Photo by rawpixel on Unsplash

ผมรู้จักกับ Agile (อไจล์) เมื่อสิบกว่าปีที่แล้ว ตอนนั้นก็ไม่รู้หรอกว่ามันจะป๊อบขนาดนี้ สมัยนั้นอย่าพูดถึงอไจล์เลย ทีมไหนทำ Unit Testing ก็ถือว่าหรูแล้ว

ฝั่ง UK จะออกเสียงว่า อา-ไจล์, ฝั่ง US จะอ่านออกเสียว่า แอ-ไจล์ ในบทความนี้จะขอใช้ทับศัพท์ว่าอไจล์ซึ่งเป็นที่นิยมใช้กันนะครับ – https://dictionary.cambridge.org/pronunciation/english/agile

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

ผมเชื่อว่าผู้บริหารระดับสูงที่กล้าจะเลือกใช้อไจล์นั้นมีวิสัยทัศน์ที่ดี แต่เวลาปฏิบัติจริง ผมกลับเห็นว่าหลายที่ได้ผลลัพธ์เละเทะมาก สุดท้ายก็มาจบลงที่ว่าอไจล์ไม่ดี หรือไม่เหมาะกับองค์กร (ซึ่งก็อาจจะเป็นไปได้) หรือบางที่ก็เลือกที่จะซุกปัญหาไว้ใต้พรม แล้วทำ KPI ให้ดูสวยๆว่าผลลัพธ์ออกมาดี

สุดท้ายกลายเป็นตราบาปให้กับอไจล์ เป็นแผลเป็นให้กับพนักงานในบริษัท ที่ขยาดทุกครั้งที่ได้ยินคำนี้

ผมเลยอยากเขียนบทความนี้ไว้ให้ผู้บริหาร และหัวหน้าทีมพัฒนา (Technical Lead/ Team Lead) เพราะทัศนคติที่ถูกต้องต่ออไจล์จะส่งผลกระทบต่อการรับอไจล์เข้ามาในองค์กรมาก

บทความนี้จะพูดถึงข้อแนะนำ และตัวอย่างกรณีที่ดี/ไม่ดีแบบต่างๆ ในการนำอไจล์เข้ามาในองค์กร โดยผู้เขียนอนุมานว่าผู้อ่านรู้จักอไจล์และ Scrum แล้ว หากใครที่ยังไม่เข้าใจคำพวกนี้ แนะนำให้อ่านบทความอื่นก่อนครับ

การทำอไจล์คือการปรับวัฒนธรรมองค์กร (Cultural Change) ไม่ใช่แค่การปรับกระบวนการอย่างเดียว (Process)

คำว่าอไจล์ไม่ใช่กระบวนการ (Process) นะครับ มันเป็นหลักการ ถ้าไปดูต้นกำเนิดแล้ว อไจล์มีแค่หลักการสี่ข้อ

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.
จาก http://http://agilemanifesto.org/

จากหลักการสี่ข้อ ก็มีผู้เสนอวิธีการทำอไจล์ในแบบต่างๆ (Methodology) ซึ่งในช่วงแรกๆมีเยอะมาก สุดท้ายที่เหลือรอดอยู่และได้รับความนิยม ก็จะมี Scrum กับ XP

ในบรรดาวิธีต่างๆ Scrum ดูจะได้รับความนิยมในหมู่บริหารมากที่สุด โดยจะมีกิจกรรมหลักคือ Sprint Planning, Standup Meeting, Sprint Review, Retrospective

เท่าที่ผมสังเกต เวลาบริษัทที่ทำอไจล์กัน จริงๆคือทำ Scrum นะครับ ไม่ได้ทำอไจล์เลย ตัวอย่างเช่น

ทีมมายืนทำ Standup Meeting สิบห้านาทีทุกเช้า ต่างคนพูดจบแล้วก็ไป ไม่มีใครตั้งใจฟัง แค่มาเล่า Project Update ให้ Scrum Master ฟังเฉยๆ

ทีมทำ Demo ทุกสองสัปดาห์ แต่ซอฟต์แวร์ทำงานจริงไม่ได้ แค่มาเล่าเฉยๆว่าทำอะไรไปบ้าง

ทีมส่งมอบทุกสองสัปดาห์ แต่ทำตาม Specification ที่เขียนไว้พอ เปลี่ยนไม่ได้ ส่งมอบไม่ตรงโดนปรับ

ทีมทำ Sprint ใช้ Story Point แต่ Deadline กับ Scope โดนวางไว้ตั้งแต่ก่อนเริ่มแพลนนิ่งแล้ว เปลี่ยนไม่ได้

ถ้ามีอาการอย่างนี้ องค์กรไม่ได้ทำอไจล์ครับ เพราะมันไม่มีอะไรที่ตรงกับ Manifesto ของ Agile เลย

องค์กรณ์แค่กำลังทำ Scrum เป็นพิธีกรรมอย่างหนึ่ง

และเมื่อไม่ได้ทำอไจล์ ก็อย่าคาดหวังประโยชน์จากอไจล์ครับ

การทำอไจล์จริงๆคือการปรับวัฒนธรรมของทีม องค์กร และปรับทัศนคติของคน ให้เข้ากับสี่ข้อใน Manifesto ข้างต้น

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

นี่เป็นความยากของการนำอไจล์เข้ามาในองค์กรครับ มันไม่ใช่แค่ทำตาม Scrum Guide แล้วก็จบ

ทุกคนต้องเข้าใจว่าอไจล์ไปเพื่ออะไร

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

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

แต่พอคำสั่งและแนวทางถูกส่งลงไปยังผู้บริหารระดับกลาง-ล่างหรือโปรแกรมเมอร์ กลับกลายเป็นแค่ว่า “หัวหน้าสั่งให้ทำแสตนด์อัพมีตติ้งทุกเช้า” โดยไม่รู้ด้วยซ้ำว่าทำไมต้องทำ

ใครไม่มั่นใจ ลองเดินไปถามคนในทีมดูว่าเรายืนกันสิบห้านาทีทุกเช้าแล้วได้ประโยชน์อะไรบ้าง

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

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

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

วัดผลที่ผลลัพธ์ ไม่ใช่กระบวนการ

หากบริษัทใช้ KPI ผมอยากให้วางตามผลลัพธ์ที่ต้องการทางธุรกิจขององค์กรเป็นหลัก

โดยอาจจะวัดว่าฝ่ายธุรกิจมีความพึงพอใจเพิ่มขึ้นหรือไม่ ส่งมอบโปรดักต์ได้เร็วขึ้นหรือเปล่า

ไม่ใช่ว่าทีมมายืนล้อมวงกัน 15 นาทีตอนเช้าหรือไม่

ครั้งนึงทีมที่ทำเคยต้องกรอกแบบสอบถาม ว่าทำ Agile Practices อะไรบ้าง ทำ TDD กับ Pair Programming รึเปล่า โดยผลของแบบสอบถาม จะถูกนำไปเป็น KPI ให้กับผู้บริหาร

กระบวนการสำคัญ แต่ผลลัพธ์สำคัญกว่า

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

เราทำอไจล์ไม่ได้หากไม่มีความรู้ด้านเทคนิคเพียงพอ

พูดถึงด้านเทคนิค (Technical skill & knowledge) ผมขอแยกเป็นออกเป็นสองเรื่อง คือการวางแผน กับเรื่องคน

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

ทำให้หลายๆครั้ง ผู้บริหารวางแผนปรับเปลี่ยนแค่ด้านการบริหาร แต่ละเลยด้านเทคนิคไป

ทั้งที่จริงๆแล้ว ความรู้ด้านเทคนิคเป็นรากฐานที่สำคัญมากในการทำอไจล์ให้สำเร็จ ในหลักการของ Responding to change

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

ทีมจะต้องฝึกเทคนิคใหม่ๆที่ต่างจากเดิมโดยสิ้นเชิง เช่น Automated Testing, Continuous Integration/Deployment ไม่งั้นมีทางทำซอฟต์แวร์ที่ทำงานได้จริง เอาขึ้นระบบจริงได้ทุกๆสองสัปดาห์หรอกครับ

ดังนั้น เวลาเลือกคอนซัลต์ หรือวางแผนกับคอนซัลต์ในการปรับเปลี่ยนองค์กร อย่าละเลยส่วนนี้นะครับ

โค้ชอไจล์ที่ดีต้องมีความรู้ทางด้านการพัฒนาซอฟต์แวร์และมีประสบการณ์ด้วย ถ้าโค้ชคนเดียวไม่สามารถทำได้ โค้ชก็จะต้องมีทีมที่มีประสบการณ์ปฏิบัติจริงมาช่วยด้วย

เรื่องที่สองคือคนในองค์กร

อยู่ดีๆส่งไปอบรมอไจล์สามวัน จะให้กลับมาทำได้ทุกอย่าง คงเป็นไปไม่ได้ใช่ไหมครับ?

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

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

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

นี่ไม่ใช่ความผิดของคนคนนั้นนะครับ เป็นความผิดของทั้งองค์กรน่ะแหละที่เฉื่อยชา คิดว่าธุรกิจไปได้ดีแล้วไม่ยอมเปลี่ยนแปลงหรือพัฒนาบุคลากรเป็นเวลาสิบๆปี

การปรับเปลี่ยนคนเป็นสิ่งที่ยากที่สุดแล้ว ต้องใช้เวลาครับ

เลือกคอนซัลต์ให้ดี อย่าเชื่อเพราะชื่อเสียงบริษัท

ในองค์กรที่ไม่มีผู้เชี่ยวชาญด้านนี้เลย หรือมีไม่มากพอ การจ้างคนจากภายนอกมาช่วยเป็นเรื่องสำคัญมาก ส่วนใหญ่คอนซัลต์จะเข้ามาคลุกคลีกับทีมในฐานะโค้ช (Agile coach)

คงไม่ต้องอธิบาย ว่าถ้าโค้ชพยายามโค้ชในสิ่งที่ตัวเองยังไม่เข้าใจ หรือไม่มีประสบการณ์พอ ผลลัพธ์จะเป็นอย่างไร

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

คุยๆกันไปนี่ผมโคตรช็อคเลย คือถามทฤษฏีตอบได้ แต่ถามว่าปฏิบัติจริงยังไง ตอบลงลึกไม่ได้เลยเพราะไม่เคยทำมาก่อน

ลองคิดดูนะครับ อไจล์พึ่งมาบูมในช่วงสองสามปีนี้ โตแบบก้าวกระโดด อยู่ดีๆมันจะมีโค้ชที่มีประสบการณ์ในตลาดสักเท่าไร

แต่เมื่อมันมีดีมานด์ มันก็ต้องมีซัพพลาย บริษัทคอนซัลต์ต่างๆก็เนรมิตมาให้ท่านได้

เวลาคุยกับคอนซัลต์ เช็คประวัติคนที่จะมาช่วยทีมด้วย อย่าให้องค์กรกลายเป็นที่ฝึกงานของโค้ช

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

ทีละขั้น อย่าทำรวดเดียว

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

ผมเองก็เป็นมาก่อน สมัยเริ่มทำงานใหม่ๆ ทำอไจล์ปุ๊บ ก็หวังมีผลงานใหญ่ๆเอาไปโชว์หัวหน้าในเร็ววัน

คือ ชอบคิดว่า พอเริ่มทำอไจล์ปุ๊บ จะเห็นผลในเดือนสองเดือน

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

คำแนะนำในหัวข้อนี้คือ ค่อยๆเปลี่ยนทีละนิด ไม่งั้นคนในทีมจะปรับตัวไม่ทัน

แต่ก็ต้องมีเป้าที่ชัดเจนในแต่ละขั้น

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

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

ถ้าจะวัดผล ก็ค่อยๆวัดทีละขั้น เรื่องนี้สำคัญมาก เพราะการจะสร้างโมเมนตัมในการเปลี่ยนแปลงองค์กร มันต้องเริ่มจากความสำเร็จเล็กๆก่อน (Small Win)

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

การเลือกใช้อไจล์เป็นการลงทุนระยะยาวครับ ผลตอบแทนอาจจะต้องรอกันเป็นปี

ไม่ใช่แค่ทีมพัฒนาที่ต้องอไจล์ ส่วนอื่นๆในบริษัทด้วย

เวลานำอไจล์ไปใช้ในองค์กร ส่วนใหญ่จะเริ่มจากทีมพัฒนาก่อน

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

  1. ทีมพัฒนาอยากทำ Continous Integration แต่การขอเซอร์เวอร์มาใช้ ต้องใช้เวลา 3-4 เดือน
  2. ทีมพัฒนาทำ Continuous Deployment แต่เวลาจะเอาขึ้น Production ที จะต้องขออนุมัติจากแผนกต่างๆล่วงหน้า 1 เดือน
  3. ทีมพัฒนามีการจัดทำเดโม แต่ฝั่งธุรกิจ (Business Unit) ไม่มีเวลามานั่งดูเดโมหรือทดลองซอฟต์แวร์ ทีมพัฒนาจึงไม่ได้ Feedback เลย

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

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

คือคนในทีมจะต้องประกอบไปด้วยคนในฝั่งธุรกิจ ทีมพัฒนา (Development) ฝั่งปฏิบัติการ (Operation) คนในทีมไม่มีการแบ่งว่าชั้นอยู่ฝั่งไหน ทั้งทีมมีอยู่เป้าหมายเดียว คือทำให้โปรดักต์ (หรือโปรเจ็ค) ที่ทำอยู่ประสบความสำเร็จในระยะยาว

วิธีนี้ช่วยป้องกันปัญหาเรื่อง Silo ในองค์กรได้ดี เพราะทุกคนที่เกี่ยวข้องกับโปรดักต์ไม่มี Priority ที่ขัดแย้งกัน

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

ผลักจากข้างบน ดันจากข้างล่าง

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

อยากให้ยอมรับอย่างหนึ่งว่า คนแรกที่เห็นผลลัพธ์ของการทำงานคือพนักงานในระดับปฏิบัติการ

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

ผู้บริหารบนๆจะเห็นแค่ภาพรวม และกว่าจะเห็นก็ผ่านไปเป็นเดือนหรือไตรมาสแล้ว

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

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

ซึ่งวิธีที่ทำได้ก็มีหลายแบบ ไม่ว่าจะเป็นการใช้โค้ช การจ้างพนักงานใหม่ที่มีประสบการณ์ การให้รางวัลจูงใจ ฯลฯ

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

องค์กรจะอไจล์ไม่ได้ ถ้าคนที่ปฏิบัติงานไม่อไจล์ครับ

สรุป

อไจล์เป็นสิ่งที่เข้าใจง่าย แต่นำไปปฏิบัติจริงไม่ง่าย

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

หากผู้บริหารต้องการการเปลี่ยนแปลงที่แท้จริง จะต้องพร้อมที่จะเปลี่ยนวิธีคิดและละทิ้งวิธีการทำงานแบบเดิมๆ โดยการเปลี่ยนนี้ไม่ใช่แค่ฝั่งไอทีหรือทีมพัฒนาอย่างเดียว แต่รวมไปถึงฝั่งธุรกิจด้วย