לפעמים זה מענין רק בשביל הרכילות ולפעמים זה מענין כדי ללמוד ודעת מה להיזהר ומה כדאי לנסות. המפגש הקרוב של קבוצתינו היקרה Agile Practitioners IL  שיתקיים ביום ראשון הקרוב ה-4 למרץ 2012 יוקדש כולו לנושא הזה בדיוק, אחד אחרי השני יחלקו איתנו נציגים של חברת LivePerson שגם מארחים את המפגש, נציגים של חברת WebCollege ונציגים של חברת SAP את המשמעות של המלה אג׳יל עבורם.

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

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

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

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

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

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

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

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

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

תחילה נשאל מי הם ה״שחקנים״ שיכולים לעזור להגיע ליעד העסקי הזה:
1. לקוחות שכבר קונים בחנות – לקוחות קיימים.
2. מנהל החנות 
3. אנשים שמתדלקים בתחנת הדלק
4. אנשים שעוברים באיזור התחנה.
5. אנשים שגרים באיזור התחנה.

עבור כל ״שחקן״ נשאל איך הוא יכול לעזור להגביר את התנועה בחנות, למשל עבור אנשים שכבר קונים בחנות, הם יכולים לקדם את היעד ע״י:
1. לחזור ולקנות בתדירות גבוהה.
2.להפיץ את קיום החנות לחברים ומכרים.

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

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

לסיכום

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

אז למי שלא היה על כדור הארץ (או לפחות בלינקדאין או בטוויטר) בחודשים האחרונים כדאי שאספר: בימים שני ושלישי ה-30/31 לינואר שנת 2012 התקיים בפעם הראשונה כנס שענה לשם:

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

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

אז מה היה? או מה אני עשיתי בכנס?

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

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

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

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

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

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

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

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

לסיום – מיני רטרוספקטיבה אישית:

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

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

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

נתראה ב -Agile Practitioners 2013 ….

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מעניין למה?

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

בקורס סקראם שהעברתי לפני כשבועיים ובמסגרת הסבר על ה-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~