שבע טעויות נפוצות ביישום AGILE

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

  1. לחשוב בגישה של ONE FITS ALL – כמו בכל שיטה, צריך להתאימה לצרכי הלקוחות, לתרבות הארגונית לארכיטקטורת המוצר, לגודל הגרסאות ועוד. ארגונים שאינם משקיעים חשיבה בכל  אחד מהאלמנטיים ובוחנים את מידת התאמתו, עשויים למצוא את עצמם משקיעים אנרגיה רבה ביישום אלמנטיים שבמקרה הטוב, אינם תורמים דבר. לדוגמא, ההחלטה על גודל הספרינט, נגזרת מיכולת הבדיקה שלך, מיכולת הלקוחות שלך לייצר משוב, מהתלות שלך בפיתוח חומרה ועוד. החלטה על גודל ספרינט קטן מדי, יוצרת לחץ מיותר וחסר ערך.
  2. לא לתכנן את ה SCALING AGILE – האג'ייל לא מתחיל ונגמר ברמת הצוות. צריך לחשוב מראש איך ינוהל פורטפוליו הפרויקטים, איך נעבוד עם פרויקטים שדורשים מספר צוותים, איך נקצה מומחים, איך נבצע בקרת רוחב ועוד. יש היום למעלה מחמש שיטות שונות לנהל SCALING AGILE וכל אחת מהן מותאמת לסוג אחר של צרכים ואינה נותנת מענה לצרכים אחרים. בסופו של דבר ה SCALING הוא שקובע בראיית ההנהלה את הצלחת הפיתוח.
  3. לא להשתמש בכלי תומך – במניפסטו האג'ילי כתוב שיותר חשוב התקשורת בין האנשים מאשר כלים, אך בלי כלי קשה מאד לשלוט ברמת ה SCALING. קשה גם לנתח נתונים ולזהות בעיות רוחב. החדשות הטובות שיש כלים טובים. JIRA היא הכלי המוביל היום, אבל יש גם אחרים.
  4. לוותר על ה PMO – פונקציית ה PMO אחראית על שלושה נושאים – הטמעת הכלים והתהליכים, בקרת רוחבי על התקדמות פיתוח המוצרים והעומסים על צווארי הבקבוק ועל התכנון הרוחבי לטווח הארוך. אלה תפקידים חשובים, שמי שמוותר עליהם, מגלה שקשה לו מאד להבין מה קורה בארגון שלו ולתת מענה לדרישות ההנהלה לייצר מפת דרכים ריאלית לפחות שנה קדימה.
  5. להתמקד ב SPRINT ולא במוצר – החשיבה האג'ילית מתמקדת בטווח הקצר, אך פעמים רבות, ערך משמעותי מושג רק אחרי מספר חודשים (לדוגמא, אם לוקח לפתח מעגל מודפס שלושה חודשים, עד שהלקוח יראה ערך משמעותי, ייקח חצי שנה). חשוב להרים את הראש מדי פעם ולראות איפה אנו עומדים בראיה הכוללת. ה PRODUCT OWNER אמור לעשות זאת בראיה השיווקית, אך לרוב זה לא מספיק וצריך לפתח מנגנון כמו ה MSM (Managerial Status Meeting) שיכריח את המנהלים להרים את הראש מהשוטף ולראות את התפתחות המוצר.
  6. לסבך במקום לפשט – השיטות האג'יליות נועדו לפשט את התהליכים ולאפשר לאנשי הפיתוח להשקיע יותר זמן בפיתוח עצמו. אם יצרתם תהליכים או מבנה ארגוני צוותי שמסבך את תהליכי התקשורת והפיתוח, כנראה שטעיתם.
  7. לא לנהל את השינוי – צריך לנהל את השינוי. אחרת תגלו שחלק מהאנשים עובדים בצורה אליה התרגלו ולא בצורה הנכונה מהבחינה הארגונית . יש מספר שיטות לניהול השינוי שהמבוילה בהם היא שיטת שמונת השלבים של קוטר, אך גם כאן, צריך לבצע התאמות.

בהצלחה.

מודעות פרסומת