Posts tagged ‘עבודת צוות’

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

בהטמעות של סקראם (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.

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

הפיל בסלון

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

“הפיל בסלון” הוא ביטוי מתורגם מאנגלית – “The elephant in the living room” המשמעות של הביטוי היא שיש משהו בחדר שכולם רואים אותו, הוא גדול מידי בכדי להתעלם ממנו, אבל אם זאת מוזר או מביך מידי בשביל לדבר עליו.

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

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

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

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

איך לבנות צוות מנצח ?

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

The A-Teamאתחיל בהגדרה שלי לצוות: צוות הוא קבוצה של אנשים שעובדים בסינרגיה ע”מ להשיג יעדים משותפים.
רוב ה”צוותים” שאני פגשתי אינם עונים להגדרה שהצגתי, ברוב הצוותים שאני פוגש ישנו מנהל חזק המכונה ר”צ, שאחראי לקבלת החלטות, לפירוק העבודה לגורמים, וחלוקת הגורמים הללו בין חברי הצוות, כאשר בד”כ אין חפיפה אמיתית במטרות של כל אחד מחברי הצוות, כי אם לכל אחד יש מטרה משלו ואם יש תלות אז היא חד צדדית ורק צד אחד תלוי בשני.
לדעתי בצוות טוב ישנה תרבות כזו שאין משמעות גדולה להצלחה של הבודד בתוך הצוות, הצוות מצליח או נכשל כיחידה אורגנית ולא כאוסף של בודדים, לא שאני אומר שאין משמעות להצלחה של יחידים, אך המשמעות הזו נשארת בתוך הצוות. אני לא זוכר איפה ראיתי את זה אבל מישהו פעם אמרכתב שחברים בצוות טוב, מכסים על החסרונות אחד של השני, שהרי לכל אחד יש חסרונות. אני באופן אישי (כפי שכבר כתבתי) מאמין בצוותים שמנהלים את עצמם (Self-empowered teams) צוותים מסוג זה מראים פעם אחר פעם שהם מסוגלים להתגבר על רוב המכשולים שעומדים בדרכם, מגלים יצירתיות בפתרון בעיות, ומפתחים הווי פנימי ואווירה טובה.
אני לא רוצה שישתמע, ולא לרגע, שזה פשוט. בשביל שצוות יגיע לרמה הזו דרושה תמיכה, הדרכה ועזרה, דרושה הבנה וסבלנות, וגם אז, לא תמיד זה מצליח, לפעמים הגורם האנושי הוא חזק יותר, אבל מניסיוני, ברוב המקרים זה אפשרי, והפירות הם מתוקים מתוקים….

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

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

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

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

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

אלמנטים של סקראם….רטרוספקטיבה

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

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

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

תפיסת ה-“בחינה והתאמה” מיושמת בסקראם באמצעותה של ישיבה שמתבצעת בסוף כל ספרינט ונקראת רטרוספקטיבת הספרינט (Sprint retrospective).

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

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

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

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

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

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

אבטחת איכות (QA), לא מה שחשבתם.

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

אני חושב אחרת.

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

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

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

בואו נבחן את הרעיון הבא: מחקרים מראים שכ-80% מהבאגים נגרמות ע”י טעויות אנוש, אז אם הייתה לנו מערכת שמונעת לפחות חלק מטעויות האנוש היינו יכולים להימנע מחלק מהבאגים, ובכן, יש מערכות כאלה.

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

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

לתפיסה הזו אני קורא (מתרגם): להכניס את הבדיקות פנימה – Build quality in*.

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

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

ישנן כיום מספר שיטות למימוש תפיסה כזאת, על אחת מהן דיברתי (Continuous integration), ובנוסף ישנם כלים רבים לכתיבה והפעלה של בדיקות אוטומטיות:
ל-JAVA יש את : Junit, EasyMock, NGTest,Fitnesse
ל- C++ יש את : CppTest,Jungle,Fitnesse
ל – .NET – יש את : NUnit, TestDriven.NET
וכו’…

*הביטוי מתוך הספר Lean Software development . הוספתי לינק.

הישיבה היומית – לעמוד זה לא מספיק

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

  • שיתוף הצוות בהתחייבויות אישיות
  • עדכון סטאטוס
  • זיהוי בעיות
  • חיזוק הצוות.

Daily meeting

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

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

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

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

טוב. ישיבה נעימה :)

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

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

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

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

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

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

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

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

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

המטבח הפתוח.

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

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

אין לי תשובות רק שאלות.

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

תחשבו על זה… וגם תלכו למסעדות :)

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

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

בסקראם מוגדרת ישיבה יומית, הישיבה היומית נקראת Daily standup meetingDaily Scrum, היא ישיבה שאורכה לא יותר מ-15 דקות (בד”כ פחות), והיא מתבצעת באופן יומי בצורה הבאה:
כל הצוות מתכנס במקום קבוע ובשעה קבועה ועומד במעגל – הסיבה שאנחנו עומדים היא פשוטה, בשביל שהישיבה תהיה קצרה. בישיבה יכולים להימצא אנשים שאינם חלק מהצוות אך חל עליהם הכלל הבא – “ששש….”, אסור להם לדבר. בישיבה מדברים אך ורק, חברי הצוות והסקראם מסטר (וגם הוא עדיף שישתוק אם זה אפשרי).
בישיבה עונה כל אחד מחברי הצוות בתורו על 3 שאלות פשוטות :

  • מה עשיתי מהישיבה הקודמת עד עכשיו?
  • מה אעשה מעכשיו עד הישיבה הבאה?
  • האם משהו מפריע לי לביצוע המשימות?

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

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

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

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

טוב, אני חייב לרוץ לישיבה היומית… נתראה בפוסט הבא.