แนะนำการพัฒนาแบบ Agile หลังจากการลงทะเบียนโครงการแบบดั้งเดิม

ประมาณหนึ่งปีครึ่งที่ผ่านมาฉันเข้าทำงานที่อ้างว่าทำแบบ Agile development สิ่งที่ฉันได้เรียนรู้คือสถานที่แห่งนี้มีการปฏิบัติที่คล่องแคล่วหลายอย่าง (เช่น standups รายวัน plannings plunings และ sprint review) แต่ไม่มีหลักการใด ๆ (ในเวลา / มีความคิดที่ดีพอ

ตอนนี้ฉันได้รับมอบหมายให้ทำให้ทีมมีความคล่องตัวมากขึ้นและฉันมั่นใจว่าฉันมีการบายอินอย่างสมบูรณ์จากทีม dev และทีมธุรกิจ ในฐานะโปรแกรมนำร่องพวกเขาให้โครงการที่เพิ่งรวบรวมความต้องการครบ 15 เดือนมีเอกสารวิเคราะห์และออกแบบหน้า 110 (ถือว่าเป็น "หิน") และที่ฉันไม่สามารถเข้าถึงจุดสิ้นสุดได้ ผู้ใช้ (สำหรับคณะกรรมการที่ประกอบด้วยผู้จัดการของผู้ใช้ที่ไม่ได้ใช้ผลิตภัณฑ์)

ฉันเริ่มเล็กให้พวกเขามีรายการสิ่งของที่คาดหวังสำหรับ 5 sprints แรก (ปล่อย sprints ในอนาคตที่ไม่ได้กำหนด) รายการเป้าหมายของ sprint แรกและฉันก็แยกเอกสาร A & D เพื่อให้เรื่องราวของผู้ใช้เพียงพอที่จะบรรลุเป้าหมายของ sprint แรก .

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

สิ่งนี้ค่อนข้างหยาบสำหรับฉันในฐานะผู้จัดการโครงการใหม่ แต่มีการปรับปรุงที่ฉันได้ดำเนินการอย่างมีประสิทธิภาพเช่น scrumban สำหรับการจัดการเรื่องราวการเขียนโปรแกรมคู่และการมีธุรกิจให้เราทดสอบการยอมรับของลูกค้าล่วงหน้า (เป็นส่วนหนึ่งของเอกสารข้อกำหนด) .

ดังนั้นคำถามของฉันคือ:

1. ฉันจะทำอย่างไรเพื่อแนะนำการเปลี่ยนแปลงที่มีประสิทธิภาพให้กับธุรกิจที่ดื้อรั้นมากขึ้น
2. มีวิธีปฏิบัติอื่น ๆ ที่ฉันสามารถแนะนำทางด้านไอทีเพื่อช่วยให้ธุรกิจได้รับประโยชน์จากความคล่องตัวหรือไม่?
3. ภาระของเอกสารกำลังรัดคอเรา - ธุรกิจยังมองว่าเป็นกลยุทธ์การบริหารความเสี่ยงแทนที่จะเป็นความเสี่ยง เราสามารถทำอะไรเพื่อบรรเทาความกังวลเกี่ยวกับเอกสารและความต้องการของพวกเขา (โดยเฉพาะปริมาณของเอกสารและความต้องการของเอกสารเหล่านั้นทั้งหมด)
4. เราอยู่ในอาคารแยกต่างหากจากธุรกิจของเราห่างออกไปประมาณ 3 ช่วงตึกและพวกเขาปฏิเสธที่จะให้พนักงานของพวกเขาอยู่ในโครงการร่วมกับคนคนนั้น "จะไม่สามารถทำงานในโครงการอื่น ๆ ของพวกเขาได้ในขณะที่พวกเขาอยู่ที่เรา อาคาร." พวกเขาคาดหวังให้เราไปที่นั่นเสมอและรวบรวมคำถามของเราเพื่อที่เราจะสามารถถามพวกเขาทั้งหมดในครั้งเดียวและไม่ต้องเสียเวลาของบุคคลนั้นด้วย "การขัดจังหวะอย่างต่อเนื่อง" เราจะทำอย่างไรเพื่อให้ได้รับการติดต่อสื่อสารที่ดียิ่งขึ้น

คำแนะนำเพิ่มเติมใด ๆ ก็จะได้รับการชื่นชม

ขอบคุณ!

ฉันมั่นใจได้ว่าฉันมีการบายอินอย่างสมบูรณ์จาก devs และทีมธุรกิจ [... ] ฉันไม่สามารถเข้าถึงผู้ใช้ปลายทาง [... ]

สิ่งหนึ่งที่ค่อนข้างชัดเจนคือความแตกต่างระหว่างการมั่นใจด้วยวาจาว่าคุณ "มีบายอิน" ในอีกด้านหนึ่งและอีกนัยหนึ่งความมุ่งมั่นที่แท้จริงจากใครก็ตามที่สนับสนุนงานของคุณ

คำแนะนำที่ดีที่สุดสำหรับฉันคือการตั้งป้ายกำกับ "เปรียว" โดยสิ้นเชิง แบนคำจากการสนทนาตราบเท่าที่เป็นไปได้ ให้มุ่งเน้นสิ่งต่อไปนี้แทน:

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

"การทำให้ทีมมีความคล่องตัวมากขึ้น" ไม่ใช่เป้าหมายที่สามารถดำเนินการได้ มันไม่เจาะจงพอไม่สามารถวัดได้ไม่มีเงื่อนไขสิ้นสุด สิ่งที่คุณต้องการคือสิ่งที่เฉพาะเจาะจง: เป้าหมายที่แสดงในรูปของข้อบกพร่องน้อยลงร้อยละ X หรือร้อยละ Y ของวันที่ส่งมอบคุณลักษณะของคุณที่ได้รับเกียรติจริง ๆ ตามวันที่ Z

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

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

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

พยายามตั้งค่าสิ่งต่าง ๆ เพื่อที่ว่าคุณจะเปลี่ยนความผิดไปได้ยากหากสิ่งต่าง ๆ ไม่ถูกต้อง (และอาจเกิดความผิดพลาดได้) โปรดทราบว่าสิ่งนี้อาจเกิดขึ้นและเตรียมพร้อมหากเกิดขึ้น: ทราบกลยุทธ์การออกของคุณ

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

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

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

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

เกี่ยวกับคำถามที่สองของคุณฉันขอแนะนำให้คุณนำสิ่งหนึ่งครั้ง

ปัญหาเอกสารของคุณควรได้รับการโพสต์ของตัวเองที่นี่ใน P.SE และฉันไม่เห็นปัญหาใด ๆ กับความจริงที่ว่าคุณอยู่ในอาคารที่แตกต่างกันสองแห่งหากทั้งสองยินดีที่จะปฏิบัติตามกฎระเบียบ มีสถานการณ์ที่ด้านใดด้านหนึ่งไม่ต้องการพบเลย)

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

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

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

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

สร้างในเวลา / ทรัพยากร / ค่าใช้จ่ายของเอกสารที่พวกเขาต้องการและให้พวกเขาดูว่ามันผลักดันตารางเวลาออกไปไกลแค่ไหน

นี่อาจช่วยแสดงให้พวกเขาเห็นว่าพวกเขาผลักงานเข้าสู่ทีมโครงการมากน้อยเพียงใดและจะลดลงได้อย่างไรหากพวกเขาไม่ทำเช่นนั้น