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

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

יש או אין?

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

אם יש אז מי זה?

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

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

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

clip_image002

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

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

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

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

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

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

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

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

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

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

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

נמצאה התרופה לבינוניות ארגונית

Uncategorized

April 8, 2014

לא תאמינו אבל הצלחנו!

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

גם אתם צריכים מנג׳מול!

managemol

מנג׳מול הוא תוצאה של מחקר של 12 שנים ואושר על ידי ה-FDA ה-CIA וה-CNN.

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

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

יש להיוועץ ברופא לפני השימוש.

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

במידה והתופעות נמשכות יש להפסיק לקחת את התרופה ולגשת למאמן אג׳ילי ;)

הבנתם?

אורח לרגע רואה כל פגע

Uncategorized

December 17, 2013

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

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

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

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

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

כיצד יכול לסייע תהליך מונחה?

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

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

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

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

הבעה בעל פה

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

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

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

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

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

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

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

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

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

*מקור התמונה – http://www.flickr.com/photos/wicker-furniture/8555333439/in/photostream/

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

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

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

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