Posts in עבודת צוות

עקרון מספר 5

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

הלא רשום בעקרון מספר 5 באג׳ייל מניפסטו:

Build projects around motivated individuals
Give them the environment and support they need
and trust them to get the job done

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

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

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

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

איך אנחנו מורידים את המוטבציה והמחויבות?

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

האם אפשר גם אחרת?

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

אשמח לשמוע תגובות או אפילו לדבר איתכם באופן אישי על הנושא, אז אל תהססו ליצור קשר.
http://www.practical-agile.com/contactus

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

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

יש או אין?

תלוי את מיד שואלים, אני אומר יש. 
בואו נתבונן רגע בביטוי ראש צוות שנגזר מהביטוי הלועזי 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/

אולי תחליטו כבר?

"גם לא להחליט זו החלטה" כך היא אמרה לי, וכמה שהיא צודקת….

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

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

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

אז איך מקבלים החלטה?

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

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

פרוטוקול החלטה (מבית היוצר של הזוג מק’ארתי)

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

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

בר החלטה

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

פרמטרים להחלטה

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

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

מקור התמונות:
http://www.flickr.com/photos/inafrenzy/5787848646/
http://www.flickr.com/photos/sarahreido/3120877348/

רטרו קפה

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

photo

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

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

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

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

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

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

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

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

פיתוח עסקי

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

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

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

נקודה 1: שפות התכנות מתרחקות מהחומרה ומתקרבות לעולם העסקי.

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

נקודה 2: כל מפתח הוא מנהל מוצר

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

נקודה 3: אם העולם העסקי לא מעניין, אולי אתה לא בעבודה הנכונה

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

נקודה 4: התהליכים ותפיסות העבודה דוחפות לכיוון.

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

רגע רגע. אנחנו בני אדם, וככאלה אנחנו שונים זה מזה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך?

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

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

 

בואו נדבר על… צוותי פיצ׳רים

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

אבל מה זה כן?

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

אז מה הבעיה? למה לא כולם עושים את זה?

הנה כמה סיבות שאני שומע:
  • בצוות כזה אין חלוקה שווה של העומס בין המפתחים – הגיוני, הרי יש פיצ׳רים שדורשים יותר חלק אפליקטיבי ויש כאלה שדורשים יותר פיתוח תשתיתי, יש כאלה שדורישם יותר בדיקות וכאלה שזקוקים בעיקר לקונפיגרציה. אבל מתוך הנחה שרוב הפיצר׳ים דורשים התייחסות בכל החלקים, מישהו מוכן בבקשה לקום ולהסביר לי איך הבעיה הזאת נפתרת כשהאנשים המעורבים יושבים בצוותים שונים? להיפך עבודה בצורה כזו תציף את הבעיה של חוסר איזון בין ההתמחויות ולא תחביא אותה בתוך מבנה ארגוני מסובך.
  • אנשי תוכנה לא יודעים לבדוק כמו שצריך – בואו לא נכנס לוויכוח אם זה נכון או לא ונשאל האם זה בכלל רלוונטי, אם למשל מומחה הבדיקות שלנו מגדיר את הבדיקות שצריכות להתבצע והמתכנת מוציא אותן לפועל, או אם מומחה הבדיקות כותב את הרמה העליונה של האוטומציה (ATDD) והתוכניתן כותב את ה-fixtures.
  • איש ה-QA לא יכול לכתוב קוד – באמת? הפעם דווקא בא לי להתווכח, יש לא מעט אנשי בדיקות שכן יודעים, או שלא יודעים ורוצים ללמוד, אני לא מציע לכם לתת לאיש בדיקות לגעת ללא עזרה באיזורים רגישים בקוד, בדיוק כמו שלא הייתי מציע לכם לאפשר את זה למי שרק סיים אוניברסיטה, אבל בהחלט אפשר להיעזר גם באזני בדיקות בכדי לכתוב קוד במידה והם מעוניינים בכך. גם אם איש הבדיקות לא רוצה לכתוב קוד ישנן עוד משימות שיש לבצע, כתיבת מסמכים, ייצוג הצוות בישיבות, התקנות, אדמיניסטרציה ועוד.
  • תוכניתן A הוא מומחה בשפה מסוימת – אז מה? תוכניתנים לא מחליפים שפות? לא לומדים דברים חדשים? מישהו שיודע שפת C לא יכול לעזור קצת עם ג׳אווה או עם #C? אני גם חושב שזה אפילו כדאי, ראוי ואפילו חובה להרחיב אופקים וללמוד דברים חדשים.
ישנן עוד לא מעט סיבות ״לא לעבוד בצוותי פיצ׳ר״, ואתם מוזמנים להוסיף כאלה בתגובות.
לפני שאני מסיים את הפוסט הזה (והולך לישון – כבר 2 בלילה!!!) אני רוצה לתת סיבה אחת למה כן כדאי, יש הרבה אבל אני רוצה להתמקד באחת:
אין צורך באינטגרציה
בתור מי שמפתח תוכנה כבר לא מעט שנים אחת הבעיות הכי כואבות שאני מכיר היא אינטגרציה, השלב המקולל הזה שאני מתחיל אותו כשגם אני וגם האדם שמולי בטוחים שסיימנו את העבודה ורק נשארו שעה שעתיים לחבר את החלקים, אותו שלב מקולל שדורש ששנינו נהיה פנויים, אותו שלב מקולל שבו מגלים ששום דבר לא באמת עובד, אותו שלב מקולל שבו ממש כשהיגענו לקטע קריטי הוא צריך ללכת לישיבת צוות או משהו דומה… בצוותי פיצ׳ר זה לא קיים! בצוות כזה כל האינטגרציה מתבצעת בתוך אותה יחידה קטנה שנקראת צוות. אותו צוות שיכול להרשות לעצמו לבצע כל הזמן אינטגרציה. איזה כיף זה.
אשמח לשמוע מה לכם יש להגיד בנושא.
מקור התמונה : http://www.flickr.com/photos/35168673@N03/5796777205/in/photostream/

בואו נדבר על… רטרוספקטיבות

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

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

לפני שאני צולל אני רוצה לחלוק אתכם את ה- Retrospective prime directive שניסח  Norm Kerth:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand

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

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

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

  1. פתיחה
  2. איסוף נתונים
  3. יצירת רעיונות
  4. קביעת משימות לביצוע.

פתיחה

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

איסוף מידע

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

יצירת רעיונות

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

קביעת משימות לביצוע

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

טיפים לביצוע יעיל של רטרוספקטיבה:

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

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

*מקור התמונות :
http://www.flickr.com/photos/linkey/2752696822/
http://www.flickr.com/photos/chodhound/4489875318/sizes/z/in/photostream/