Posts tagged ‘coaching’

איך שואלים “למה”?

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

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

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

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

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

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

במקום להגיד: “אף אחד לא ירוויח מהרעיון הזה”
אפשר להגיד: “מי לדעתך ירוויח מהרעיון הזה?”

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

במקום לשאול: “למה בחרת בדיזיין הזה?”
אפשר לשאול: “מה היו השיקולים לבחור דוקא בדיזיין הזה”
אפשר לשאול: “מה היתרונות של אלטרטיבה א’ מול אלטרנטיבה ב’?”

במקום לשאול: “למה לא הספקת לסיים את המשימה?”
אפשר לשאול: “אילו דברים הפריעו לך לסיים את המשימה?”
וכדומה…

אז הנה לכם כלי פשוט וקל שיכול לעשות שינוי משמעותי.

עוד סרטון מבית היוצר של דן פינק… גדול

מכתב פתוח לדוד בוב

בוב היקר,

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

אתייחס כעת לעל אחת מהנקודות שהעלית:

1. חוסר בטכניקות טכניות – אתה צודק, וזה ידוע לרוב שסקראם, בניגוד למשל ל-XP אינו מציין באיזה טכניקות או שיטות יש להשתמש כשמפתחים תוכנה, ולטעמי לא סתם: לו היה סקראם מגדיר באיזה שיטות לעבוד כשמפתחים תוכנה הרי היה גורלו להפוך לא רלוונטי כעבור פרק זמן מסויים, וכידוע לנו, תחום התוכנה הוא דינאמי ומשתנה. כאשר צוותים היום בוחרים לעבוד בסקראם הם בד”כ משתמשים בשיטות כגון CI, Pair programming, TDD וכו’ מכיוון שאלה דברים שנכון להיום אנו יודעים שהם עובדים, אבל מה יהיה עוד 10 שנים, האם עדיין אותן שיטות יהיו רלוונטיות ? אז ממש כמו ה-Agile Manifesto שאתה מהיוזמים שלו, לא צוינו פרטים טכניים בכדי לשמר אותו לאורך זמן, כך גם סקראם, ואני רואה בכך יתרון.

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

3. מסכים בהחלט – לא מומלץ ואף גורם נזק בד”כ כשהסקראם מסטר הוא גם מנהל פרויקט. אבל זה לא חסרון של סקראם.

4. מסכים! מסכים! מסכים! אבל גם זה לא חסרון של סקראם אלא של הארגון שמפיץ אותו, היה נפלא לו היינו נפתרים מה-“Certified” לאלתר.

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

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

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

8. צוותים מרובים או “סקראם בגדול” היא באמת שאלה פתוחה ואני לא חושב שמישהו עדיין מצא אחת גלובאלית להתמודד עם השאלה, לטעמי האישי הרעיונות של Bas Vodde ו-Craig Larman הם טובים, אך גם הם לא מתאימים לכל מקום כמו כפפה ליד, הנושא של פיתוח בסדר גודל גדול הוא נושא כנראה סבוך מידי ואין פתרון אחד (ממש כמו התפיסה האג’ילית – One size does not fit all)

זוהי תשובתי מלאת ההערכה אלייך דוד בוב (Robert C Martin).

אלעד.

החסרונות של סקראם ע”פ Uncle Bob

לא פעם ולא פעמיים אני נתקל באנשים ששואלים אותי: “מהם החסרונות של סקראם?”
שאלה קשה. בעיקר למישהו שמאמין שסקראם היא דרך טובה מאוד לפיתוח תוכנה.

ולאחרונה, בקבוצת הדיון של סקראם ביאהו (Scrum development) נסוב דיון בשאלה הנ”ל, בדיון הזה הציג מישהו את השאלה הזאת ולא למרבה הפלא, ענה לו לא אחר מאשר Robert.C.Martin הידוע גם בכינויו Uncle Bob. אני רוצה בפוסט זה ובתרגום חופשי, לתאר לכם את תשובתו של “הדוד בוב”:

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

1. חוסר בטכניקות טכניות. סקראם מצויין במתן הכוונה בכל הנוגע לניהול הפרויקט אבל אינו מסייע לתהליך הפיתוח עצמו, בכל הטמעה מוצלחת של סקראם ישנה השאלה של טכניקות משיטות אחרות כגון XP, השיטות שיש לצרף לשיטה הן כנראה: TDD, CI, Pair programming, Acceptance testing ו- Refactoring

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

