Posts tagged ‘Teamwork’

את מי כן הייתי מעסיק ?

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

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

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

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

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

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

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

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

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

אני לא הייתי מעסיק את סופרמן

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

מכירים אותו ?

אני די משוכנע שאתם מכירים אותו.

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

imageאני לא הייתי מעסיק אותו.

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

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

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

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

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

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

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

חבל על הזמן…

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

יום שני 11:00 – ישיבת הנהלה הכירה:
המנכ”ל גדי מברך את כולם ביום טוב וסוקר את הפעילויות הצפויות לחברה בעתיד הקרוב, לקוחות פוטנציאלים ועוד מספר עניינים אדמיניסטרטיביים, גדי מזכיר לכולם שהחברה החליטה לעבור לגישות אג’יליות ורזות יותר, “השינויים שאנחנו עושים הם חשובים, הם נוגעים לחלקכם, ויש להקדיש זמן ליועץ שהבאנו ולהתייחס בכובד ראש לדברים” הוא אומר, “מסכנים הפיתוח“ אומרת דליה סמנכלית השיווק, גדי מחייך.
אחד כך עובר גדי לסבב הרגיל של דיווחי סטטוס:
image– שירה, סמנכ”לית פיתוח, מסתכלת על גדי ומספרת על מצב הפרויקטים, הבעיות, ואף מציינת שכבר שני צוותים עברו לפיתוח “בשיטת סקראם” שזה הטרנד החם כרגע בעולם תהליכי פיתוח התוכנה האג’ילים, “יופי, איך הולך?” שאל גדי, “אנחנו מנסים את זה, גם דיברנו עם היועץ שיעזור לנו, אני מאמינה שזה יכול לקצר משמעותית זמני פיתוח ולהגביר את האיכות”, מעולה! אומר גדי תעדכני אותי כשיהיו מסקנות.
– אחרי שירה דיבר יניב, סמנכ”ל HR, הוא סיפר לכולם שעקב חוסר תקציב אין יום כיף השנה, וגם כנראה לא יהיו בונוסים. בנוסף הוא הזכיר שיש למלא את הערכות העובדים עד סוף השבוע ולקבוע יעדים אישיים חדשים לשנה הבאה, “ולא לשכוח לנרמל את התוצאות ברמת הצוות, והמחלקה”, כולם מהנהנים.
– לבסוף מדבר אורן, סמנכ”ל תפעול, הוא טוען שהוא גילה לאחרונה שלקוחות יוצרים קשר עם אנשי פיתוח ולהיפך “זו תופעה חמורה ואנחנו חייבים לנתק את הקשר הזה”, כולם מהנהנים בהסכמה.
– דליה סמנכ”לית שיווק, מעלה בתורה את הבעיה שאנו לא עומדים בזמנים שהבטחנו ללקוח, ומעבר לכך יש לנו בעיה קשה עם לקוח X, יש כרגע מספר בעיות קריטיות וחייבים לפתור לו את הבעיות, ומהר. גדי (המנכ”ל) מסתכל על שירה, שירה אומרת שהם עושים את המקסימום והמפתחים כבר באו 3 סופי שבוע אחרונים בכדי לנסות להדביק את הפער, “והשבוע עוד מפתח עוזב, באמת שאנחנו עושים את המקסימום.”, “את צריכה לשמור על האנשי שלך יותר טוב” אומר גדי בחצי חיוך חצי רצינות. “אני מאמינה שעד סוף הגירסה נצליח להשלים את הפער” אומרת שירה. השיחה ממשיכה עוד קצת ואז תם הזמן לישיבה.
– “טוב, שבוע טוב לכולם” אומר גדי. שבוע טוב, הם עונים לו.

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

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

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

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

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

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

נ.ב.
אחרי שקראתי את הפוסט הבנתי שעקב ריבוי הדמויות והמידע (יחסית לרמת הפירוט) אפשר לפרש את הישיבה בכל מיני צורות וצבעים, כוונתי היתה הפשט, בבקשה אל תניחו הנחות אלא התבססו על העובדות.
ואולי אכתוב עוד אחד כזה על ישיבת R&D…. אולי.

מנהיגים מנצחים

תודה לאילן קירש על ההשראה והלינק

לשבור את הקיר

clip_image002[4]

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

