Posts in סקראם – Scrum

אז יש ראש צוות או אין ראש צוות?

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

יש או אין?

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

אם יש אז מי זה?

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

אם אין אז מה כן יש?

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

clip_image002

האם צריך מישהו במקום?

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

מה(מי) זה הסקראם מסטר הזה?

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

איך עושים את זה?

אה… שאלה טובה! ובכן מספר דברים חשובים:

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

וכעת, דבר המפרסם (דלגו לפסקה הבאה אם לא בא לכם על פרסומת):

כל מספר חודשים אנו עורכים סדנא ציבורית שעוסקת בנושאים הללו,שמה של הסדנא הוא "workshop Advanced Scrum master".
הסדנא הקרובה תיערך ב-30 לאפריל ונותרו עוד מספר מקומות אשמח לפגוש אתכם שם ולהמשיך את הדיון…

כמובטח תרגיל נחמד שאתם יכולים לערוך בצוות:

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

לולאה אינסופית

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

clip_image002פתיחה

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

איסוף נתונים:

בחרנו בשיטה של Good, Bad, Better, Best וכל אחד מהמנהלים רשם אירועים ודברים על פתקיות דביקות והדביק אותם בקטגוריה הרלוונטית, לאחר שכולם סיימו (למעשה לאחר שתם הזמן לחלק הזה) העלמתי את הקטגוריות המקוריות שביקשתי מהמשתתפים למיין את הפתקים לקבוצות לפי נושא, ולעשות זאת מבלי לדבר בכלל.
זה לקח כ-5 דקות ולבסוף היו לנו 8 קבוצות, הקבוצה הגדולה ביותר באופן משמעותי הייתה הקבוצה שהם הגדירו שקשורה למוטיבציה של חברי הצוותים.

ניתוח הנתונים:

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

תכנון של ניסוי:

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

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

סיכום:

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

מקור התמונה: http://www.flickr.com/photos/livenature/8064660509/

זה סקראם – זה לא

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

עליכם להחליט אם המשפט הכתוב הוא נכון או לא.

  1. סקראם היא מתודולוגיה מלאה שמספקת תשובות והגדרות לכל האספקטים הקשורים לניהול מוצר מבוסס תוכנה.
  2. סקראם היא שיטת עבודה שבנויה בצורה כזו שכאשר תוציאו לפועל את האלמנטים המוגדרים בה הבעיות הקיימות בארגון ובתהליך ייחשפו באופן מואץ מהרגיל.
  3. סקראם היא שיטת עבדוה שמאפשרת לצוותי הפיתוח להכתיב לכל הארגון איך לעבוד.
  4. התוצרים והתפקידים המוגדרים בסקראם הם מדויקים ואין להוסיף עליהם שום אלמנט אחר או תפקיד נוסף.
  5. בסקראם חייבים להשתמש ב"יוזר סטוריז" ובהערכת משימות בנקודות.
  6. צוותים מנוהלים עצמאית הם חלק בלתי נפרד מסקראם.
  7. שימוש בגאנט למעקב אחרי התקדמות אסור בפרויקט סקראם.
  8. בסקראם לא מומלץ לתכנן או להתכונן מעבר לספרינט אחד.
  9. הבדיקות בסקראם חייבות להתבצע בתוך הספרינט \ סקראם דורש שלכל מוצר תהיה הגדרת Done כל מה שהגדרה זו כוללת יש לבצע במהלך הספרינט.
  10. צוות הסקראם רשאי לשחרר גירסא רק בסוף ספרינט.

image

אז נכון או לא?

  1. לא – סקראם זו שיטת עבודה המשמשת לפיתוח מוצר תוכנה ומגדירה צורת עבודה שעוזרת לקיים שקיפות, למידה ושיפור מתמיד
  2. כן – ולא כמו שנהוג לחשוב שזו שיטת עבודה שנועדה לפתור בעיות שכיחות הקשורות לפיתוח מוצרי מבוסס תוכנה.
  3. לא – סקראם זו שיטת עבודה מסודרת מאוד הדורשת משמעת עצמית גבוהה הן מהמנהלים והן מהצוותים ואין לאף גוף יותר כח מהאחרים.
  4. לא ולא -  סקראם מגדירה את המינימום ההכרחי (לטעמה) בנוגע לתפקידים, טקסים ותוצרים שיש לכלול בפרויקט תוכנה ע"מ שתוכל להתקיים למידה ושיפור מתמיד.
  5. שוב לא – את הבקלוג של המוצר והספרינט ניתן להגדיר בכל צורה שהארגון מוצא כיעילה.
  6. כן – צוותים מנוהלים עצמאית הם אכן חלק בלתי נפרד מסקראם ולא ניתן לקבל את התוצאות המקסימליות מסקראם כשבוחרים לעבוד עם צוותים שמנוהלים ע"י ר"צ "קלאסי" שמחלק את המשימות בין חברי הצוות ומייצג את הצוות כלפי חוץ.
  7. טעות – ניתן להוסיף לסקראם כל אלמנט שרק רוצים כל עוד משמרים את המינימום המוגדר.
  8. לא נכון – אין המלצה כזאת. התנהלות של רוב הפרויקטים מצריכה הסתכלות מעבר לספרינט הבא, וכך גם פרויקטים שמשתמשים בסקראם. לבחור לא להסתכל מעבר לספרינט הבא מתברר בד”כ כטעות.
  9. שוב לא נכון – סקראם דורש שלכל מוצר תהיה הגדרת Done כל מה שהגדרה זו כוללת יש לבצע במהלך הספרינט, אכן למען הקטנת סיכונים והגברת יכולת החיזוי של ההתקדמות יש לכלול מקסימום אלמנטים בתוך הגדרת ה-DONE.
  10. טעות נפוצנ מאוד -  סקראם לא מגדיר כל קשר בין שחרור גרסאות לספרינטים.

 

