כדי
לבצע שינוי בחיים, עלינו קודם כל להבין מה מצבנו האמיתי, מה יהיה המצב
המקווה בסוף התהליך, והבנה שהתהליך עצמו יזעזע את שטח הנינוחות שלנו
(Comfort Zone). הדבר נכון גם במעבר לשיטת ניהול פרויקטים חדשה, ולשיטה
האג'ילית בפרט, בה יש דגש חזק על המימד האנושי (להבדיל, למשל, ממעבר לכלי
CRM חדש).
האנשים והחברה (ובייחוד ההנהלה) צריכים קודם להבין מה המצב האמיתי של
הארגון, ללא ה-"שקרים הלבנים" שנפוצים בארגון, לבדוק כמה פעמים הארגון
עומד בהבטחותיו ללוחות הזמנים, כמה זמן מוקצה להשקעה בעובדים, כמה זמן
"מושקע" בישיבות ועוד. לאחר מכן, צריך להבין האם המצב סביר או דורש שינוי,
כי זהו הדלק שייתן לארגון כוח בהמשך. לאחר מכן, על הארגון לבחון איזו שיטה
עדיפה על ידי בדיקה האם השיטה החדשה תיתן מענה אמיתי לבעיות הקריטיות
שנמצאו.
הדבר החשוב ביותר, הוא להבין שבשעת המעבר הארגון סופג זעזוע בשיטת
הניהול שלו ועליו לרכוש מיומנויות חדשות בכל מיני תחומים. הדוגמה החביבה
עלי היא ילד חדש במשפחה. על כל המשפחה להבין את המציאות החדשה ולפתח את
המיומנויות החדשות הנגזרות מהמצב החדש (הלבשה בבוקר, שכן שעת התחלת בית
הספר לאחות הגדולה לא השתנתה, מקלחות וארוחת ערב בלילה, פניות לכלל
הילדים, שכן שיעורי הבית ממשיכים להגיע ואפילו מתגברים וכו').
במעבר לסקראם, שבו הדגש הוא על עבודת הצוות וגיבושו לצוות מיומן ומגובש
מוכוון משימות (יחידת עילית), הצוות חווה קושי רב בתחילה וללא שום דיבידנד
מיידי. זהו הזמן שבו צריך לשלוף את הרשימה שתיארה את המצב הקודם ואת
הרשימה של המצב המקווה של סוף התהליך ולהיעזר בסבלנות ובמשמעת (הדיבידנדים
בדרך!).
מכיוון שכל שינוי מייצר את הנוגדן הטבעי האנושי: פחד, אנשים נוטים
לעטוף אותו בכל מיני תירוצים שונים ומשונים שמתארים מדוע ההטמעה נידונה
מראש לכישלון. קצרה יריעה מלהכיל את כל הרשימה, אז הנה אוסף התירוצים
הנפוצים ביותר שאנחנו שומעים:
- "בתיאוריה זה נהדר אבל פרקטית זה
לא עובד". בתרגום: "המצב כל כך סבוך בארגון שאין לי מושג מאיפה להתחיל את
התהליך שנראה לי שמאוד יעזור לארגון". בכל ההטמעות שאני הייתי חשוף אליהן,
אם זה בארץ או בעולם, אם שאני השתתפתי או שתוקשר לי על ידי מדריכים
מוסמכים (של האיגוד הבינלאומי) אחרים, הארגון התייעל באופן משמעותי.
- "אצל אחרים זה בטוח יעבוד אבל אצלנו זה לא יעבוד". בדומה לראשון,
קיימת הבנה שהשיטה יעילה ואפילו עובדת פרקטית, אבל הכרת האנשים
והמתודולוגיות המיושמות בארגון ימנעו מכך לקרות כי אין לארגון היכולת
להשתנות אפילו בשם היעילות.
- "אצלנו הצוותים מבוזרים, לכן זה לא
יעבוד". קיימת נטייה לחשוב שאם נבצע מיקור חוץ למדינה בה המשכורות נמוכות
משמעותית, נוכל לחסוך הרבה כסף. אמת הדבר שעיקר ההוצאות בענף ההיי-טק הוא
משכורות העובדים אולם בדרך כלל נוטים לשכוח את הבדלי התרבות, הזמן
והתקשורת הקלוקלת. לפעמים מקצינים את הדבר על ידי הוצאת תת צוות (QA,
למשל) מעבר לים וציפייה שהצוות כולו יתפקד בצורה יעילה. לסקראם אין
פתרונות קסם והדבר יוקצן ביתר שאת לכל אלה שממענים לראות זאת אבל המטמיע
(בייחוד אם הוא מדריך סקראם מוסמך מטעם האיגוד הבינלאומי שמביא איתו את
הניסיון והידע של האיגוד) ידע לתת כלים למענה מיידי ויעיל כמו גם ארוך
טווח לשיפור המצב.
- "אין סיכוי בעולם שנצליח להוציא גרסה כל 3
שבועות" – לפעמים הארגון חולה בתסמונת הסטודנט ("דחה את הבעיה בתקווה שהיא
תיעלם"). זה מתבטא בהרבה מאוד דברים, בין השאר בחוסר יכולת לקמפל את כל
הפרויקט. כשאני שואל לפשר הדבר, אני מקבל תשובות הזויות ותמוהות, כמו
"אנחנו לא יכולים לקמפל כרגע, לקמפל לוקח שבועיים וחבל על הזמן" וכד'.
בסקראם אנחנו מקמפלים את כל הפרוייקט כל יום (ואפילו עם כל שינוי קוד
מאושר). נכון, בתחילה זה לוקח זמן, אבל מהר מאוד מגיעים למצב הזה ואז
קורים דברים נפלאים. אם קיימת בעיה, היא מיד (עד יום) מתגלה. דומה הדבר
לעבודת תחזוק בית. אם לא תתחזק אותו בצורה קבועה, כשיגיעו אורחים תצטרף
לעבוד שעות. ראיתי פרויקטים מסובכים מאוד ומורכבים מאוד. כולם לבסוף הגיעו
למצב שהם מתקמפלים תוך לילה (ולפעמים זה לא פשוט!) ואז הם לא הבינו איך הם
עבדו לפני זה.
- "10% מההטמעות נכשלות – למה להתחיל אם יש סיכוי להיכשל?". הפחד מכישלון הוא לפעמים המגן הכי טוב...
-
"אנחנו חברה של מאות אנשים ולכן אג'ייל לא יוכל להתאים לנו". אחת הטעויות
הנפוצות היא שסקראם מתאים רק לחברות קטנות או לצוותים קטנים. כמובן שהדבר
לא נכון. סקראם מתאים לחברות גדולות כקטנות, אפילו בארץ יש חברות גדולות
של מאות אנשים שעוברות לסקראם. ראיתי כבר חברות גדולות שעברו הטמעה מוצלחת
וחברות קטנות שההטמעה נכשלה. סקראם אינו תלוי בגודל החברה אלא במחויבות
ההנהלה לשינוי.
- "אנחנו עובדים בפרויקטים קבועי תכולה (Fixed
Price Project) ולכן אג'ייל לא יעבוד". אם זה היה נכון, היה לוקח לסקראם
חצי שנה להיעלם. סקראם מתאים לסוגי פרויקטים מגוונים כמו גם לפרויקטים
קבועי תכולה. ההבדל הוא שבסקראם ניתן לדעת כמעט מיד האם צריך להוסיף זמן
ו/או אנשים ולא צריך לחכות כמעט לסוף הגרסה כדי להפתיע את הלקוח בחוסר
המוכנות של החברה בזמן המוסכם. אחת הבעיות השכיחות בעולם הפיתוח הוא
שמנהלים משחקים בלהיות אלוהים והם חושבים שהם יכולים לקבוע הם את התכולה,
הן את הזמן ואת את כמות האנשים שצריך. המציאות טופחת על פניהם פעם אחר פעם
שכן אי אפשר לקבוע את שלושת הדברים הנ"ל אלא רק שניים מהם בכל זמן נתון,
כשהשלישי נגזר. כמו כן פיתוח תוכנה הינו שילוב של יצירתיות ותקשורת ולכן
יש להתמודד איתו בהתאם כאשר נדרשים למתן לוחות זמנים. בעזרת סקראם ניתן
לרכוש את המיומנות הזו אבל אי אפשר לעשות קסמים. אם צוות של שלושה אנשים
יכול לשתות 100 כוסות מים ב-20 דקות, לא יעזור המנהל המוכשר ביותר שיבוא
ויגיד שאותו צוות צריך לשתות 100 כוסות ב-5 דקות רק בגלל שהובטח הדבר
ללקוח.
ונסיים באוסף התירוצים שמצחיקים אותי יותר מהמכל שכן לא רק שהם אינם
קשורים לסקראם, אלא הפתרון נראה מובן מאליו אבל אף אחד לא מטפל בהם והם
בבחינת גזרה משמיים. הנה הדוגמאות המובילות. למעט השמטת פרטים מזהים כמו
שם החברה, הציטוטים מדוייקים:
- "אצלנו המסמכים היו ותמיד יהיו מסובכים, מורכבים ובלתי ברורים שאין סיכוי להטמיע אג'ייל".
- "למנהל המוצר אסור לדבר ישירות מול הצוותים כי הם לא אנשים שלו ופעם אחרונה שזה קרה, היה בירור עם סמנכ"ל הפיתוח".
-
"אני חייב לשקר למנהל המוצר לגבי לוחות הזמנים. הוא יודע את זה והוא מקצץ
את ההערכות שאני נותן לו. אתה מציע להגיד לו את האמת וזה לא ילך".
- "אין לנו אפשרות לתעדף את פרטי הגרסה - אצלנו הכול חשוב".
- "ברור לי שהאנשים לא יספיקו את כל התכולה אבל אני חייב לשקר להם אחרת הם לא יספיקו אפילו חצי ממה שאנחנו רוצים".
- "לעולם לא נוכל להוציא גרסה כל שלושה שבועות כי רק על ישיבות אנחנו מבזבזים יומיים כל שבוע".
- "ההטמעה תיכשל כי להנהלה לא איכפת איך אנחנו עובדים העיקר שנעמוד בלוחות הזמנים והתכולה (הבלתי הגיוניים) שהם התחייבו בשמנו".
- "אצלנו המנהלים צריכים לדעת כל דבר קטן לכן לעבוד באג'ייל שהאחריות ניתנת לצוות לא תעבוד כשיטה".
- "נוח לי עם זה שלא כל אחד יודע מה אני עושה, עכשיו אתה מציע שכולם ידעו על מה אני עובד ומה קצב ההתקדמות שלי?".
-
"לעבוד באג'ייל זה לעבוד בצוות ואין טעם לעבוד אצלנו בצוותים כי כל אחד
בצוות יודע דבר אחר ואף אחד לא יכול להחליף אותו או לעזור לו וככה זה
ישאר".
והדוגמה ההזויה ביותר:
- "אנחנו אמנם לא עומדים בלוחות הזמנים, באיכות ובתכולה אבל לאף אחד לא
איכפת אז פשוט אין לנו טעם לעבור לאג'ייל או לכל שיטה חדשה אחרת".