"מתי זה יהיה מוכן?" - שאלה שאפשר לענות עליה בנתון

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

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

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

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

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

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

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

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