אג'יל זה לא מילה גסה

אם אתם רוצים להרשם לכנס Agile Practitioners 2012 ועוד לא עשיתם כך, אז הנה משהו שאולי יעזור לכם להשתכנע, בדף הזה יש הנחה מיוחדת של 15% על המחיר המלא של היום הראשון ו-10% על המחיר של היום השני.

אל תספרו לאף אחד שאני שלחתי אתכם

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

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

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

עד כאן איך לא.איך כן?

תתחילו בבית (תיקון*: תתחילו בעצמכם במקום העבודה)

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

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

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

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

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

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

ביום ראשון ה-4 לדצמבר בשעה 18:00 אשמח לפגוש את כווולללכככםםם בעוד מפגש של קבוצת Agile Practitioners IL.

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

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

אה.. אל תשכחו להרשם לקבוצה בלינקדאין.

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

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

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

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

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

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

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

מעניין למה?

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

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

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

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

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

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

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

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

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

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

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

נתחיל בשורה התחתונה:
במקום שבו אין מקום לכישלון אין יצירתיות.

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

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

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

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

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

מה עם ההנהלה? מכירים את המשפט “Failure is not an option”? הוא משוייך במקור לבקר טיסה של אפולו 13 (למרות שלא ממש נאמר בצורה הזו), שם באמת לא היתה אפשרות להיכשל, אבל מכאן ועד להשתמש במשפט הזה חדשות לבקרים ע”י מנהלים שונים יש מרחק גדול.
אני לא חושב שמנהל אחראי צריך להשתמש במשפט הזה, מנהלים גם נכשלים לפעמים (לא את\ה, אחרים) מנהלים נכשלים בלהתיישר עם היעדים העסקיים, מנהלים נכשלים בלייצר סביבה שבה מותר להכשל, מנהלים נכשלים לייצר סביבה שבה אנשים הם בעלי מוטיבציה גבוהה, מנהלים נכשלים בעמידה ביעדים העסקיים שלהם (מעניין מי הציב את היעדים האלה בכלל?) אז אנחנו רואים שגם מנהלים נכשלים. 
הופ, כישלון הוא כן אופציה.

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

מה אם המנהל לא מאפשר כישלון? אני מציע שתשלחו לו קישור לבלוג שלי ASAP…

תיכשלו! תיכשלו מהר. תיכשלו הרבה. תיכשלו לעיתים קרובות.

לסיום פנינה מאת תומס אדיסון:
I have not failed.  I’ve just found 10,000 ways that won’t work. 
~Thomas Edison~

ב-6 לנובמבר זה שוב קורה.
מפגש ררביעי של קבוצת Agile practitioners IL והפעם במשרדי SAP ברעננה.

והפעם בחלק הראשון הרצאה של ליאור פרידמן על פיתוח אג’ילי בצוות אחד מתוך פרויקט, או במילים אחרות : Agile in Waterfall. ובחלק השני יהיה דיון פתוח בנושא.

עוד מידע על הפגישה והרשמה נמצאים כאן.

בתאריך 25-26 לאוקטובר אני פותח בשיתוף עם פסיפיק תוכנה קורס סקראם ציבורי לקהל הרחב.

אני מזמין אתכם לקחת חלק בקורס וללמוד ביחד איתי ועם עוד משתתפים על הדברים הבאים:
- ההיסטוריה של סקראם ואג’יל.
- המניפסט האג’ילי.
-  מה זה סקראם?
- איך עובדים בסקראם?
- התפקידים:
     *הצוות
     *הסקראם מסטר
     *מנהל המוצר – Product owner.
- הטקסים והישיבות:
     *תכנון ספרינט
     *הישיבה היומית
     *סיום הספרינט
     *רטרוספקטיבה.
- התוצרים: ספרינט בקלוג, ניהול דרישות תוך שימוש בבקלוג מוצר.
- תהליך הפיתוח בסקראם: שיטת פיתוח אג’יליות.
- תכנון פרויקט בסקראם.
- הערכת מאמצים בעולם אג’ילי.
- עבודת צוות: צוותים מנוהלים עצמאית.
- סקראם בארגונים\מוצרים מרובי צוותים.
- ועוד…

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

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

כל משתתפי הקורס יקבלו את חוברת הקורס הכוללת את כל החומר הנלמד.

עדיין ניתן לקבל הנחת רישום מוקדם עד ה-10 לאוקטובר. צרו איתי קשר למימוש ההנחה.

פרטים נוספים והרשמה ניתן למצוא בקישור הבא: http://pacificsoft.co.il/course.asp?p=664&s=1210

ממוצע הציון שהתקבל בקורס האחרון שהעברתי הוא : 4.4 מתוך 5.

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

קוראים יקרים

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

שנה טובה!

אלעד סופר – מאמן אג’ילי