אז בואו נתן דוגמאות לכמה קירות כאלה באירגונים חלקם פיזיים וחלקם וירטואלים:

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

הקיר שמעליו זורקים את המסמכים מגורם אחד לשני:
זהו קיר וירטואלי בעיקר והוא נוצר בד”כ clip_image004[4]בעקבות מבנה ארגוני והגדרות תפקידים, קיר זה מייצר בעיה דומה לבעיית הקיר הפיזי ו”תורם” לאי הבנות. בנוסף הקיר הזה מאופיין בעוד משהו: התנערות מאחריות – כשאני מקבל מסמך ומממש אותו למיטב הבנתי, אז לכל בעיה שנוצרה אני תמיד יכול להאשים את המסמך או את מי שכתב אותו, כאשר כותב המסמך ואני עובדים יחד, אזיי שנינו אחראים באותה המידה ומחויבים להצלחת המשימה כולה ולא רק “לחלק שלי במשימה”. דוגמאות קלאסיות הן מסמכי בדיקות, מסמכי ארכיטקטורה וכו’.
איך לשבור? להכניס את הבודקים, הארכיטקטים, מהנדסי המערכת וכו’ לתוך הצוותים.

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

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

י יש ישי ישיב ישיבו ישיבות

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

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

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

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

איך זה מרגיש ?

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

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

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

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

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

אז איך זה מרגיש לעבוד בסקראם ?

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

אז אני יודע שזה מתיימר מאוד, אבל לפי ניסיוני המעשי, ככה זה מרגיש.

שיטה עם ערכים

לא הרבה אנשים מכירים את העובדה שכמו ל”מניפסט האג’ילי” גם לסקראם (Scrum) יש 5 ערכים, הערכים האלו מוזכרים בספר הראשון שנכתב על המתודולוגיה שנקרא “Agile software development with Scrum”, הספר נכתב ע”י מייק בידל וקן שוובר (Mike Beedle & Ken Schwaber) ובו מצאו לנכון הכותבים להקדיש מקום לערכים הבסיסיים שעליהם מבוססת השיטה.

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

clip_image002[4]

כעת אציג בפניכם את חמשת הערכים:

Commitment – מחויבות: הצלחה אמיתית של סקראם מבוססת על התחייבות, ההתחייבות האמיתית הכנה שמאחוריה הכוונה “אנחנו נשעה כל מה שביכולתנו בכדי לעמוד בהתחייבויות שלקחנו על עצמנו“. לא לשווא הדגשתי, התחיבות היא משהו שמישהו לוקח על עצמו בצורה וולונטרית, ולא מקבל מצד ג’ כלשהוא, בסקראם בתחילת כל ספרינט הצוות, והוא בלבד, בוחר (תוך התבססות על סדר עדיפות) את המשימות שהוא מתחייב לסיים על סוף הספרינט, הוא לא מקבל על עצמו התחייבויות של מחלקת השיווק למשל שהבטיחה ללקוח הרים וגבעות. אבל לא רק הצוות מתחייב, גם ה-PO מתחייב לשמור על ה-Product backlog במצב טוב, הוא גם מתחייב לתת מענה לשאלות והדילמות שיש לצוות.
לא פחות (אם לא יותר) חשוב, היא ההתחייבות של הארגון לתת תמיכה לצוות ולספק לו את כל הכלים שברשותו, ע”מ לסייע לצוות לעמוד בהתחייבויות שלו, ולהסיר עיכובים ובזבוזים (ראו פוסט על waste).

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

Openness – פתיחות: כפי שכבר ציינתי בעבר, אחד המאפיינים הבולטים של סקראם הוא השקיפות, סקראם דואג שכל הנתונים שידועים על הפרויקט יהיו נגישים לכולם, הבסיס בתהליך אמפירי שבבסיסו
“בחינה והתאמה” (Inspect & Adapt) בנוי על כך שכל הנתונים, החסרונות והיתרונות, ידועים לכל. הפתיחות דורשת מכל אחד מהאנשים שהוא חלק מהפרויקט לומר תמיד את האמת, גם היא לא נעימה וע”י כך להיות מסוגלים לבצע התאמות למציאות ולא להחביא את המציאות מאחורי ערימה של מסמכים ותוכניות, לכן בסקראם כל הישיבות (מלבד הרטרוספקטיבה) פתוחות לכולם (לצפייה), לכן בסקראם נהוג שה-“Sprint backlog” וה-“Sprint burndown chart” נמצאים על הקיר במקום גלוי. בסקראם לא אמור להיות שום מידע שמוסתר בכוונה תחילה מכל שיקול שהוא.

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

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

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

