אולי כדאי להתחיל מההתחלה ולהסביר בכלל מה זה - Agile.

ויקיפדיה מגדירה את המושג Agile כגישה בהנדסת תוכנה, היוצאת מנקודת הנחה שפיתוח תוכנה הוא ביסודו בעיה אמפירית, אשר לא ניתן לפתור בשיטות המתבססות על חיזוי או תכנון. באנגלית, המונח Agile פירושו "זריז, קל רגליים, נע במהירות ובחן", ותרגומו לעברית הוא "זמיש" (הלחם, חיבור יחדיו של המילים זריז וגמיש). הגישה קובעת שפיתוח תוכנה הוא פיתוח מוצר חדש ומתייחסת אליו כמשחק של שיתוף פעולה מוכוון־מטרה‏. הגישה הזריזה לפיתוח תוכנה מניחה שלא ניתן להגדיר במלואה תוכנה מסוימת קודם לפיתוחה בפועל, ומתמקדת במקום זאת בשיפור יכולתו של הצוות לספק תוצרים במהירות ולהגיב לדרישות העולות תוך כדי הפיתוח.

אם יורשה לי לספק תובנה אישית ,Agile הוא כלי שפותח על מנת לאפשר למפתחים, אנשים שלא ידועים ביכולות השיווק שלהם (שלא לדבר על ניהול לקוחות), לעבוד מול לקוחות שלא יודעים מה באמת הם רוצים ולכן עולה הצורך להציע להם לבחור בין שתי אופציות. זאת שיטה שפותחה לניהול לקוחות ולאפשר המשך יחסי עבודה תקינים יותר, לעומת שיטה שפותחה במטרה לנהל את הקוד בצורה יעילה.

אז מה זה Scrum? ב- Scrum, תהליך הפיתוח מתחיל שוב מראשיתו מידי חודש. כלומר, פעם בחודש מסופקת תוכנה עובדת למשתמשים, והערותיהם, כמו גם דרישות חדשות, העתידות להיות מיושמות במחזורי הפיתוח הבאים. כך שבפועל, בכל סבב חודשי, מסדרים תקלות ומוסיפים פיצ'רים חדשים למוצר על פי רשימת עדיפויות.

איך הסכנות באות לידי ביטוי בפועל?

לא מנצלים את כוח האדם עד הסוף- בעבודה מהסוג הזה, מחלק המשימות/המתעדף מקבל את החלטות לבד, בדרך כלל כדי להבטיח מצב בו כל היעדים של הסבב הזה מתמלאים. מחלק המשימות, אשר כל האחריות על הגשמת הסבב יושבת על כתפיו וכישלון במשימה הינו כישלונו, מאפשר מרחב "נשימה" לצוות הפיתוח. הרי במשימות פיתוח אף אחד לא באמת יודע מה יכול להשתבש בדרך…

בפועל עלול להיווצר מצב בו הצוות עומד במשימות ללא בעיה, אך חייב להציג את עצמו כעמוס.

המפתחים המנוסים והטובים שלכם יעזבו אתכם- בתהליך מסודר בו הצורך העסקי מוגדר מלמעלה, יורד למעצבים, ומהמעצבים למפתחים, נוצר מצב בו המפתחים הם "פועלים שחורים" המבצעים את רק הפיתוח ובכל חודש ההנחיות לסבב הבא יורדות אליהם כתורה מסיני. זה יוצר מצב שבו אף מפתח מוכשר לא מוכן להיות פועל שחור המהנוהל באמצעות micromanagement ובפועל מרגיש שאינו בעל סמכות לקבל החלטות. במקום זה מפתחים עם ניסיון רב, ומפתחים מוכשרים הרוצים להיות חלק ממשהו, נוטים לעזוב כשהמערכת נשארת עם מפתחים בינונים בלבד.

תהליך עבודה זה מעודד בינוניות- תהליך בו מפתח עובד על פרויקט שכל ההחלטות בו כבר התקבלו ותפקידו מתמצה בביצוע ובעמידה בזמנים בלבד, מכניס את המפתח לעמדת ראש קטן. הרי גם עם לדעתו ההנחיות / המשימות / המוצר אינן נכונות - הוא מרגיששדעתו אינה רלוונטית. במידה ומישהו יקשיב לו ויבצע שינוי באמצע הסבב הנוכחי, שינוי זה יגרור עבודה נוספת שתוביל לשעות עבודה נוספות החודש או, במקרה הגרוע יותר, תמנע עמידה בזמנים. הצעת היעול / שיפור של אותו המפתח תהיה חרב פיפיות שתפגע בו יותר מאשר תועיל לו - הרי בעקבות הצעתו, כל החברה נכשלה בעמידה ביעד. 
 

אפשר להגיד הרבה על מפתחים, אבל הם הלב המניע את החברה והמוצר, כדי להצליח צוות הפיתוח חייב להיות מוכשר ומעורב.

התעסקות אין סופית שאף פעם לא נגמרת בזוטות- עבודה מהסוג של Agile ו - Scrum מחייבת כל הזמן פגישות אין סופיות בין הצוות העסקי למנהלי מוצר, פגישות אשר  צוות ה - R&D וצוות התשתיות אינם חלק מהן ולכן הארכיטקטורה של המערכת אינה מתאימה למוצר. צריך לשנות ולסדר אותה מחדש בכל פעם כדי שתתאים לפיצ'ר חדש או שינוי כזה או אחר במערכת.

אסטרטגיה לטווח קצר בלבד- בשונה מ - lean אסטרטגיה בה אנחנו יודעים מה המוצר הסופי שלנו, וממנה אנחנו גוזרים MVP כדי לראות שאנחנו בכיוון הנכון - אסטרטגית Scrum היא אסטרטגיה בה לא רואים את התמונה הגדולה - היא מחייבת כל הזמן לשנות ולהתאים את המוצר שלך מבלי לראות את הנקודה הסופית. אסטרטגיה זו מתאימה לחברה במשבר המנסה להוציא פתרון מהר ומוכנה לשנות אותו במהירות מבלי לתת לשוק להבין בדיוק במה מדובר. למעשה מדובר בניהול פרויקט אגרסיבי שהגיוני רק באיתות חירום. אנשי פיתוח עסקי ומנהלים לא באמת יכולים להבין בזמן אמת האם הפרויקט מצליח או בגרעון, או האם הפיצ'ר הבא שהם יפתחו הוא שיהווה את ה - tipping point  להצלחה. כשהעובדות מתבררות כבר עלול להיות מאוחר מידי. 

אולי הגיע הזמן שהשימוש הנרחב ב - Agile וה - Scrum יעבור מן העולם, אומנם יש להם את המקום שלהם - כשצוות הפיתוח כולו צעיר ואין לו ניסיון, כשהחברה במצוקה והיא חייבת צעדים דרסטים לבצע שינוי, אבל רעיונות אלו הם רעיונות מסוכנים.

כיום אנשים מאמצים אותם מבלי להבין עד הסוף לטובת איזו מטרה הם נוצרו - לניהול לקוחות ולא לניהול פיתוח, ולאיזה אסון הם יכולים להוביל את הארגון, רק כי מדובר ב – Buzzwords וגורמים להם להישמע מבינים.