Posts tagged ‘Scrum master’

להיות מוסמך או לא להיות מוסמך ?

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

image ככל שהזמן עובר, יותר ויותר אנשים מבקרים בצורות שונות את הרעיון של הסמכות שונות.
באופן אישי, אני חושב שיש תועלת בהסמכות כאלה ואחרות (רופאים, עורכי דין וכו’), אבל אופי ההסמכות הללו בד”כ מכיל בתוכו תנאים מקדימים רבים (כמו קבלת תואר אקדמאי), בעולם ההסמכות שלנו (Scrum) התנאי לקבלת הסמכה הוא מעבר קורס של יומיים ומבחן ל-CSM, מילוי טפסים שמוכיחים ניסיון ל-CSP, ועמידה בפני ועדה והוכחת ניסיון ל-CST.

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

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

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

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

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

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

clip_image002

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אלמנטים של סקראם…מה זה DONE ?

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

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

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

בואו נתבונן רגע בהגדרת DONE:

  • הקוד גמור
  • בדיקות גמורות
  • הפיצ’ר אושר ע”י מנהל המוצר.

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

  • הקוד גמור
  • נכתבו Unit tests והם רצים בהצלחה.
  • נכתבו Integration tests והם רצים בהצלחה.
  • הבדיקות התווספו לתשתית האוטומציה.
  • הפיצ’ר תועד (לפי הצורך).

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

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

האדם שאחראי להחליט האם המוצר או הפיצ’ר הוא DONE הוא מנהל המוצר, הוא אחראי לוודא שהצוות אכן עומד בקריטריונים המתבקשים, זה קורה בישיבת סוף הספרינט – Sprint review.

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

נ.ב. – התוספת של התמונות לפוסטים מפריעה? מוסיפה? לא משנה? – אנא תגובתכם.

זהו – אני סיימתי – …I am DONE

 

*מקור התמונה : http://www.flickr.com/photos/hawaii-mcgraths/2701705139/lightbox/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

נ.ב. – כן, זה בכוונה שהתייחסתי לסקראם מסטר בלשון נקבה, אני פשוט חושב שנדרשת אפליה מתקנת לנשים בתחום שלנו (את הרעיון לקחתי מ- Mike Cohnאשר בספריו בנושא מתייחס ל-Product owner בלשון נקבה)

dir="ltr"