Posts in Agile – אג’יל

בדרך לסקראם…

 

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

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

לכבד את התפקידים ומבנה האחריות הנכחי

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

להפוך את העבודה לויזואלית

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

לנהל את הזרימה

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

ליישם לולאות פידבק

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

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

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

להגביל את כמות העבודה – Limit WIP

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

מה בכל זאת שונה?

לכבד את התפקידים?

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

הגבלת כמות העבודה?

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

שיפור שיתופי תוך שימוש במודלים:

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

סיכום הדברים:

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

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

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

מקור התמונות:
http://www.flickr.com/photos/18091975@N00/2963986468/
http://www.flickr.com/photos/adam_jones/3793602841/

מה ההבדל בין טבח ביתי לשף?

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

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

בוא נתחיל עם אלה שלא:

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

יש בטח עוד אבל אלה לטעמי הדברים העיקריים שאו שנולדים/גדלים/מחונכים איתם או שלא.

8170834332_9e4da61829[1]בואו נמשיך עם אלה שניתנות לגישור:

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

הבנתם? אז בואו נחזור לקרקע.

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

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

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

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

מקור התמונות:
http://simania.co.il/bookimages/covers0/8957.jpg
http://www.flickr.com/photos/19714819@N00/8170834332

שש פעמים אותו הדבר?

3912450799_ef0ea00945[1] כמה פעמים יצא לכם לחזור על אותה פעולה מספר פעמים? נגיד 6.

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

נשמע נורא לא?
אז זהו שלא. כמעט בכל אחת מהפעולות שביצעתי מספר פעמים היה ערך (חוץ אולי מהאוהל – אבל זה סתם טרטור) איפה הערך?

הערך הוא בלימוד.

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

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

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

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

בסדנת ה- Test Automation Code Retreat יתרגלו המשתתפים בניית אוטומציה לאפליקציה 6 פעמים, ב-6 גישות שונות וכלים שונים. אם זה התחום שלכם אז גם אם אתם מתחילים וגם אם אתם כבר מנוסים, לדעתי זו תהיה אחת ההשקעות הכי טובות שעשיתם בשנים האחרונות

מקור התמונה: http://www.flickr.com/photos/imuttoo/3912450799

מסטר צוואר בקבוק

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

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

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

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

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

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

מסטר צוואר בקבוק.

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

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

נ.ב. את השם הגיתי באנגלית – בה הוא נשמע טוב יותר: Bottleneck Master.

*מקור התמונה: http://commons.wikimedia.org/wiki/File:Bottlenecks.jpg

ספרינט ייצוב – תנצב”ה

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

למה אני מתכוון?

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

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

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

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

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

בקיצור: זה רע.

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

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

איך?

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

מקור התמונה:http://www.flickr.com/photos/lenore-m/4052125926/

 

היי אתה, בוא רגע לפה

 

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

תגיד לי אתה, כן אתה שם בפינה, כן כן אתה – התוכניתן עם האוזניות:

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

אתה. אתה יודע מי אתה?

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

הבחירה היא שלך:

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

 אתה הבנת את זה?

 

 

 

מקור התמונות:
http://www.flickr.com/photos/a2gemma/1448178195/
http://www.flickr.com/photos/infomofo/154877897/

להצלחה הרבה אבות, הכשלון הוא אמפירי

כמעט כל התהליכים האג׳ילים מבוססים על מנגנונים של שיפור מתמיד, תקראו לזה inspect and adapt, תקראו לזה PDCA, שיפור מתמיד.
בשביל להשתפר צריך ללמוד ובשביל ללמוד כמובן שצריך גם לטעות אבל לטעות זה לא חכמה גדולה,
פיתחנו פיצ׳ר מסוים, הלקוחות לא אהבו אותו, מה למדנו? אם כל מה שלמדנו זה שהפיצ׳ר לא טוב אז כנראה שנפלנו קורבנות לאחד מדפוסי ההתנהגות הבעייתיים ביותר שאני מזהה בארגונים שקוראים לעצמם ארגונים לומדים.
אני אומר את זה בצורה הברורה ביותר: למידה היא לא תירוץ טוב לכישלון, בטח ובטח אם כל מה שלמדנו הוא על עוד משהו שלא עובד.
אם נכשלתם אחרי חצי שנה שבה ישבו 5 מפתחים, שני בודקים, 1 מנהל מוצר ו-150 חבילות של עוגיות עבאדי. אז זה לא למידה, לפחות אני לא רואה את זה ככה.
החכמה בכישלון היא שהוא יהיה מהיר ומדויק, הוא צריך לתת תשובה בדיוק במה נכשלנו ותוך פרק זמן קצר ככל שניתן. מה מתוך אינספור האלמנטים שאנחנו מוציאים לפועל כל יום לא עובד טוב או נכשל? איזה שינוי צריך לנבוע מתוך הניסיון שלנו?

כשלון אמפירי

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

איך מודדים?

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

להיכשל מהר

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

אבל יש בעיה…

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

