Posts tagged ‘Scrum master’

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

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

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

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

עד כאן איך לא.איך כן?

תתחילו בבית (תיקון*: תתחילו בעצמכם במקום העבודה)

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

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

image

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

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

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

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

מיפוי מח של סקראם מסטר

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

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

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

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

Scrum master's mindmap

תמיד מאשימים את ה-ש.ג. ובצדק.

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

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

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

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

מידי פעם, מישהו מחליט על שינוי, שינוי תהליך, שינוי בשיטות עבודה, מעבר לסקראם, שינוי לצוותים מנוהלים עצמאית, מעבר ל-TDD, מנסים CI, לנסות Pair programming, וכדומה.
אין לי סטטיסטיקה אבל לפי ניסיוני לפחות בחצי מהמקרים השינוי לא מצליח בטווח הארוך, צוות הסקראם מפסיק לעשות רטרוספקטיבות ודיילי, ראש הצוות בסוף כן אומר לצוות מה ואיך לעשות, כותבים בדיקות אחרי הקוד ולא לפניו, הבילד אדום במשך ימים שלמים ואף שבועות, וכו’.

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

איך שומרים על שינוי, או, איך שומרים עלינו מעצמינו?

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

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

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

עמוד נח.

מכתבים למערכת

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

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

הוא כתב:

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

אני עניתי

הי ישראל ישראלי.

שאלות קשות יש לך :)

אני אנסה להביע את דעתי.

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

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

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

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

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

אלעד.

הוא ענה:

הי אלעד,

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

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

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

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

תודה,
ישראל ישראלי

גם אני, ואני מאמין שגם “ישראל”, נשמח לשמוע את חוות דעתכם בנושא.

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

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

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

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

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

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

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

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

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

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

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

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

מכירים אותו ?

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

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

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

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

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

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

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

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

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

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

חבל על הזמן…

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

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

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

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

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

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

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

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

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

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

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

החסרונות של סקראם ע”פ 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, אבל הרעיון כמו שהוא איננו מספיק ולא הוטמע כמו שהוא כמעט בכלל. “סקראם בגדול” נשאר תחום של יועצים מסויימים שטוענים שיש להם תשובות, ואין קונצנזוס בנושא כלל.

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

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

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

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

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

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