Posts tagged ‘Communication’

מכתב פתוח לדוד בוב

בוב היקר,

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

אתייחס כעת לעל אחת מהנקודות שהעלית:

1. חוסר בטכניקות טכניות – אתה צודק, וזה ידוע לרוב שסקראם, בניגוד למשל ל-XP אינו מציין באיזה טכניקות או שיטות יש להשתמש כשמפתחים תוכנה, ולטעמי לא סתם: לו היה סקראם מגדיר באיזה שיטות לעבוד כשמפתחים תוכנה הרי היה גורלו להפוך לא רלוונטי כעבור פרק זמן מסויים, וכידוע לנו, תחום התוכנה הוא דינאמי ומשתנה. כאשר צוותים היום בוחרים לעבוד בסקראם הם בד”כ משתמשים בשיטות כגון CI, Pair programming, TDD וכו’ מכיוון שאלה דברים שנכון להיום אנו יודעים שהם עובדים, אבל מה יהיה עוד 10 שנים, האם עדיין אותן שיטות יהיו רלוונטיות ? אז ממש כמו ה-Agile Manifesto שאתה מהיוזמים שלו, לא צוינו פרטים טכניים בכדי לשמר אותו לאורך זמן, כך גם סקראם, ואני רואה בכך יתרון.

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

3. מסכים בהחלט – לא מומלץ ואף גורם נזק בד”כ כשהסקראם מסטר הוא גם מנהל פרויקט. אבל זה לא חסרון של סקראם.

4. מסכים! מסכים! מסכים! אבל גם זה לא חסרון של סקראם אלא של הארגון שמפיץ אותו, היה נפלא לו היינו נפתרים מה-“Certified” לאלתר.

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

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

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

8. צוותים מרובים או “סקראם בגדול” היא באמת שאלה פתוחה ואני לא חושב שמישהו עדיין מצא אחת גלובאלית להתמודד עם השאלה, לטעמי האישי הרעיונות של Bas Vodde ו-Craig Larman הם טובים, אך גם הם לא מתאימים לכל מקום כמו כפפה ליד, הנושא של פיתוח בסדר גודל גדול הוא נושא כנראה סבוך מידי ואין פתרון אחד (ממש כמו התפיסה האג’ילית – One size does not fit all)

זוהי תשובתי מלאת ההערכה אלייך דוד בוב (Robert C Martin).

אלעד.

יצירתיות

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

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

clip_image002

אני מעוניין לחלוק איתכם רעיון שקיבלתי מ-Rachel Davies בכנס שהשתתפתי בו לאחרונה:
רייצ’ל מציעה (למען הסר ספק זה גם לא המצאה שלה) שיטה שהיא קוראת לה Gold cards או כרטיסי זהב.

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

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

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

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

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

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

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

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

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

איך זה מרגיש ?

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

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

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

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

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

אז איך זה מרגיש לעבוד בסקראם ?

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

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

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

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

במסגרת הספרים הרבים שנכתבו בנושא מוצעים לא מעט מודלים שייעודם הוא לסייע באנליזה של הדינאמיקה של צוות ולנסות למקד את הבעיות.
מבין המודלים המוכרים מאוד שעוסקים בשלבי התפתחות של צוות ישנם למשל את:
המודל של התפתחות צוות ע”פ ברוס טאקמן: Forming – Storming – Norming – Performing
המודל של ג’וזף פרלין: Burning – Cooking – Stagnating – Congealing – Solid

clip_image002אבל אני לא הולך לדבר על המודלים הללו, אני הולך להציג מודל נוסף, שונה קצת, של פטריק.מ. לנסיוני שנקרא: חמשת הליקויים של צוות או באנגלית – 5 dysfunctions of a team. המודל הזה מוצג בספר בעל אותו שם, הספר הוא קל מאוד לקריאה, וכתוב לא כספר לימודי אלא כסיפור על מנכ”ל שמגיע לחברה בקשיים, ומוצא שהבעיה של החברה למעשה מקורה בתפקוד של הצוות הבכיר של החברה.

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

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

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

3. חוסר מחויבות – lack of commitment – כאשר אנשים לא מרגישים שהייתה להם חלק בהחלטה מסוימת, או לא ניתנה במה מספקת לדעות שלהם, מצטבר תסכול, התסכול הזה מתבטא (לעיתים בצורה גלויה ולעיתים לא) בחוסר מחויבות, לשם המחשה, נניח שהמנהל שלכם מקבל החלטה ואין לכם שום אפשרות להשפיע עליה, סיכוי טוב שלא תרגישו באמת מחויבים להחלטה הזאת, תבצעו אותה כנראה (הוא בכל זאת המנהל) אבל רק לשם לצאת מידי חובה ולא מתוך מחויבות אמיתית. מחויבות היא מרכיב חיוני בתוך צוות, אני לא חושב שיש צורך להרחיב למה.
כשאין מחויבות אישית ו”קנייה” (buy-in) של המשימות יורד משמעותית הסיכוי להשגת המטרות והיעדים של הצוות. כאשר חברי הצוות לא מרגישים מחויבות לביצוע המשימות הם גם לא מרגישים אחריות להישגים של הצוות ובזה נוגע הליקוי הרביעי.

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