מקור התמונה: http://www.fotopedia.com/items/flickr-3422530465

כמה זמן זה מפה לקהיר?

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

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

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

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

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

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

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

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

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

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

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

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

*מקור התמונה : http://www.flickr.com/photos/arancidamoeba/3415301321/

בואו נדבר על… צוותי פיצ׳רים

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

אבל מה זה כן?

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

אז מה הבעיה? למה לא כולם עושים את זה?

הנה כמה סיבות שאני שומע:
  • בצוות כזה אין חלוקה שווה של העומס בין המפתחים – הגיוני, הרי יש פיצ׳רים שדורשים יותר חלק אפליקטיבי ויש כאלה שדורשים יותר פיתוח תשתיתי, יש כאלה שדורישם יותר בדיקות וכאלה שזקוקים בעיקר לקונפיגרציה. אבל מתוך הנחה שרוב הפיצר׳ים דורשים התייחסות בכל החלקים, מישהו מוכן בבקשה לקום ולהסביר לי איך הבעיה הזאת נפתרת כשהאנשים המעורבים יושבים בצוותים שונים? להיפך עבודה בצורה כזו תציף את הבעיה של חוסר איזון בין ההתמחויות ולא תחביא אותה בתוך מבנה ארגוני מסובך.
  • אנשי תוכנה לא יודעים לבדוק כמו שצריך – בואו לא נכנס לוויכוח אם זה נכון או לא ונשאל האם זה בכלל רלוונטי, אם למשל מומחה הבדיקות שלנו מגדיר את הבדיקות שצריכות להתבצע והמתכנת מוציא אותן לפועל, או אם מומחה הבדיקות כותב את הרמה העליונה של האוטומציה (ATDD) והתוכניתן כותב את ה-fixtures.
  • איש ה-QA לא יכול לכתוב קוד – באמת? הפעם דווקא בא לי להתווכח, יש לא מעט אנשי בדיקות שכן יודעים, או שלא יודעים ורוצים ללמוד, אני לא מציע לכם לתת לאיש בדיקות לגעת ללא עזרה באיזורים רגישים בקוד, בדיוק כמו שלא הייתי מציע לכם לאפשר את זה למי שרק סיים אוניברסיטה, אבל בהחלט אפשר להיעזר גם באזני בדיקות בכדי לכתוב קוד במידה והם מעוניינים בכך. גם אם איש הבדיקות לא רוצה לכתוב קוד ישנן עוד משימות שיש לבצע, כתיבת מסמכים, ייצוג הצוות בישיבות, התקנות, אדמיניסטרציה ועוד.
  • תוכניתן A הוא מומחה בשפה מסוימת – אז מה? תוכניתנים לא מחליפים שפות? לא לומדים דברים חדשים? מישהו שיודע שפת C לא יכול לעזור קצת עם ג׳אווה או עם #C? אני גם חושב שזה אפילו כדאי, ראוי ואפילו חובה להרחיב אופקים וללמוד דברים חדשים.
ישנן עוד לא מעט סיבות ״לא לעבוד בצוותי פיצ׳ר״, ואתם מוזמנים להוסיף כאלה בתגובות.
לפני שאני מסיים את הפוסט הזה (והולך לישון – כבר 2 בלילה!!!) אני רוצה לתת סיבה אחת למה כן כדאי, יש הרבה אבל אני רוצה להתמקד באחת:
אין צורך באינטגרציה
בתור מי שמפתח תוכנה כבר לא מעט שנים אחת הבעיות הכי כואבות שאני מכיר היא אינטגרציה, השלב המקולל הזה שאני מתחיל אותו כשגם אני וגם האדם שמולי בטוחים שסיימנו את העבודה ורק נשארו שעה שעתיים לחבר את החלקים, אותו שלב מקולל שדורש ששנינו נהיה פנויים, אותו שלב מקולל שבו מגלים ששום דבר לא באמת עובד, אותו שלב מקולל שבו ממש כשהיגענו לקטע קריטי הוא צריך ללכת לישיבת צוות או משהו דומה… בצוותי פיצ׳ר זה לא קיים! בצוות כזה כל האינטגרציה מתבצעת בתוך אותה יחידה קטנה שנקראת צוות. אותו צוות שיכול להרשות לעצמו לבצע כל הזמן אינטגרציה. איזה כיף זה.
אשמח לשמוע מה לכם יש להגיד בנושא.
מקור התמונה : http://www.flickr.com/photos/35168673@N03/5796777205/in/photostream/

להגיע לפסגה

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

אני בהחלט חושב שהנקודה שיובל העלה בהחלט שווה התייחסות.

להטמעת סקראם יש לטעמי שלושה שלבים עיקריים:

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

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

אם עשיתם רק את שלב הלימוד…

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

אם המשכתם לשלב ההטמעה…

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

אבל אם אתם בשלב הניסויים…

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

המלצתי היא:

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

 

מקור התמונות:
 http://www.flickr.com/photos/jinglesthepirate/2885330439/
http://www.flickr.com/photos/tuchodi/4901707346/