The Three Agile Pillars

אתמול שאל אותי מנהל קבוצת פיתוח

אחרי תקופה שאני עובד עם האירגון שלו,

מה לדעתך הבעייה הכי חמורה שגורמת לנו לאחר בגרסאות❓

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

אז קבלו בתמצית את התורה המורכבת כולה על רגל אחת.

רגל אחת ושלושה עמודי תמך. 🙂

ה - Three Agile Pillars

שלושה תחומים נדרשים לטיפול, וקרוב לוודאי,

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

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

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

אוטומציה אפקטיבית מתקדמת היא גם כזו שמגנה על המוצר ולא מאפשרת להכניס אליו בגים מלכתחילה (Test before commit)

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

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

למעשה, במקום להכניס את הערך הגבוה בהתחלה ולקראת הסוף רק את ה" Nice to have " ככל שמספיקים,

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

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

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

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

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

באותה מידה שלושת התחומים הללו אם מפתחים אותם על בסיס קבוע:

1. אוטומציה מתפתחת לצד המוצר.

2. בקלוג מנוהל הייטב.

3. צוותי פיתוח מיומנים ופרואקטיביים.

הופכים את האירגון למכונה משומנת.

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

אחרי הכל יש באירגוני פיתוח לא מעט אנשים חכמים,

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

ואת זה אנחנו מאמנים אירגונים לסגל ולפתח,

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

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

ואם האירגון הוא אג'ילי הוא ודאי מאמץ לעצמו את הכלל הרביעי באג'ייל מניפסטו -

"אנחנו מעדיפים להגיב לשינויים,

יותר מאשר אנחנו רוצים להצמד לתכניות.

בעוד תכניות זה דבר מצויין כדי להערך ולהתארגן,

השינוי הוא המציאות ואנחנו מעדיפים להכיר במציאות"

אם אתם רוצים לדעת יותר על השיטה,

ואיך אתם יכולים להפוך את תהליכי הפיתוח שלכם לאפקטיביים יותר, אג'יליים יותר,

צרו קשר ונקיים פגישת ייעוץ אצלכם,

המומחיות והידע והנסיון עלינו,

הקפה עליכם.

#עצה_של_מאמן_אגייל_2021