Becoming Agile - what you must know before starting the process

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

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

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

ברמת הכללה, הדבר נעוץ לטעמי בשלוש סיבות עיקריות –

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

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

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

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

(כאשר למעשה ההפך הוא הנכון...)

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

The Trigger

מהו טריגר המעבר של הארגון לשיטת אג'ייל ?

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

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

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

חשוב להבין כי הצורך המרכזי עליו עונה שיטת אג'ייל הינו – "היכולת להתמודד עם שינוי מתמיד"

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

היכן זה פוגש את הארגון ?

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

שנית, ביכולת של הארגון "להתאים" את השיטה לצרכיו (בהמשך..)

The Process

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

אציין מספר דוגמאות להמחשת טענה זו –

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

- ניהול סיכונים: האם הארגון מכיר את הסיכונים הכרוכים בהטמעת השיטה? מהן הדרכים להתמודד עם סיכונים אלו? מי מבצע מעקב אחר סיכונים אלו?

- בעלי העניין: מיהם בעלי העניין בפרויקט? האם אלו רק מנהלי הפיתוח? מה לגבי מנהל המוצר? היכן מקומם של ראשי הצוותים בתהליך?

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

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

כל הנושאים לעיל חייבים להיות ברורים לפני שנכנסים לתהליך.

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

The Package

אג'ייל אינו מוצר מדף. (נקודה)

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

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

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

השיטה המומלצת לביצוע שינויים מסוג זה מתבססת על –

- שינויים קטנים בכל פעם

- בקרה ולמידה

- קבלת החלטות

ותיקון שוב במידת הצורך.

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

The Mindset

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

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

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

The Supporting Environment

נושא זה מתחלק לשני תחומים אשר מחויבים להתקיים בהטמעת השיטה -

1. סביבת הנהלה תומכת

2. סביבת כלים תומכת

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

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

The Delivery

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

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

שורת סיכום

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

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

היתרונות בהטמעה מוצלחת של המתודולוגיה הנם עצומים.

הכוונה היא להיכנס לתהליך בעיניים פקוחות, ובכך להעלות את הסיכויים להצלחה.

Picture source - http://www.scalestudy.com/

יוגב טל, PMP

Project Manager & Agile Practitioner

מאמרים נוספים בנושא שיכולים לעניין אותך - 

Agile Anti Patterns 

Who is the agile project manager

Did Agile kill creativity

בחזרה לעמוד הבית - מרעננים את הפיתוח