דפים

יום ראשון, 10 בנובמבר 2013

Efficient retrospective process

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

ראשית – מספר מילים לאלו שהמושג חדש להם:
ישיבת ה retrospective הינה ישיבה בה מתכנס צוות האג'ייל ומבצע תהליך הפקת לקחים על הספרינט האחרון. המתודולוגיה ממליצה לבצע זאת ע"י שאלת שלוש שאלות בסיסיות –
1. מהם הדברים אשר בוצעו בצורה לא תקינה ועלינו להפסיק לעשות אותם ?
2. מהם הדברים אשר לא בוצעו ויש לבצעם בהמשך ?
3. מהם הדברים שבוצעו בצורה תקינה ויש להמשיך ולבצעם ?

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

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

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

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

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

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


בהצלחה !

*אם יש לכם תהיות והתלבטויות הקשורות לייעוץ והכוונה בנושא –
צרו קשר – yogev05.t@gmail.com



יוגב טל, PMP


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

אין תגובות:

הוסף רשומת תגובה