5. חוסר תשומת לב לתוצאות – Inattention to results – זהו הליקוי החמישי, המצב שבו חבר בצוות מעדיף את טובתו האישית יותר מטובת הצוות. אל תבינו לא נכון, אני לא מדבר על החיים האישיים, אני מדבר מצב שבו חברי הצוות מרוכזים יותר בלהדגיש את ההישגים האישיים שלהם ללא התחשבות בתוצאה הסופית. המצב הזה מאופיין בד”כ במצבים שבהם כל אחד בצוות בטוח שהוא עשה את הכל נכון ולמרות זאת הצוות לא משיג תוצאות (מנהל הפרויקט עשה עבודה נהדרת, זה המפתחים שעשו עבודה גרועה… וואלה?!).

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

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

פיתוח תוכנה רזה – Lean software development.

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

ליפנים יש תפיסת עולם מאוד ייחודית (ובעבר גם מהפכנית) בנוגע לתהליכי ייצור ופיתוח, התפיסה הזו הייתה גורם משפיע מאוד, בין השאר הגישה של הזו הייתה השראה למאמר של טקוצ’י וננקה (Hirotaka Takeuchi, Ikujiro Nonaka) שנקרא – The New New Product Development Game, המאמר הזה הוא זה שהתחיל את המהפכה, זה שגרם לשיטת הסקראם להתפתח, ונחשב ע”פ רוב ל”ניצוץ שהדליק את האש”.

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

clip_image002 בשנת 2003 פרסמו מרי וטום פופנדיק את הספרLean Software Development: An Agile Toolkit, הספר למעשה שופך אור על הנושא ומציג באופן פורמאלי אנלוגיה בין עולם הייצור והפיתוח הרזה לבין עולם פיתוח התוכנה, הספר מציע איך לתרגם את הערכים והתפיסות מעולם הפיתוחייצור הרזה לעולם פיתוח התוכנה, ואם יורשה לי, הוא עושה את זה בצורה יוצאת מין הכלל.

עקרונות העבודה בעולם ה-Lean עברו טרנספורמציה קלה לטובת התאמה לפיתוח תוכנה ואסקור אותם כעת:

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

עקרון 2 – לבנות את האיכות מבפנים – Build quality in:
המשמעות של לבנות את האיכות מבפנים היא להחליף תהליכים של איתור בעיות בדיעבד, לתהליכים שמונעים טעויות מראש,כבר כתבתי על כך פוסט ולכן לא ארחיב כעת.

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

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

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

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

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

נצחון בנקודות

קודם כל וידוי – הפוסט הזה נכתב בהשראת המצגת שהכנתי לפורום SD, שבו אני מרצה השבוע (26/11/2008).

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

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

השם המקובל לנקודות אלה נקרא story point והוא נגזר מהמונח user stories שהיא שיטה לתאר דרישות שבאופן פורמאלי משתמשים בה במתודולוגיה Extreme programming.

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

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

אבל מה ? מישהו יכול להסביר לי מה ההבדל בין משימה שגודלה 18 למשימה שגודלה 19 ? לי ברור (וניתן כמובן לחלוק על כך) שאין לנו יכולת, לכן אנו מניחים שככל שמשימה היא גדולה יותר, כך אי הוודאות בה גדול יותר. הגיוני. הפתרון המקובל הוא לא להשתמש בכל המספרים האפשריים, ולכן נהוג להשתמש בסדרות כגון חזקות של 2 או סדרת פיבונאצ’י (0,1,2,3,5,8,13,21).
דבר נוסף שיש לשים לב אליו, שקשה לנו מאוד להעריך דברים בסדרי גודל שונים, מה הגודל היחסי של זבוב לפיל ? או מה הגודל היחסי בין שינוי טקסט בכפתור לבין הוספת תמיכה באורקל ? קשה.
מה עושים ? מעריכים משימות בסדר גודל אחר, כלומר, אם אנו רואים שמשימה היא בסדר גודל גדול מידי מפרקים אותה לחלקים. איך? בפוסט אחר.
מקובל באג’יל שמשימה היא למעשה אוסף הפעולות שדרושות בכדי לפתח את הפיצ’ר, שזה כולל תיעוד, בדיקות,פיתוח וכו’, מכאן יוצא שבשביל להעריך את המשימה יש צורך בכל האנשים הקשורים לעמידה במשימה. אני קורא לאוסף האנשים הזה צוות.

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

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