מקור התמונה: http://www.flickr.com/photos/60766987@N00/2710464400/

חמש טעויות נפוצות

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

גרומינג רק לספרינט הבא

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

לא לתעד בכללimage

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

להשוות צוותים ע״י שימוש בוולוסיטי

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

תכנון מפורט מידיי

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

אי הקפדה על הגדרת ה-Done

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

 

מקור התמונה : http://www.flickr.com/photos/squidish/410698265/in/set-72157594528501650

רטרו קפה

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

photo

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

שלב ראשון – פתיחה

בפתיחה נעשה שימוש בפרוטוקול ה-Check-in מתוך הפרוטוקולים של ג’ים ומישל מקרתי הכינוי של הפרוטוקול הזה הוא Sad\Mad\Glad\Afraid או בעברית שמח\עצוב\כועס\חושש, זו בעצם טכניקה לייצר סיטואציה בעלת פתיחות מוגברת ע”י חשיפת רגשות, כל משתתף למעשה מביע דבר אחד או יותר ע”י שימוש ברגשות הללו, לדוגמא: אני שמח שלמדתי על הרטרו קפה, אני כועס שלא חשבתי על זה בעצמי. מניסיוני שימוש בפרוטוקול הזה לפתוח רטרוספקטיבה מוכיח את עצמו כיעיל מאוד.

שלב שני – רטרו קפה

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

שלב שלישי – סגירה

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

יש שאלות? הצעות לשיפור?

בדרך לסקראם…

 

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

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

לכבד את התפקידים ומבנה האחריות הנכחי

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

להפוך את העבודה לויזואלית

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

לנהל את הזרימה

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

ליישם לולאות פידבק

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

להפוך את התהליך למפורש

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

להגביל את כמות העבודה – Limit WIP

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

מה בכל זאת שונה?

לכבד את התפקידים?

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

הגבלת כמות העבודה?

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

שיפור שיתופי תוך שימוש במודלים:

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

סיכום הדברים:

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

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

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

מקור התמונות:
http://www.flickr.com/photos/18091975@N00/2963986468/
http://www.flickr.com/photos/adam_jones/3793602841/

מסטר צוואר בקבוק

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

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

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

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

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

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

מסטר צוואר בקבוק.

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

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

נ.ב. את השם הגיתי באנגלית – בה הוא נשמע טוב יותר: Bottleneck Master.

*מקור התמונה: http://commons.wikimedia.org/wiki/File:Bottlenecks.jpg

ספרינט ייצוב – תנצב”ה

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

למה אני מתכוון?

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

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

בשביל לשנות תפיסה צריך קודם להבין שיש בעיה.

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

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

בקיצור: זה רע.

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

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

איך?

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

מקור התמונה:http://www.flickr.com/photos/lenore-m/4052125926/

 

היי אתה, בוא רגע לפה

 

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

תגיד לי אתה, כן אתה שם בפינה, כן כן אתה – התוכניתן עם האוזניות:

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

אתה. אתה יודע מי אתה?

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

הבחירה היא שלך:

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

 אתה הבנת את זה?

 

 

 

מקור התמונות:
http://www.flickr.com/photos/a2gemma/1448178195/
http://www.flickr.com/photos/infomofo/154877897/

כמה זמן זה מפה לקהיר?

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

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

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

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

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

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

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

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

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

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

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

אם בכל זאת אתם צריכים לתכנן לטיוח ארוך אז תמתינו לפוסט הבא.

*מקור התמונה : http://www.flickr.com/photos/arancidamoeba/3415301321/