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

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

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

אז הנה ההזדמנות שלכם!

בכנס APIL 2014  שייערך בסוף ינואר אנו מתכוונים להציג תערוכה של לוחות Scrum/Kanban/Wallboard

אם אתם רוצים להציג את הלוח שלכם אנא שילחו מייל אלי amitye@gmail.com ובקרו בקישור הבא על מנת לראות את שאר הפרטים קישור ללינקדאין.

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

אפשר לקבל הערכה?

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

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

כשזה קרה לי, עמדו בפני שתי ברירות:
 האפשרות הראשונה, לבצע הערכת עובדים וקביעת יעדים כמו בעבר. מה שאומר שבדף היעדים יופיעו משפטים כגון "מהנדס X אמור לפתח תוכנה Y עד לתאריך Z" או "מהנדס X אמור לתמוך בפרוייקט W ולהביא אותו לייצור עם K באגים". מה שיקרה בעקבות כך הוא שבשנה הבאה בעת הערכות העובד אנו נעבור על הדף ונגלה שתוכנה Y בכלל נדחתה לשנה הבאה, ושהתוכן שלה השתנה ב 180 מעלות לעומת הדרישה המקורית או שפרוייקט W בכלל בוטל והוחלף בפרוייקט אחר. או ששום דבר לא השתנה אבל כחלק מהתהליך האג'ילי מהנדס אחר בכלל עבד בפועל על המשימה.
האפשרות השניה, לחשוב על יעדים מסוג חדש. יעדים שייתמכו בתהליך האג'ילי. כאלו שלא יישתנו או יישברו עם כל שינוי בפרוייקט זה או אחר.

אתם מנחשים באיזו אפשרות בחרתי?

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

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

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

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

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

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

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

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

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

יש לכם שיטה אחרת? רעיונות לעוד יעדים אג'יליים? אשמח לשמוע.

גבולות הגזרה של Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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