3. הנטיה של הסקראם מסטר לקחת על עצמו תפקידים של מנהל פרוייקט. זו לא בעיה של סקראם עצמו, אלא בעיה שקורת לפעמים כשהסקראם מתפתח, אולי זה קשור לשימוש במילה “מסטר”, אולי המונח מאמן – Coach, מתאים יותר. הטמעות טובות של סקראם לוא דוקא מייצרות חפיפה בין תפקיד הסקראם מסטר למנהל הפרוייקט.

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

5. סקראם לא מספק מספיק הכוונה לגבי מבנה ה-Backlog. למדנו במשך השנים שהבקלוג הוא רשימה היררכית של דרישות המורכב מ-Epics, themes, stories, גם למדנו דרכים טובות להעריך אותם באופן סטטיסטי, למדנו גם איך לשבור אותם.

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

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

8. צוותים מרובים. סקראם אומר מעט מאוד בנושא התיאום בין צוותים. זוהי לא מגרעה ייחודית של סקראם. אג’יל בעצמו הוא שקט בנושא. סקראם מדבר על הרעיון המעורפל של “סקראם של סקראמים” – Scrum of Scrums, אבל הרעיון כמו שהוא איננו מספיק ולא הוטמע כמו שהוא כמעט בכלל. “סקראם בגדול” נשאר תחום של יועצים מסויימים שטוענים שיש להם תשובות, ואין קונצנזוס בנושא כלל.

בפוסט הבא תובא ממש כאן, תגובתי לדוד בוב.

תמריצים מגבירים מוטיבציה? כנראה שלא…

תהליך הטמעת סקראם

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

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

בקווים כלליים לתפיסתי הטמעה מתחלקת לארבעה חלקים עיקריים:

– הדרכה
– הצבה של תשתית מתאימה לשינוי
– ליווי ותמיכה
– כוונון (Tuning).

הדרכה – שלב ההדרכה הוא באורך יומיים בד”כ, וכולל העברה של המושגים הבסיסיים של Agile ו-Scrum והבנה עמוקה יותר של הסיבות והתמריצים לאמץ את הדברים.

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

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

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

איך לעודד ביצוע משימות “לא נעימות” ?

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


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

ישיבות או לא להיות

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

clip_image002באופן קלאסי ישיבה מתחלקת לשלושה חלקים:

– הכנת השטח.
– איסוף נתונים
– עיבוד הנתונים.

הכנת השטח
הכנת השטח כוללת בד”כ הצגה ברורה של הנושאהבעיההשאלה שבגללה כינסנו את הישיבה, למרות שלעיתים זה נשמע טריוויאלי, ויש הנוטים לחשוב שאין בכך צורך, הניסיון שלי מראה לי שיש ערך רב בלהשקיע מספר דקות ולהבהיר (שוב) את הסיבה המדויקת שבגינה מתקיימת הישיבה.
ניתן לשאול את המשתתפים האם הנושא הזה מקובל עליהם, האם זה מה שהם רוצים לדון בו, מרבית הסיכויים הם שתקבלו כן מכולם, אבל פעולה פשוטה זו מסייעת בהעלעת מידת המחוייבות של המשתתפים.
אני ממליץ שבנוסף לתיאור בע”פ של הנושא, הנושא יהיה זמין ובולט בצורה ויזואלית, ע”י כתיבה שלו על לוח מחיק או על פליפ-צ’ארט (מישהו יודע איך קוראים לזה בעברית?), כאשר הנושא קיים באופן ויזואלי זה עוזר לשמור על המיקוד של המשתתפים, ומשמש ככלי עזר למנחה הישיבה במקרה שמאבדים את הפוקוס ע”י שימוש במשפטים בגון: “חיים, זה קשור באופן ישיר לנושא או שניתן לדון הזה אח”כ ?”
בחלק הזה של הישיבה גם ניתנת הזדמנות למשתתפים לצאת מהישיבה כי זה לא מה שהם חשבו, או שהם חושבים שאין שום ערך מוסף בהשתתפותם. שלב זה בד”כ דורש 5%-10% מזמן הישיבה.