כשהצוות לא מתפקד.

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

במסגרת הספרים הרבים שנכתבו בנושא מוצעים לא מעט מודלים שייעודם הוא לסייע באנליזה של הדינאמיקה של צוות ולנסות למקד את הבעיות.
מבין המודלים המוכרים מאוד שעוסקים בשלבי התפתחות של צוות ישנם למשל את:
המודל של התפתחות צוות ע”פ ברוס טאקמן: Forming – Storming – Norming – Performing
המודל של ג’וזף פרלין: Burning – Cooking – Stagnating – Congealing – Solid

clip_image002אבל אני לא הולך לדבר על המודלים הללו, אני הולך להציג מודל נוסף, שונה קצת, של פטריק.מ. לנסיוני שנקרא: חמשת הליקויים של צוות או באנגלית – 5 dysfunctions of a team. המודל הזה מוצג בספר בעל אותו שם, הספר הוא קל מאוד לקריאה, וכתוב לא כספר לימודי אלא כסיפור על מנכ”ל שמגיע לחברה בקשיים, ומוצא שהבעיה של החברה למעשה מקורה בתפקוד של הצוות הבכיר של החברה.

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

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

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

3. חוסר מחויבות – lack of commitment – כאשר אנשים לא מרגישים שהייתה להם חלק בהחלטה מסוימת, או לא ניתנה במה מספקת לדעות שלהם, מצטבר תסכול, התסכול הזה מתבטא (לעיתים בצורה גלויה ולעיתים לא) בחוסר מחויבות, לשם המחשה, נניח שהמנהל שלכם מקבל החלטה ואין לכם שום אפשרות להשפיע עליה, סיכוי טוב שלא תרגישו באמת מחויבים להחלטה הזאת, תבצעו אותה כנראה (הוא בכל זאת המנהל) אבל רק לשם לצאת מידי חובה ולא מתוך מחויבות אמיתית. מחויבות היא מרכיב חיוני בתוך צוות, אני לא חושב שיש צורך להרחיב למה.
כשאין מחויבות אישית ו”קנייה” (buy-in) של המשימות יורד משמעותית הסיכוי להשגת המטרות והיעדים של הצוות. כאשר חברי הצוות לא מרגישים מחויבות לביצוע המשימות הם גם לא מרגישים אחריות להישגים של הצוות ובזה נוגע הליקוי הרביעי.

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

5. חוסר תשומת לב לתוצאות – Inattention to results – זהו הליקוי החמישי, המצב שבו חבר בצוות מעדיף את טובתו האישית יותר מטובת הצוות. אל תבינו לא נכון, אני לא מדבר על החיים האישיים, אני מדבר מצב שבו חברי הצוות מרוכזים יותר בלהדגיש את ההישגים האישיים שלהם ללא התחשבות בתוצאה הסופית. המצב הזה מאופיין בד”כ במצבים שבהם כל אחד בצוות בטוח שהוא עשה את הכל נכון ולמרות זאת הצוות לא משיג תוצאות (מנהל הפרויקט עשה עבודה נהדרת, זה המפתחים שעשו עבודה גרועה… וואלה?!).

הליקוי החמישי הוא בהחלט האולטימטיבי!!! אבל בכדי להתגבר עליו באמת צריך לעבור את כל המשוכות שבדרך, וזה ידידי, לא קל.

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

הסכמות עבודה צוותיות.

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

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

clip_image002

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

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

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

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

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

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

לסיום אני רוצה לתת מספר דוגמאות להסכמות “נכונות” ו-“לא נכונות” לדעתי:
נכונות
– לכתוב תיעוד מעל כל פונקציה שאורכה עולה על 5 שורות.
– לכתוב תיעוד מעל כל מחלקה.
– לכל פונקציה public יש לכתוב לפחות שתי unit tests – הצלחה וכישלון.
– כל אחד מבצע לפחות יום אחד בשבוע pair programming.

לא נכונות
– לתעד את הקוד יותר.
– לכתוב יותר בדיקות.
– להגביר שיתוף ידע בין אנשים.