12 הטעויות הנפוצות ביותר בתהליך מעבר למתודולוגיות אג’יליות

מדוע ארגונים נכשלים בתהליך ההטמעה של אג׳ייל? הנה 12 הסיבות הנפוצות לכך

מאת דוד צמח

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

לכן השאלה המתבקשת היא מדוע? מדוע ארגונים נכשלים בתהליך ההטמעה למרות שהידע קיים ונגיש לכולם, מדוע ארגונים נכשלים למרות השימוש בחברות יעוץ, מאמנים, ויועצים אשר מלווים את התהליך ואת הארגון בזמן המעבר?

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

1. שימוש באג’ייל מניפסט כדת

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

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

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

דוגמאות קלאסיות:

  1. מעבר מוחלט של צוותי סקראם תוך התעלמות מהדרג הניהולי (הישיר והעקיף).
  2. התמקדות בצוותים תוך התעלמות מצרכי הלקוח בהיבטים של תקשורת, איכות והובלת התהליך.
  3. הקניית כח רב לתפקיד ה-PO, אשר מנהל את פריורטיזצית העבודה תוך התעלמות מפקטורים ארגוניים.

2. רטרוספקטיב ללא שיפור תמידי

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

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

דוגמאות קלאסיות:

  1. בעיות שלא מטופלות בזמן ילכו ויתעצמו בהמשך.
  2. בעיות שהינן מטופלות יגדילו סיכונים ואת היכולת של הארגון לייצר תהליך שיפור תמידי.
  3. חוסר מענה לבעיות צוותיות ייצר מצב של חוסר אמון מצד הצוות אשר קריטי לכל שיטת פיתוח ועוד יותר בעולם האג’ילי.
  4. חוסר מענה יגרום לכך שאנשים לא יעלו בעיות נוספות בישיבות עתידיות (לא תאמינו כמה הדבר נפוץ..).

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

3. חוסר הכשרה שמוביל לחוסר ידע

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

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

כחלק מאסטרטגיית המעבר של החברה החיצונית, ניתנו הדרכות בסיסיות בלבד בנושאים שונים (יום מרוכז אחד ליותר מ -300 עובדים) אשר התמקד בעיקר במתודולוגיה ובתאוריה אשר לא עזרה כלל לאותם עובדים שבין לילה הפכו להיות מנהלי מוצר (PO), סקראם מאסטרס (SM) ואנשי פיתו ובדיקות שהיו רגילים לעבוד במחלקות נפרדות ולפתע צריכים לעבוד יחדיו כצוות סקראם.

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

4. שימוש באוטומציה להורדת חוב טכני

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

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

כאשר אנו רוצים לבצע שינוי מתודולוגי אפקטיבי, אנו חייבים לבדוק את מוכנות הארגון בנושאי תשתיות האוטומציה על שלל שכבות הבדיקה (Unit, Component, integration and System) השונות, ללא הכנת הארגון ותשתיות אלו, ההטמעה תכנס לקשיים עוד בראשית, והסיבות רבות וכוללות:

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

5. משחקים במשחק ה-“אשמות”

יש לזכור שבאג’ייל המיקוד הוא על “הצוות” ולא על העובד הבודד (צד מאוד חשוב אשר מקבל מענה ברמה הצוותית) לכן, יש חשיבות רבה לכך שכל חברי הצוות יהנו מסביבת עבודה תומכת והרגשת שיכות לצוות שבו הם עובדים (כחלק מגישה בסיסית זו, צוותים אג’ילים יחוו כשלון או הצלחה כיחידה אחת).

הצלחה בכל טרנספורמציה אג’ילית מתחילה מההיבט הבסיסי הזה שבו חברי הצוות ירצו לעבוד ביחד כיחידה אחת שבה יש חלוקה שווה לכשלונות והצלחות כאשר כולם חולקים את נטל העבודה. אימוץ גישה זו בשלבים ההתחלתיים של הטרנספורמציה יהוו גורם מונע למצב קלאסי אחר שבו חברי הצוות משחקים במשחק ה-“אשמות” שבו חברי הצוות מאשימים אחד את השני בכשלונות ולא מאפשרים מצב של למידה ושיפור מתמשך.

6. מסתמכים על “Best Practices”

בשנים האחרונות אני נתקל ביותר ויותר גורמים בתעשיה אשר מדברים על תהליך הטרנספורמציה ה אג’ילית כמשהוא שניתן לבצע מקריאה באינטרנט או לבסס על פי יועצי אג’ייל למינהם שבאים מהבית עם “Best Practices”  שאמנם נראים מצוין בתאוריה אך לרוב לא יעמדו במבחן המציאות.

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

הטיפ הטוב ביותר שאני יכול לתת לכם הקוראים, הוא לא לבסס לעולם תהליך טרנספורמציה מסוג זה תוך התבססות על מדריכים, אג’ייל צ’ק ליסט, וכמובן “Best Practices” למינהם. תהליך הטמעה חייב להיות מותאם לארגון ומצריך עבודה יסודית מצד החברה המייעצת שמובילה אותו, תוכנית העבודה נוצרת רק לאחר מכן ולא לפני.