איסוף נתונים
זהו השלב השני, לשלב זה רוב הישיבות מגיעות, אבל רבות גם לא יוצאות ממנו.
בשלב זה אנו מעוניינים שהמשתתפים יאספו ידע והבנה לגבי הנושא, יחליפו דעות בינהם, ויבנו למעשה, ידע שבאמצעותו נוכל להתקדם. תפקיד המנחה הוא בד”כ לספק את התשתית לאיסוף הידע ולאפשר למשתתפים להישאר ממוקדים ולקבל תועלת מירבית ומספר רב ככל האפשר של תגובות רלוונטיות אפשריות. ישנן טכניקות רבות לאיסוף מידע בקבוצה (הנה רעיון לפוסט), ולא נדון בהם במאמר הזה. (מיקוד, כבר אמרתי?)
ע”מ לאפשר לכל הנכחים להשתמש בנתונים ובתגובות שנאספו אני ממליץ לדאוג לכך שכל התגובות יהיו זמינות לכולם ע”י שימוש בלוח מחיק מקרן משהו דומה. השלב הזה בד”כ דורש 50%-70% מזמן הישיבה.

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

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

סקראם מסטר – טכנולוג או טכנופוב ?

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

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

אם קראתם טוב את ההגדרה אני מניח שלא ממש מצאתם שום דבר שמצביע על כך שעליו להכיר באיזה שהיא רמה את הצד הטכני של הבעיה שהצוות מתמודד איתו, לעומת זאת עליו להכיר ולהבין לעומק את מתודולוגית הסקראם (שהיא פשוטה), עליו לדעת להנחות ישיבות, ולהסיר מכשולים, גם אין כמעט ויכוח על כך שרצוי שהסקראם מסטר יבין ויפנים את התפיסה האג’ילית כדי שיהיה מסוגל להנחיל אותה לצוות, ואף יכיר כלים אג’ילים כגון XP, TDD, Pair programming, Continuous integration וכו’
אם כך, הסקראם מסטר לא צריך ידע טכני. נחמד. אבל… ותמיד יש אבל, מה אם יש לו ידע טכני, האם זה יעזור או יפריע לביצוע התפקיד? שאלנו את פלוני ואלמוני ולהלן תשובתם:

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

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

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

יש עוד שתי נקודות שעולות לי בהקשר הזה:

  • כאשר שוקלים איזה “סוג” של לסקראם מסטר רוצים, יש לשקול את המחיר של ההתעסקות הטכנית, כאשר סקראם מסטר עסוק בפן הטכני של הפרויקט הוא מזניח, ולו במעט, את הפן ההתנהגותי של הצוות.
  • כאשר לסקראם מסטר ידע טכני, בנוסף לדילמות הרגילות שיש לו, נוספות לו דילמות חדשות בפן הטכני, למשל (דוגמא שלי מהחיים), הסקראם מסטר רואה שהצוות עושה החלטה טכנית גרועה (לדעתו), האם הוא מתערב לצוות בהחלטה ?
    נקודה למחשבה: אם נחזור רגע לערכים האג’ילים נמצא בראש הרשימה את המשפט הבא:
    Individuals and interactions over processes and tools.
    מה זה אומר לכם לגבי הנושא הזה?

סקראם מסטר – מי אתה ?

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

  • צניעות – תפקיד הסקראם מסטר כברירת מחדל אינו מציע חיזוקים לאגו, אופי התפקיד הוא מעט כפוי טובה, ולכן, לפני שחובשים את הכובע, יש להצטייד במעט צניעות והרבה מצב רוח טוב.
    ההתנהלות היום יומית של הסקראם מסטר כוללת בעיקר: ניהול ישיבות, פתרון בעיות (לעיתים סבוכות), מאבקים עם מנהלים כאלה ואחרים ע”מ לאפשר לצוות לעבוד ללא הפרעות והתמודדות תמידית עם מתנגדי האג’יל והסקראם (אני קורא להם אנשי התהליכים הלא נגמרים) וכל זה רק כלפי חוץ (הצוות), למעשה סקראם מסטר טוב לא יכול להתגאות באופן ישיר בהישגים של הצוות (ובצדק!), סקראם מסטר יכול, לכל היותר, להתגאות במה שהוא עזר להשיג.
    מעבר לכך שהתובנה הזו נכונה לטעמי, היא גם נדרשת ע”מ לתת דוגמא אישית לחברי הצוות, ולשדר את המסר הבא: “מי שהכי חשוב כאן, זה מי שעובד – מי שמלכלך את הידיים”.
    אסתכן ואף אומר – סקראם מסטר טוב, הוא אחד שהצוות מסתדר טוב בלעדיו.
  • שיתופיות – אחד המצרכים החשובים (שאף פעם אין מספיק ממנו) הוא שיתוף פעולה, שיתוף פעולה בתוך הצוות, בין הצוותים, בין המנהלים לצוות וכו’. הניסיון מלמד שקל יותר לקבל עזרה ושיתוף פעולה צריך אם אתה בעצמך כזה, ולכן לטעמי, ערך רב לאדם שבבסיסו יודע לשתף פעולה ולעזור. כאשר חברי הצוות רואים שהסקראם מסטר הוא “כזה”, חברי הצוות מרגישים בטוחים לדון באופן חופשי ולשתף בבעיות, פשוט כי הם יודעים שיש מי שיעזור כשצריך. על סקראם מסטר טוב לדאוג לכך ששיתוף פעולה תהיה נורמה התנהגותית בתוך הצוות ואף לציין באוזני הצוות כאשר הוא נתקל בהתנהגות שונה.
  • מחויבות – כמו לכל תפקיד בעל אחריות, על הסקראם מסטר לגלות מחויבות אמיתית לפרויקט ולהצלחתו, אך במקביל לגלות מחויבות כלפי הצוות, הקו הדק הזה הוא לא טריוויאלי וכאן מגיע לעזרתו של הסקראם מסטר – הסקראם. המסגרת הסקראמית עוזרת להגדיר את הגבולות בין טובת הצוות וטובת הפרויקט.
    מדד נוסף למחויבות של הסקראם מסטר הוא כמות הבעיות הפתוחות שיש לצוות, סקראם מסטר מחויב יעשה מאמץ גדול ע”מ לפתור את הבעיות של הצוות מהר ובצורה טובה ככל האפשר, גם אם מדובר במשימות קשות כגון לשכנע את מנהל הפרויקט לממן שרת חדש, להשיג משאבים לעזרה חיצונית כשצריך וכדומה.
  • יכולת השפעה – אחד הפרמטרים שמצביעים על כך שסקראם מסטר הוא מוצלח הוא מידת ההשפעה שלו על הצוות ומחוצה לו. בשלב ראשון יהיה על הסקראם מסטר בכלל לשכנע את הצוות לנסות סקראם, בהמשך יהיה עליו לנסות להשפיע על הצוות לאמץ שיטות אג’יליות כגון TDD, Pair programming וכדומה. יש לציין כי ההשפעה אינה צריכה להיות בסגנון של ניהול אלא בסגנון “שכנועי” זאת עקב ההבנה שכשמישהו עושה משהו מתוך בחירה מידת המחויבות שלו היא גדולה יותר מאשר הוא מבצע משהו מתוך כורח.
    כמו שנאמר, הסקראם מסטר גם יזדקק ליכולות השכנוע שלו מחוץ לצוות, למשל לשכנע צוות אחר לספק מוצר חלקי לצוות הסקראם, לשכנע את מנהל המחלקה להוסיף בודקים במשרה מלאה לצוות או אפילו לשכנע את סמנכ”ל הפיתוח לנסות סקראם, באופן כללי על סקראם מסטר לנסות ולהתמצא ככל האפשר בצורת קבלת ההחלטות בארגון ע”מ לחדד את יכולת ההשפעה שלו.
  • הקשבה – היכולת הזאת שאולי נשמעת לכם טריוויאלית, אינה פשוטה כלל לאימוץ ודורשת משמעת עצמית וסבלנות. סקראם מסטר אמור להתבונן אל תוך הצוות, להקשיב, לחפש בעיות, לזהות תקלות, לעזור לצוות לתקשר בצורה טובה ולתת לצוות כלים להתמודדות עם מצבים כאלה ואחרים. עליו לאתר חילוקי דעות בשלבים מוקדמים, לזהות בעיות בינאישיות לפני שהן מתנפחות למימדים אדירים.
  • ידע והבנה– ללא ספק, על סקראם מסטר להבין את מה שהוא עושה ולמה הוא עושה זאת, עליו להבין לעומק את התפיסה האג’ילית ואת הרציונל שלה, להכיר בצורה מעמיקה את ה”סקראם” ואת השיטה האמפירית, ידע זה יקנה לו ולסובבים אותו ביטחון שתאפשר לו להוביל את הצוות להצלחה.

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