ע”מ להעריך את המשימה בפועל אנחנו משתמשים בטכניקה שנקראת planning poker שעליה ארחיב בפוסט אחר, אולי אפילו הבא.

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

רבותי, ההיסטוריה חוזרת.

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

בשנת 1980 שודרה תוכנית ברשת NBC שנקראה
“אם יפן יכולה למה אנחנו לא” – “if Japan can… why cant we”,
בתוכנית בין השאר הוצג דמינג שטען שהבעיה הגדולה ביותר של המוצרים האמריקאים היא האיכות הנמוכה שלהם, האפקט של התוכנית הזאת היה כה משמעותי, שהוא גרם להתפרסמות של דמינג בגיל 80!!! וזאת למרות שהתוכנית שודרה רק פעם אחת. מאותו רגע ועד מותו (1993) דמינג נחשב לאדם שנמצא בחזית התנועה לשיפור האיכות.
למה אני מספר את זה ?
דמינג פרסם מאמרים רבים, בין השאר ישנו מאמר משנת 1982 עם סיכום ב-14 נקודות של העקרונות שלפיהם צריכה להתנהל חברה מסחרית, אותם עקרונות שהוא האמין בהם בשנות ה-50.
מבלי לדון בהן, אני אתרגם אותן כמיטב יכולתי בפוסט הזה, ואגיש לכם אותן כחומר למחשבה.

  1. יש להתמקד במטרות ארוכות הטווח של החברה, לא צריך להתמקד ברווח בטווח קצר, המטרה היא להמשיך להתקיים ולייצר מקומות עבודה.
  2. העולם משתנה, ומנהלים צריכים לשנות את צורת החשיבה בהתאם: עיכובים, טעויות, עובדים לא טובים ושירות גרוע לא מקובלים עוד.
  3. לא להסתמך על תהליכי בדיקות לזיהוי פגמים, תתחילו לבנות את האיכות בתוך המוצר תוך כדי ייצורו.
  4. אל תבחרו ספקים על בסיס תמחור בלבד, תמזערו הוצאות לטווח ארוך ע”י יצירת קשר ארוך-טווח עם הספקים, קשר שמבוסס על אמון ונאמנות.
  5. באופן המשכי וקבוע יש לעבוד על שיפור תהליך הייצור, שיפור אינו מאמץ חד פעמי, על כל פעילות במערכת להשתפר ע”מ לצמצם פעולות לא מועילות ולשפר את האיכות. כל הזמן.
  6. מיסוד ההכשרה. על המנהלים לדעת איך לבצע את העבודה עליה הם מפקחים, ולהיות מסוגלים לאמן עובדים, מנהלים גם זקוקים להכשרה ע”מ להבין את המערכת כולה.
  7. מיסוד מנהיגות. התפקיד של המנהלים הוא לסייע לאנשים לעשות עבודה טובה יותר, ולהסיר מכשולים שמפריעים לעובדים להשלים את המשימות שלהם בגאווה. הבזבוז הגדול ביותר באמריקה הוא אי השימוש ביכולתם של אנשים.
  8. למגר את הפחד. אנשים זקוקים להרגיש בטוחים ע”מ לבצע את עבדות כראוי, לעולם לא צריך להיות קונפליקט בין ביצוע הדבר הטוב ביותר לחברה, ועמידה בציפיות של האדם ממשימתו הנכחית.
  9. הסירו את החוצצים בין המחלקות. צרו צוותים מולטידיסיפלינארים כך שכולם יוכלו להבין את הפרספקטיבה זה של זה. אל תמעיטו בכוחם של צוותים ע”י תגמול עובדים על בסיס ביצועים אישיים.
  10. הפסיקו להשתמש בסיסמאות, תוכחה ושידול. זאת המערכת עצמה, ולא העובדים אשר מייצרת פגמים ופוגמת בפרודוקטיביות, סיסמאות לא ישנו את המערכת, בשביל זה יש מנהלים.
  11. הסירו מכסות אישיות לעובדים. זוהי צורה של ניהול ע”י פחד (Management by fear), נסו מנהיגות במקום.
  12. הסירו חוצצים ששודדים מהעובדים את זכותם לגאווה בעובדתם. הפסיקו להתייחס לעובדים לפי שעה כמו משאבים, הסירו דירוגים של הערכות ביצועים שנתיות לעובדים.
  13. תעודדו למידה ושיפור עצמי לכולם. עובדים והנהלה מלומדים, הם המפתח לעתיד.
  14. תפעלו למען השגת השינוי. הנהלה הבכירה חייבת להוביל את המאמץ באמצעות פעולות, ולא רק תמיכה ודיבורים.

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

המטבח הפתוח.

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

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

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

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

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

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

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

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

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

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

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

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

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

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