אחד היתרונות (ויש גם
כאלו שיכנו זאת חיסרון) של מתודולוגיית אג'ייל הינה בהתאמה הנדרשת בהטמעת המתודולוגיה.
הצלחת הטמעת אג'ייל בארגון תלויה במספר רב של גורמים - החל מבשלות ההנהלה לקבלת
השינוי, דרך השתרשות המתודולוגיה הנוכחית בארגון, וכלה ברמת ההטמעה הנדרשת (הרחבה
ניתן למצוא כאן).
אך בהנחה ששלב ההטמעה
עבר בהצלחה, האתגר האמיתי היה ונשאר היכולת לשמר את השיטה, או במילים אחרות היכולת
של צוות הסקראם להמשיך ולהיות פרודוקטיבי ברמה הנדרשת לארגון לאורך זמן.
המשך
המאמר יתמקד במנועים העיקריים אשר יתרמו למטרה זו, והפעם מנקודת מבטו של צוות
הסקראם.
האם אי
פעם עצרתם ושאלתם את הצוות אם הוא שבע רצון?
איני מתכוון לפגישות Retrospective כי אם לשאלה ברמה הבינאישית
מנוע #1 – שביעות רצון
בבסיס של כל צוות Scrum נמצאת האינרציה הפנימית של הצוות, היא זו אשר דוחפת אותו
"להתחייב" כלפי עצמו, היא זו שדוחפת אותו לבצע את המשימות שלו ברמה
מספקת כלפי הצוות, והיא זו שגורמת לו לחתור לעמידה ביעדים שהוא בעצמו הציב.
האם אי פעם עצרתם
ושאלתם את הצוות אם הוא שבע רצון? איני מתכוון לפגישות Retrospective כי אם לשאלה ברמה הבינאישית. צוות הסקראם הוא זה שנמצא במרכז
הזירה, הוא המנוע העיקרי להצלחה או כישלון של תכנית המוצר, ועליו מופעל לחץ
מכיוונים שונים
החל מראשי הצוותים ברמה
המקצועית, דרך Scrum
Masters ברמה
המטריציונית, מנהלי פרויקטים, מנהלי מוצר, VP R&D, וכו'
הקשר בין שביעות רצון
העובדים לבית תוצר הפעילות שלהם כבר נבדק והוכח באינספור מחקרים.
מונח המתאר בתמציתיות
את הקשר בין שביעות רצון אנשי הצוות לרווחיות נקראת PPP:
People-Product-Profit – הדבר החשוב
ביותר שיש לדאוג לו הם אנשי הצוות, אם שביעות הרצון שלהם תהיה גבוהה, רמת התוצר
שלהם תהיה גבוהה. רמת תוצר גבוהה תוביל לרמת גבוהה של המוצר הסופי, אשר יוביל
בסופו של דבר לרמת רווחים גבוהה לארגון.
לטעמי טכסי האג'ייל
אינם חסינים, וגם הם ברי שינוי.
זאת בתנאי שהשינויים
מתבצעים מתוך החלטה ולא מתוך הזנחה.
מנוע #2 – התאמה לשינוי
בהטמעה נכונה של אג'ייל, יכולת ההתאמה לשינוי הינה רחבה, הרבה מעבר
ליכולת לשנות תכולות בלבד במהלך הגרסה.
בהטמעה נכונה ההתאמה לשינוי נבחנת שוב ושוב ברמת תהליכים, ברמת
החלטות, ברמת יישום לקחים (ראו הרחבה בנושא במאמר נפרד Agile Mindset)
ברור לי כי אני מהלך
כאן על עצבים חשופים של לא מעט אנשים העוסקים בתחום, אך בכל זאת –
כפי שציינתי בעבר, Scrum היא מסגרת בה מוגדרים הטכסים האג'יליים אשר הופכים אותה
לאפקטיבית. על פי טכסים אלו מתנהלת השגרה של אנשי הצוות, החל מפגישות יומיות(Daily), דרך פגישות הפקת
לקחים(Retrospective), וכלה בפגישות הצגה(Review)
האם טכסים אלו חסינים
בפני צורך ההתאמה לשינוי?
לטעמי טכסי האג'ייל
אינם חסינים, וגם הם ברי שינוי. זאת בתנאי שהשינויים מתבצעים מתוך החלטה ולא מתוך
הזנחה.
אתן מספר דוגמאות
להמחיש את הטענה –
פגישות Retrospective חשובות ונחוצות לכל הדעות. אך מהי התדירות בה יש לבצע פגישות
אלו?
סקראם מציע שהתדירות
תהיה בסיום כל ספרינט. נשמע הגיוני מאד. אך מה אם אורך הספרינט הינו שבוע?
מה אם הספרינטים
הראשונים של הגרסה מיועדים לפיתוח הכרחי של תשתיות?
האם לעשות פגישות Retrospective כל שני ספרינטים זה בהכרח דבר שאינו נכון?
דוגמא נוספת -על פי
סקראם, יש לבצע פגישות יומיות בעמידה (Daily Standup)
הסיבה לכך, מעבר
לקונוטציה של פגישה קצרה הינו שימוש בחוסר הנוחות שבעמידה אשר יגרום לכך שהפגישה
תתקצר.
האם דבר זה הינו מחויב?
מה אם הצוות מעדיף לשבת ועדיין כל פגישה מסתיימת בתוך מספר דקות?
האם דבר זה בהכרח שגוי?
אני טוען שאם הצוות
מבין את מהות הטכס, התנסה בו, ומעריך שיקבל ערך מוסף דומה גם לאחר השינוי הרי שאין
כל מניעה לבצע את השינוי. יש לזכור שככל שינוי, גם הוא
צריך להיבחן שוב בממד הזמן.
הגישה הכוללת בפגישת ה Review צריכה להשתנות.
במקום הסתכלות על חצי
הכוס הריקה וניצול ההזדמנות לבקר את הקיים, יש להסתכל על חצי הכוס המלאה ולנצל את
ההזדמנות להחמיא על ההתקדמות.
מנוע #3 – התמודדות עם
ביקורת
מנגנון הביקורת ב Agile הוא מחויב ומובנה בתוך התהליך. הסיבה לכך הינה שככל שהצוות
יקבל פידבק מוקדם יותר על התוצר, כך נוכל
להתמודד מוקדם יותר עם השינוי הנדרש, מה שיבטיח פגיעה מדויקת יותר במטרה הסופית. (חישבו על טיל מונחה, אשר בכל פעם מקבל כיול קטן לאורך הדרך, עד
הפגיעה במטרה)
צוות הסקראם נאלץ
להתמודד עם ביקורת מובנת לכל אורך הספרינט, מעמיתיו (בדיקות על פיתוח ולהיפך),
מראשי צוותים המקצועיים, מה product owner, אך נקודת השיא הינה פגישת ה Review.
בפגישה זו על הצוות
להציג בפני בעלי העניין את הישגיו בספרינט הנוכחי.
גישה זו אשר אמורה
להיות שיא ההתלהבות של הצוות, לעיתים מקבלת גוון הפוך לחלוטין.
טכס ה Review מושך אליו הרבה בעלי עניין, מרביתם יהיו מעוניינים להביע את
דעתם, להציע הצעות לשינוי, ואף להגדיר מחדש תכולה זו או אחרת
בעקבות הראייה המוקדמת של כיוון התוצר הקיים.
נתחיל ונאמר כי כל הדברים
הללו (במרבית המקרים) מגיעים מכוונות טובות ונכונות, ומיועדים "לנצל"
נכון את מנגנון הכיול האג'ילי. אך כפי שציינתי אינם
תמיד פוגעים במטרה.
מנקודת מבטו של צוות
הסקראם – הוא עבד קשה במהלך הספרינט, התמודד עם לא מעט אתגרים, ביצע הכנות מוקדמות
להצגת ה Review. אך
עתה בפגישת ה Review עצמה הוא סופג
ביקורות מכל עבר.
ישנם צוותי סקראם אשר
יידעו להכיל זאת ולהפיק את הלקחים/שינויים לספרינט הבא, אך ישנם גם לא מעט צוותי
סקראם אשר ייקחו זאת למקום אחר. נוכל לראות זאת בכך
שבפגישות Review הבאות הם כבר
אינם מעוניינים להציג, ובמקרים מסוימים מעדיפים כלל לא להגיע לפגישות
אלו, ולהתעדכן לאחר מכן בשורה הסופית.
האם שורש הבעיה נמצא
בצוות הסקראם? בבעלי העניין? או שמא בתהליך?
כפי שציינתי בפתיח,
המאמר יתמקד בנקודת מבטו של הצוות, על כן במקום לנסות ו"לחנך את הצוות"
ש"זה המצב" וש"יתמודד" אציג גישה מכיוון אחר לפתרון
הבעיה.
הגישה הכוללת בפגישת ה Review צריכה להשתנות. במקום הסתכלות על חצי הכוס הריקה וניצול
ההזדמנות לבקר את הקיים, יש להסתכל על חצי הכוס
המלאה ולנצל את ההזדמנות להחמיא על ההתקדמות.
תנו את הבמה לאנשי
הצוות, שאלו מה היו האתגרים המשמעותיים בספרינט וכיצד התמודדו איתם, וודאו שהצוות
יוצא מחוזק מהפגישה (כמובן בתנאי שהספרינט לא נכשל)
דעות וביקורות אשר
קשורות לשינויים באפיון המוצר, בנראות שלו, וכיו"ב, צריכות להיאמר ולהיקבע
במעגלים אחרים מחוץ לפגישת Review זו.
היכן עובר הגבול? האם
מתוך כך שהצוות הוא המנוע המרכזי של הארגון, כל
בקשה של הצוות צריכה להתקבל בזרועות פתוחות ובהסכמה?
שורת סיכום
היכן עובר הגבול? האם
מתוך כך שהצוות הוא המנוע המרכזי של הארגון, כל בקשה של הצוות צריכה להתקבל
בזרועות פתוחות ובהסכמה?
מלבד הממדים החומריים
(ענייני תקציב וכו') לטעמי בקשות הצוות צריכות –
1.
לקבל את ההתייחסות הראויה
2. להיבחן תמיד בשורה
התחתונה של רמת הפרודוקטיביות.
יש לזכור כי בקשות
ייעול הקשורות לצוות יגיעו במרבית המקרים ע"י הצוות עצמו, חוסר התייחסות ראוי
יגרמו לאכזבה/מירמור/חוסר רצון, ומכאן כפי שתיארתי במאמר הדרך קצרה לפגיעה
ברווחיות החברה. התייחסות ראויה מצד שני ולקיחת סיכון במימוש שינוי כזה או אחר יאפשרו
לשמר את צוותי הסקראם פרודוקטיביים.
יוגב טל, PMP
Program Manager, Agile/Lean Coach
PMI Israel E-Magazine Editor
אין תגובות:
הוסף רשומת תגובה