דוגמה לשאלות אשר נכללות בתהליך ההתאמה לארגון:

  1. מהן מטרות הארגון?
  2. כמות הצוותים והרמה הטכנית?
  3. האם הארגון מוכן לתהליך?
  4. האם אג’ייל הוא הכלי היחידי שמעורב או שיש להשתמש בכלים נוספים?
  5. האם אג’ייל באמת ייתן מענה לצרכים הארגוניים?

7. סביבת עבודה שלא מאפשרת גדילה

העקרון הראשון של המניפסט האג’ילי הוא “Individuals and interactions over process and Tools”” . במהלך טרנספורמציה אג’ילית (והרבה מאוד אחריה) יש לעקרון זה חשיבות רבה ביכולת של הצוות להתגבש ולעבוד כיחידה אחת. בכדי לאפשר לצוותים לאמץ עקרון זה, הארגון חייב לספק להם את סביבת העבודה שתאפשר להם לגדול ולהתפתח כצוות אג’ילי. סביבת העבודה הפיזית חייבת לאפשר עבודה של כל חברי הצוות בכלל אחד (כבר ראיתי מצבים שבהם צוות הסקראם היה מפוזר בקומות שונות או בחללים שונים ולא מדובר בצוותים שונים ומובזרים).

בנוסף לכך, סביבת העבודה חייבת לעמוד בקריטריונים הבאים:

  1. לאפשר לצוות לקיים את כל האירועים השונים אשר מהווים חלק בלתי נפרד מתהליך ההטמעה (Daily Meetings, Planning, Review Etc.).
  2. לאפשר לצוות הרגשת בטחון בזמן שבו חברי הצוות חולקים מידע זה עם זה.
  3. לאפשר לצוות לעבוד ללא הפרעות רקע שיפגעו ביעילותם.
  4. לוחות התקדמות שיאפשרו לצוות לראות את ההתקדמות במהל האיטרציה (אופציונלי אבל תמיד עוזר).

8. מבנה צוותי לא נכון

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

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

  1. חוסר יכולת של הצוות להתמודד עם האתגרים הטכנולוגים, כתוצאה ממחסור בידע טכני מספק.
  2. חוסר הרמוניה בין חברי הצוות שיכול להיות קריטי להצלחת בניית צוות מצליח.
  3. חוסר יכולת של הצוות בהערכת המשימות כתוצאה מחוסר יכולת להבין את מכלול העבודה.
  4. הצוות יחווה תסכול רב בעקבות חוסר היכולת שלו לספק את התוצרים שאליהם הוא התחייב בתחילת האיטרציה.

9. חוסר עקביות בביצוע הישיבות האג’יליות

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

לדוגמה במידה ונבחר בסקראם, נוכל לדבר על 4 סוגי ישיבות:

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

ישיבת תכנון האיטרציה – מאפשרת לצוות לקבל את הידע הדרוש בכדי לקבוע את התתחיבות לאיטרציה הקרובה.

ישיבת ריוויו – מאפשרת לצוות לחלוק את התוצאים של האיטרציה ולקבל פידבק על עבודתם.

ישיבת רטרוספקטיב – מאפשרת לצוות לייצר תהליך שיפור תמידי.

10. חוסר תמיכה מצד הנהלה הבכירה

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

הדוגמאות הקלאסיות:

  1. לחץ מצד ההנהלה שגורם לצוותים לקחת התחיבויות ייתר והבטחה לכשלון מראש.
  2. התעלמות מישיבות עקב חוסר זמן בביצועם (שוב לחץ).
  3. התערבות של הנהלה בכירה בעבודת הצוות בצורה שפוגעת במינדסט האג’ילי.

11. התפקידים האג’ילים כמקצוע ולא כתחביב

ישנם שלושה בעלי תפקידים מרכזיים בכל טרנספורמציה אג’ילת (ובמקרה שלנו סקראם) שכוללים את ה- Product owner, Scrum master and development team, כאשר לכל בעל תפקיד יש את האחריות וסט הפעולות שהוא אמור לעשות בכדי להבטיח שהצוות והתהליך יפעלו בצורה הטובה ביותר.

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

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

12. התעלמות מנושא האיכות

בתור מישהוא שהגיע מעולם האיכות, נושא זה יקר לליבי ולכן ארצה לגרום לכך שיהיה מובן ככל הניתן. אז דברנו על כך מתודולוגיות פיתוך אג’יליות מאפשרות לחתוך  את זמני הפיתוך לתקופות קצרות (בין 1-4 שבועות) מה שכמובן נשמע נפלא לרוב הארגונים אשר שומעים מה זה אג’ייל בפעם הראשונה ואני לא מאשים אותם, על הנייר אג’ייל באמת נשמע מדהים (מה ששווה מאמר נפרד).

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

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

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

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

הכותב הינו מומחה לאבטחת איכות ויועץ בכיר להטמעת Agile.

כתב אורח

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

הגב

3 תגובות על "12 הטעויות הנפוצות ביותר בתהליך מעבר למתודולוגיות אג’יליות"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
יותם
Guest

יש לי רק תיקון קל , רשמת ״תסקול״ במקום ״תסכול״

Abc
Guest

וגם רשמת “בכדי” במקום “כדי” (טעות נפוצה, אבל עדיין טעות)

מיכאל פרי
Member

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

wpDiscuz

תגיות לכתבה: