Danko on Scrumhttp://agileisrael.org/cs/blogs/danko/atom.aspxCommunity Server2008-04-15T08:15:00Zהיכולת לצאת משטח הנינוחותhttp://agileisrael.org/cs/blogs/danko/archive/2008/11/20/2150.aspx2008-11-20T18:15:00Z2008-11-20T18:15:00Z<p> (התפרסם בדיילי מיילי היום http://www.pc.co.il/_DailyMaily/ItemClean.asp?ArticleID=23152&Vol=794&SearchParam=&CategoryID=72)<br /></p><table class="bodyclean" style="width:600px;height:1723px;" align="center" cellpadding="0" cellspacing="0"><tr><td colspan="4" class="articletitle" style="font-size:18px;">היכולת לצאת משטח הנינוחות</td>
</tr>
<tr><td><div class="DaliyAuthor">דני (דנקו) קובץ', ממייסדי AgileSparks</div></td></tr>
<tr>
<td class="DailyBody"><table style="margin-right:10px;margin-bottom:20px;" align="left" cellpadding="0" cellspacing="0"><tr><td align="left"><img src="http://www.pc.co.il/_Uploads/23152danko.jpg" style="margin-right:5px;" alt="דני (דנקו) קובץ', ממייסדי AgileSparks" width="140" align="left" border="0" /></td></tr><tr><td style="padding-right:10px;" align="right"><div class="MainImgTitle" style="width:140px;">דני (דנקו) קובץ', ממייסדי AgileSparks</div></td></tr></table><div id="ctlBody"><p>כדי
לבצע שינוי בחיים, עלינו קודם כל להבין מה מצבנו האמיתי, מה יהיה המצב
המקווה בסוף התהליך, והבנה שהתהליך עצמו יזעזע את שטח הנינוחות שלנו
(Comfort Zone). הדבר נכון גם במעבר לשיטת ניהול פרויקטים חדשה, ולשיטה
האג'ילית בפרט, בה יש דגש חזק על המימד האנושי (להבדיל, למשל, ממעבר לכלי
CRM חדש).</p>
<p>האנשים והחברה (ובייחוד ההנהלה) צריכים קודם להבין מה המצב האמיתי של
הארגון, ללא ה-"שקרים הלבנים" שנפוצים בארגון, לבדוק כמה פעמים הארגון
עומד בהבטחותיו ללוחות הזמנים, כמה זמן מוקצה להשקעה בעובדים, כמה זמן
"מושקע" בישיבות ועוד. לאחר מכן, צריך להבין האם המצב סביר או דורש שינוי,
כי זהו הדלק שייתן לארגון כוח בהמשך. לאחר מכן, על הארגון לבחון איזו שיטה
עדיפה על ידי בדיקה האם השיטה החדשה תיתן מענה אמיתי לבעיות הקריטיות
שנמצאו.</p>
<p>הדבר החשוב ביותר, הוא להבין שבשעת המעבר הארגון סופג זעזוע בשיטת
הניהול שלו ועליו לרכוש מיומנויות חדשות בכל מיני תחומים. הדוגמה החביבה
עלי היא ילד חדש במשפחה. על כל המשפחה להבין את המציאות החדשה ולפתח את
המיומנויות החדשות הנגזרות מהמצב החדש (הלבשה בבוקר, שכן שעת התחלת בית
הספר לאחות הגדולה לא השתנתה, מקלחות וארוחת ערב בלילה, פניות לכלל
הילדים, שכן שיעורי הבית ממשיכים להגיע ואפילו מתגברים וכו').</p>
<p>במעבר לסקראם, שבו הדגש הוא על עבודת הצוות וגיבושו לצוות מיומן ומגובש
מוכוון משימות (יחידת עילית), הצוות חווה קושי רב בתחילה וללא שום דיבידנד
מיידי. זהו הזמן שבו צריך לשלוף את הרשימה שתיארה את המצב הקודם ואת
הרשימה של המצב המקווה של סוף התהליך ולהיעזר בסבלנות ובמשמעת (הדיבידנדים
בדרך!).</p>
<p>מכיוון שכל שינוי מייצר את הנוגדן הטבעי האנושי: פחד, אנשים נוטים
לעטוף אותו בכל מיני תירוצים שונים ומשונים שמתארים מדוע ההטמעה נידונה
מראש לכישלון. קצרה יריעה מלהכיל את כל הרשימה, אז הנה אוסף התירוצים
הנפוצים ביותר שאנחנו שומעים:<br /><br />- "בתיאוריה זה נהדר אבל פרקטית זה
לא עובד". בתרגום: "המצב כל כך סבוך בארגון שאין לי מושג מאיפה להתחיל את
התהליך שנראה לי שמאוד יעזור לארגון". בכל ההטמעות שאני הייתי חשוף אליהן,
אם זה בארץ או בעולם, אם שאני השתתפתי או שתוקשר לי על ידי מדריכים
מוסמכים (של האיגוד הבינלאומי) אחרים, הארגון התייעל באופן משמעותי. </p>
<p>- "אצל אחרים זה בטוח יעבוד אבל אצלנו זה לא יעבוד". בדומה לראשון,
קיימת הבנה שהשיטה יעילה ואפילו עובדת פרקטית, אבל הכרת האנשים
והמתודולוגיות המיושמות בארגון ימנעו מכך לקרות כי אין לארגון היכולת
להשתנות אפילו בשם היעילות.<br /><br />- "אצלנו הצוותים מבוזרים, לכן זה לא
יעבוד". קיימת נטייה לחשוב שאם נבצע מיקור חוץ למדינה בה המשכורות נמוכות
משמעותית, נוכל לחסוך הרבה כסף. אמת הדבר שעיקר ההוצאות בענף ההיי-טק הוא
משכורות העובדים אולם בדרך כלל נוטים לשכוח את הבדלי התרבות, הזמן
והתקשורת הקלוקלת. לפעמים מקצינים את הדבר על ידי הוצאת תת צוות (QA,
למשל) מעבר לים וציפייה שהצוות כולו יתפקד בצורה יעילה. לסקראם אין
פתרונות קסם והדבר יוקצן ביתר שאת לכל אלה שממענים לראות זאת אבל המטמיע
(בייחוד אם הוא מדריך סקראם מוסמך מטעם האיגוד הבינלאומי שמביא איתו את
הניסיון והידע של האיגוד) ידע לתת כלים למענה מיידי ויעיל כמו גם ארוך
טווח לשיפור המצב.<br /><br />- "אין סיכוי בעולם שנצליח להוציא גרסה כל 3
שבועות" – לפעמים הארגון חולה בתסמונת הסטודנט ("דחה את הבעיה בתקווה שהיא
תיעלם"). זה מתבטא בהרבה מאוד דברים, בין השאר בחוסר יכולת לקמפל את כל
הפרויקט. כשאני שואל לפשר הדבר, אני מקבל תשובות הזויות ותמוהות, כמו
"אנחנו לא יכולים לקמפל כרגע, לקמפל לוקח שבועיים וחבל על הזמן" וכד'.
בסקראם אנחנו מקמפלים את כל הפרוייקט כל יום (ואפילו עם כל שינוי קוד
מאושר). נכון, בתחילה זה לוקח זמן, אבל מהר מאוד מגיעים למצב הזה ואז
קורים דברים נפלאים. אם קיימת בעיה, היא מיד (עד יום) מתגלה. דומה הדבר
לעבודת תחזוק בית. אם לא תתחזק אותו בצורה קבועה, כשיגיעו אורחים תצטרף
לעבוד שעות. ראיתי פרויקטים מסובכים מאוד ומורכבים מאוד. כולם לבסוף הגיעו
למצב שהם מתקמפלים תוך לילה (ולפעמים זה לא פשוט!) ואז הם לא הבינו איך הם
עבדו לפני זה.<br /><br />- "10% מההטמעות נכשלות – למה להתחיל אם יש סיכוי להיכשל?". הפחד מכישלון הוא לפעמים המגן הכי טוב...<br /><br />-
"אנחנו חברה של מאות אנשים ולכן אג'ייל לא יוכל להתאים לנו". אחת הטעויות
הנפוצות היא שסקראם מתאים רק לחברות קטנות או לצוותים קטנים. כמובן שהדבר
לא נכון. סקראם מתאים לחברות גדולות כקטנות, אפילו בארץ יש חברות גדולות
של מאות אנשים שעוברות לסקראם. ראיתי כבר חברות גדולות שעברו הטמעה מוצלחת
וחברות קטנות שההטמעה נכשלה. סקראם אינו תלוי בגודל החברה אלא במחויבות
ההנהלה לשינוי.<br /><br />- "אנחנו עובדים בפרויקטים קבועי תכולה (Fixed
Price Project) ולכן אג'ייל לא יעבוד". אם זה היה נכון, היה לוקח לסקראם
חצי שנה להיעלם. סקראם מתאים לסוגי פרויקטים מגוונים כמו גם לפרויקטים
קבועי תכולה. ההבדל הוא שבסקראם ניתן לדעת כמעט מיד האם צריך להוסיף זמן
ו/או אנשים ולא צריך לחכות כמעט לסוף הגרסה כדי להפתיע את הלקוח בחוסר
המוכנות של החברה בזמן המוסכם. אחת הבעיות השכיחות בעולם הפיתוח הוא
שמנהלים משחקים בלהיות אלוהים והם חושבים שהם יכולים לקבוע הם את התכולה,
הן את הזמן ואת את כמות האנשים שצריך. המציאות טופחת על פניהם פעם אחר פעם
שכן אי אפשר לקבוע את שלושת הדברים הנ"ל אלא רק שניים מהם בכל זמן נתון,
כשהשלישי נגזר. כמו כן פיתוח תוכנה הינו שילוב של יצירתיות ותקשורת ולכן
יש להתמודד איתו בהתאם כאשר נדרשים למתן לוחות זמנים. בעזרת סקראם ניתן
לרכוש את המיומנות הזו אבל אי אפשר לעשות קסמים. אם צוות של שלושה אנשים
יכול לשתות 100 כוסות מים ב-20 דקות, לא יעזור המנהל המוכשר ביותר שיבוא
ויגיד שאותו צוות צריך לשתות 100 כוסות ב-5 דקות רק בגלל שהובטח הדבר
ללקוח. </p>
<p>ונסיים באוסף התירוצים שמצחיקים אותי יותר מהמכל שכן לא רק שהם אינם
קשורים לסקראם, אלא הפתרון נראה מובן מאליו אבל אף אחד לא מטפל בהם והם
בבחינת גזרה משמיים. הנה הדוגמאות המובילות. למעט השמטת פרטים מזהים כמו
שם החברה, הציטוטים מדוייקים:</p>
<p>- "אצלנו המסמכים היו ותמיד יהיו מסובכים, מורכבים ובלתי ברורים שאין סיכוי להטמיע אג'ייל".<br /><br />- "למנהל המוצר אסור לדבר ישירות מול הצוותים כי הם לא אנשים שלו ופעם אחרונה שזה קרה, היה בירור עם סמנכ"ל הפיתוח".<br /><br />-
"אני חייב לשקר למנהל המוצר לגבי לוחות הזמנים. הוא יודע את זה והוא מקצץ
את ההערכות שאני נותן לו. אתה מציע להגיד לו את האמת וזה לא ילך".<br /><br />- "אין לנו אפשרות לתעדף את פרטי הגרסה - אצלנו הכול חשוב".<br /><br />- "ברור לי שהאנשים לא יספיקו את כל התכולה אבל אני חייב לשקר להם אחרת הם לא יספיקו אפילו חצי ממה שאנחנו רוצים".<br /><br />- "לעולם לא נוכל להוציא גרסה כל שלושה שבועות כי רק על ישיבות אנחנו מבזבזים יומיים כל שבוע".<br /><br />- "ההטמעה תיכשל כי להנהלה לא איכפת איך אנחנו עובדים העיקר שנעמוד בלוחות הזמנים והתכולה (הבלתי הגיוניים) שהם התחייבו בשמנו".<br /><br />- "אצלנו המנהלים צריכים לדעת כל דבר קטן לכן לעבוד באג'ייל שהאחריות ניתנת לצוות לא תעבוד כשיטה".<br /><br />- "נוח לי עם זה שלא כל אחד יודע מה אני עושה, עכשיו אתה מציע שכולם ידעו על מה אני עובד ומה קצב ההתקדמות שלי?".<br /><br />-
"לעבוד באג'ייל זה לעבוד בצוות ואין טעם לעבוד אצלנו בצוותים כי כל אחד
בצוות יודע דבר אחר ואף אחד לא יכול להחליף אותו או לעזור לו וככה זה
ישאר". </p>
<p>והדוגמה ההזויה ביותר:</p>
<p>- "אנחנו אמנם לא עומדים בלוחות הזמנים, באיכות ובתכולה אבל לאף אחד לא
איכפת אז פשוט אין לנו טעם לעבור לאג'ייל או לכל שיטה חדשה אחרת".</p></div></td>
</tr>
<tr>
<td style="padding-top:8px;"><br /></td>
</tr>
<tr class="dont_print">
<td style="padding-top:10px;">
var arrInputs = new Array();
var field = new fieldValidate("ResponseAuthor", 0, "שם", 1);
arrInputs[0] = field;
field = new fieldValidate("ResponseTitle", 0, "כותרת התגובה", 1);
arrInputs[1] = field;
field = new fieldValidate("AuthorEmail", 9, "דואר אלקטרוני", 0);
arrInputs[2] = field;
var nSelectedID = -1;
function fnShowAddRes() {
document.getElementById("trAddRes").style.display = "block";
document.frmAddResponse.ResponseTitle.value="";
document.frmAddResponse.ResponseBody.value="";
document.frmAddResponse.ResponseAuthor.focus();
}
function fncHideAddRes() {
document.getElementById("trAddRes").style.display = "none";
}
function openResponseDiv(ID) {
if (!isNaN(ID)) {
nSelectedID = ID;
var objResTr = document.getElementById("res_tr_" + ID);
var objResDiv = document.getElementById("res_div_" + ID);
if (objResTr.style.display == "block")
objResTr.style.display = "none";
else {
if (objResDiv.innerHTML == "") {
var oXML = document.getElementById("ctlResponseXml");
oXML.src="http://www.pc.co.il/_Responses/GetResponse.asp?id=" + ID;
}
else
objResTr.style.display = "block";
}
}
}
function fnSetResponse(oXML) {
document.getElementById("res_tr_" + nSelectedID).style.display = "block";
try {
document.getElementById("res_div_" + nSelectedID).innerHTML = oXML.documentElement.text;;
document.getElementById("res_div_" + nSelectedID).beenFetched = true;
} catch(e) {
}
}
<table cellpadding="0" cellspacing="0">
<tr style="padding:4px;">
<td colspan="2">
<table cellpadding="0" cellspacing="0">
<tr>
<td><br /></td></tr></table></td></tr></table></td></tr></table><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=2150" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxתפקידו של מנהל המוצר בעולם האג'ילי - הכל מסתכם בתשואהhttp://agileisrael.org/cs/blogs/danko/archive/2008/10/11/2112.aspx2008-10-11T13:37:00Z2008-10-11T13:37:00Z<p> </p><div class="content"><p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;"><span style="font-family:'Arial','sans-serif';"></span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">אחד התפקידים המרכזיים בעולם ה
</span><span style="font-family:'Calibri','sans-serif';">Agile</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>, ואולי החשוב ביותר מכולם, הוא מנהל המוצר (</span><span style="font-family:'Calibri','sans-serif';">PRODUCT OWNER – PO</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>), שהינו </span><span style="font-family:'Arial','sans-serif';">האדם הוא הישות (הצוות) שאחראי למוצר
ועיקר המשקל והאמון של התהליך נשענים עליו. איגוד ה </span><span style="font-family:'Arial','sans-serif';">Scrum Alliance</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span> הכיר בחשיבות תפקיד ה </span><span style="font-family:'Arial','sans-serif';">PO</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>, והגדיר
הסמכה וקורס ייחודיים לתפקיד – </span><span style="font-family:'Arial','sans-serif';">Certified Scrum Product
Owner</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>.</span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">אם אתם חושבים כרגע לעצמכם: "מה ההבדל,
ה </span><span style="font-family:'Arial','sans-serif';">PO</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span> אחראי על המוצר גם בשיטה הקלאסית", אתגרו את עצמכם עם המשך תוכן
הכתבה ושאלו את עצמכם, האם באמת זה מה שקורה בארגון שלכם.</span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';"> </span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">ניתן לפצל את תפקידו של ה </span><span style="font-family:'Arial','sans-serif';">PO</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span> <span>לפעילויות הבאות:</span></span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<b><span style="font-family:'Arial','sans-serif';"> </span></b>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<b><span style="font-family:'Arial','sans-serif';">הגדרת תוכן
המוצר</span></b>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">מנהל המוצר אחראי לתוכן שלו. הוא יודע
מה נכון לשלב בגרסא הבאה, ולא פחות חשוב, מה לא לשלב בגרסא. משפט נפוץ אצל מנהלי
גרסא מהדור הקודם: "הכול חשוב ואין טעם להוציא את הגרסא עם פחות!". מצער למדי שכל
פעם מחדש, המציאות טופחת על פניהם כרעם ביום בהיר ועם הגעת יום שחרור הגרסא היא לא
כוללת את כל התוכן ה"נדרש" וזאת למרות שהצוותים עבדו במלוא המרץ ואז, הפלא ופלא,
הגרסא יוצאת עם תכולה מקוצצת...</span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';"> </span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<b><span style="font-family:'Arial','sans-serif';">אחריות על התשואה אל מול ההשקעה
(</span></b><b><span style="font-family:'Arial','sans-serif';">Return On
Investment</span></b><span></span><b><span style="font-family:'Arial','sans-serif';"><span></span>)</span></b>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">מנהל המוצר אחראי על המוצר כולו ולכן גם
על כך שהוא יהיה רווחי. מנהל מוצר שלא נמדד על התשואה, הינו מנהל מוצר שפועל על פי
דעתו הפרטית והרגשית. "מה שאתה לא יכול למדוד, אתה לא יכול לנהל" אמר פיטר דרוקר,
אבי הניהול המודרני, והכלל הפשוט הזה עובד להפליא גם כאן. על מנהל המוצר להימדד על
פי החזר ההשקעה של המוצר, רק כך הוא ידע מה עדיף להכניס לגרסא, מה כדאי להחסיר, את
התיזמון למכלול הגרסאות, קריאת השוק בצורה נכונה ועוד.</span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';"> </span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<b><span style="font-family:'Arial','sans-serif';">תיעדוף נכון של הפריטים שמהווים
את הגרסא כולה</span></b>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">על מנהל המוצר להבין את המוצר לעומקו
כמו גם את רצון השוק. רק מנהל מוצר שידע את התיעדוף הנכון של הפריטים המהווים את
הגרסא כולה, יוכל לייצר גרסא רווחית. חלוקת הגרסא לפרטים, מחצינה סיכונים ותלויות
כמו גם גורמת להבנה יותר טובה של המוצר. תיעדוף נכון יגרום לצוות לעבוד על הדברים
החשובים יותר קודם. זהו יתרון עצום שכן בעולם ה </span><span style="font-family:'Arial','sans-serif';">Agile</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>, הצוות
משחרר גרסא כל פרק זמן קצר והחשיבות של "הדברים החשובים תחילה" גורמת לגרסא להיות
תמיד המעודכנת ביותר. נוסף על כך, בעידן של כמות שינויים עצומה במהלך גרסא, עדיף
להתעמת עם הדברים החשובים ולא לדחות אותם לסוף (תסמונת הסטודנט) כשאין זמן וכולם
לחוצים (ואז מעגלים פינות על ידי ויתור על איכות) או "נזכרים" שהחלק הכי חשוב בגרסא
עוד לא טופל. </span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';"> </span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<b><span style="font-family:'Arial','sans-serif';">החלטה על תאריך שחרור
הגרסא</span></b>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">רק מנהל המוצר (מכוון שהוא נמדד עליו)
יכול להבין מתי האיזון בין דרישות השוק לגרסא חדשה לבין התוכן הקיים של הגרסא.
כזכור, בעולם ה </span><span style="font-family:'Arial','sans-serif';">Agile</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span> <span>כל
פרק זמן קצר הצוות מוציא גרסא פוטנציאלית (</span></span><span style="font-family:'Arial','sans-serif';">Potentially Shippable
Release</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>) ולכן מנהל המוצר
מודע בכל רגע נתון (איטרציה) מה כבר קיים בגרסא ומה לא (ואין הכוונה למה "אמור"
להיות בגרסא אחרי שיתחילו קומפילציה, אחרי שבוע יסיימו ואז ה</span><span style="font-family:'Arial','sans-serif';">QA</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span> יתחיל.
בעולם ה </span><span style="font-family:'Arial','sans-serif';">Agile</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>, גרסא
מוכנה היא גרסא שעברה כבר את כל השלבים הללו והצוות מבצע זאת תוך כדי האיטרציה כך
שבסוף האיטרציה המוצר כבר עובד לאחר בדיקה). לאור כל זאת, מנהל המוצר הוא היישות
היחידה שיודעת על התאריך הנכון להוצאת הגרסא.</span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';"> </span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<b><span style="font-family:'Arial','sans-serif';">התאמה, כוונון ותיעדוף של
הפיצ'רים עבור כל איטרציה</span></b>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">בתיאוריה הכל אמור לעבוד אבל המציאות
היא הרבה יותר חזקה. פיצ'רים שהוגדרו כחשובים ביותר הופכים לפחות חשובים עקב דרישות
שוק החדשות, מתחרים עם פתרונות חדשים ועוד. בנוסף, פיצ'רים שהוגדרו היטב בהתחלת
איטרציה נראים אחרת לגמרי כאשר הם מיושמים ("זה בדיוק מה שביקשתי אבל כשאני רואה את
זה משתלב עם ה</span><span style="font-family:'Arial','sans-serif';">GUI</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span> החדש אני
רוצה לשנות את הסדר/הצבע/תוכן"). כאן מתבטא תפקידו של מנהל המוצר ביתר שאת. עליו
להיות מוכוון מטרה ועם זאת גמיש מחשבתית לשנות אותם תוך כדי תנועה.
</span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';"> </span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<b><span style="font-family:'Arial','sans-serif';">אישור או דחיית פריטי
הגרסא</span></b>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">מנהל המוצר הוא היישות הסופית שיכולה
לדחות או לאשר פריטי גרסא מוכנים. בהתחלת איטרציה הצוות ביחד עם מנהל המוצר מסכימים
לא רק על מה יוצג ויוכנס לגרסא שתצא באיטרציה הבאה אלא גם על הגדרת "עשוי" עבור כל
אחד מהפרטים (</span><span style="font-family:'Arial','sans-serif';">Definition of Done</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>). האיטרציה מתחילה והצוות מתחיל לעבוד. להבדיל ממתודולוגיות פיתוח
קלאסיות, הצוות, בעולם ה </span><span style="font-family:'Arial','sans-serif';">Agile</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>, מורכב
מאוסף האנשים היעיל והרלוונטי ביותר לאור המשימות הנדרשות לאיטרציה. דוגמא לצוות
</span><span style="font-family:'Arial','sans-serif';">Agile</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span> <span>יכולה להיות 4 אנשי פיתוח, איש </span></span><span style="font-family:'Arial','sans-serif';">DBA</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>, שני אנשי </span><span style="font-family:'Arial','sans-serif';">QA</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span> ואיש
</span><span style="font-family:'Arial','sans-serif';">GUI</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span>.</span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';"> </span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';"> </span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';">מנהל המוצר יכול להיות אדם אחד שזהו
תפקידו בארגון, או צוות של אנשים אשר כל אחד מהם אחראי על חלק אחד בפרוייקט וביחד
הם אחראים על הפרוייקט כולו. כך או כך, חשוב והכרחי שהם יוכלו לתעדף נכונה את פרטי
הפרוייקט כלפי הצוות. בכל רגע נתון, ובייחוד לפני כל תחילת איטרציה, הצוות צריך
לדעת לא רק מה תוכן הגרסא אלא גם את התיעדוף של כל אחד מהפרטים שכן אין הוא מסוגל
לבצע את כולם, ולכן הצורה היעילה ביותר היא לעבוד על פי התיעדוף שמשתנה מאיטרציה
לאיטרציה. מנהל מוצר שלא עושה זאת, שמחצין לצוות ש"הכל חשוב באותה מידה" וממאן
לתעדף, גורם לחוסר יעילות משווע. אם הצוותים בעולם ה </span><span style="font-family:'Arial','sans-serif';">Agile</span><span></span><span style="font-family:'Arial','sans-serif';"><span></span> משולים
ליחידות עילית הנעות בשטח (הפרויקט), מנהל המוצר הוא הגוף המספק את המטרות. יחידות
עילית ללא מטרות מוגדרות ומתועדפות, יעשה ככל יכולתו (הרבה) אבל ללא הכוונה, דבר
שיגרום להפסד. על מנהל המוצר לספק את כל הנזכר לעיל ורק אז יחידות העילית תוכלנה
למצות את הפוטנציל שלהן שכן כל ה"חגיגה" הזו היא בשביל מנהל המוצר שאחראי לתשואה
המקסימלית של המוצר ולהצלחת החברה.</span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-size:11pt;font-family:'Arial','sans-serif';"> המאמר יתפרסם בדיילי מיילי בשבוע הבא וכמו כן ב<a href="http://www.agilesparks.com/node/131">אתר של החברה</a> <br />
</span>
</p>
<p class="MsoNormal" dir="rtl" style="direction:rtl;unicode-bidi:embed;text-align:justify;">
<span style="font-family:'Arial','sans-serif';"> </span>
</p>
</div><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=2112" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxקורס סקראם מאסטר בעבריתhttp://agileisrael.org/cs/blogs/danko/archive/2008/08/22/2056.aspx2008-08-22T21:40:00Z2008-08-22T21:40:00Z<p> </p><p dir="rtl">
<span style="font-size:xx-large;"><span style="font-size:x-large;"><span><b>קורס סקראם מאסטר בעברית!</b></span></span></span>
</p>
<p>
<span><b> </b></span>
</p>
<p>
<span style="font-size:large;">
I am happy to announce on the <span><b>first Hebrew CSM </b></span>(Certify Scrum Master) class that will be given on September 14-15 by ... me :-)</span><span style="font-size:large;"></span>
</p>
<p>
<span style="font-size:large;">
For formal details, please refer to the following link: <a href="http://www.scrumalliance.org/courses/3058-certified-scrummaster" title="September CSM class">http://www.scrumalliance.org/courses/3058-certified-scrummaster</a></span>
</p>
<p>
<span style="font-size:large;">Should you want to attend, please let me know</span></p><p><span style="font-size:large;">Danko</span></p><p>Danko@AgileSparks.com</p><p>Danny.Kovatch@Gmail.com <br /></p><p> <br /></p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=2056" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxI am a CST (Certified Scrum Trainer) !http://agileisrael.org/cs/blogs/danko/archive/2008/08/10/i-am-a-cst-certified-scrum-trainer.aspx2008-08-11T03:32:00Z2008-08-11T03:32:00Z<p>Hello all, </p>
<p> The Scrum alliance has just approved my CST request and I am a CST</p>
<p> It will be formal by next week</p>
<p>This means Course Scrum master in Hebrew</p>
<p>For the first time</p>
<p>:-)</p>
<p>Read all about it in <a href="http://www.agilesparks.com/">www.AgileSparks.com</a></p>
<p>ANI</p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=2041" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxסקראם מסטר נמדד בחסרונוhttp://agileisrael.org/cs/blogs/danko/archive/2008/06/13/1814.aspx2008-06-13T14:36:00Z2008-06-13T14:36:00Z<p>אם אתם רוצים לדעת כמה הצוות עצמאי, מוכוון משימות ומגובש</p>
<p>ו<strong>אתם</strong> זה יכול להיות הצוות עצמו, הסקראם מסטר, סמנכל הפיתוח או כל אדם בארגון</p>
<p>פשוט נסו יום אחד שהסקראם מסטר לא יגיע לישיבת הסקראם היומית</p>
<p>בהפתעה או לא בהפתעה</p>
<p>אם אילו האמירות</p>
<p><strong>אה, אתה לא מגיע מחר כלומר אין ישיבה</strong></p>
<p><strong>איזה כייף מחר דנקו לא מגיע אז לא צריך לעשות ישיבת סקראם</strong></p>
<p><strong>אז מה נעשה בלעדייך, אין טעם לעשות את הישיבה</strong></p>
<p><strong>אוף, עוד פעם תהיה ישיבה של שעה כמו פעם קודמת</strong></p>
<p><strong>שוב יפריעו לנו אנשים מבחוץ</strong></p>
<p>אז סימן שיש לכם עוד דרך ארוכה</p>
<p>אבל אם אלו האמירות</p>
<p><strong>טוב, דנקו לא הגיע אבל בוא נתחיל </strong></p>
<p><strong>אתה לא בא מחר? אוקי, תגיד לנו אם אתה רוצה שנקשר אותך טלפונית או לא</strong></p>
<p>אתם לקראת סוף ההתחלה בהבנת רוח הסקראם</p>
<p> </p>
<p>לסקראם מסטר יש שני תפקידים עיקריים, כמו להורה, לשמור ולייתר</p>
<p>לשמור על הצוות, מהצוות, מעצמו ומכל יתר הנשמות הטובות בארגון שיודעות לתת עצות מצויינות בהיעדר המחוייבות</p>
<p>לנסות לייתר את עצמו ובכך להשקיע בצוות שיהיה עצמאי ולטפח אותו על ידי מתן כלים במציאת פתרונות ולא במתן פתרונות</p>
<p>וכל זאת תוך שמירה שהצוות לא יעשה שטויות</p>
<p>היכולת של סקראם מסטר לעודד מצויינות, יוזמה וחוסר פחד מעשיית טעויות יביאו לא רק את הצוות לגבהים חדשים אלא גם את הסקראם מסטר עצמו</p>
<p> </p>
<p>בהצלחה</p>
<p> </p>
<p>דנקו</p>
<p> </p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1814" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxבעית החיתוליםhttp://agileisrael.org/cs/blogs/danko/archive/2008/06/13/1811.aspx2008-06-13T11:10:00Z2008-06-13T11:10:00Z<p>השבוע נשאלתי בפעם המי יודע כמה את שאלת החיתולים </p>
<p>זה התחיל בזה ששאלו אותי מי מחליט איזו משימה לעשות</p>
<p>כמו שאתם יודעים, בערך תשעים אחוז מהפעמים התשובה לשאלת <strong>מי</strong> בסקראם היא <strong>הצוות</strong></p>
<p>גם כאן התשובה היא כי הצוות מחליט איזו משימה כל אחד מחברי הצוות יעשה</p>
<p>ואנשי צוות מתקדמים גם יודעים שלא צריך להחליט על זה מראש אפילו</p>
<p>ואז שוב היגענו לשאלה <strong>אבל אם אף איש צוות לא רוצה לקחת את המשימה הזו אז הצוות נתקע וצריך מנהל שיחליט</strong></p>
<p>התשובה כמובן היא <strong>לא ולא</strong></p>
<p>אז הנה לכם האנלוגייה, כמו שאתם יודעים להחליף חיתול היא אחת המשימות הפחות נעימות </p>
<p>מה יקרה אם אף אחד מההורים לא ירצה להחליף חיתול, האם צריך מישהו מלמעלה שיבוא לכל בית אב ויחליט בשביל הזוג</p>
<p>זה כמובן לא קורה כי בגידול ילדים זוג ההורים מעצם היותם הורים התחייב כצוות הורים על גידול הילד</p>
<p>וזה כולל כמובן משימות מדהימות, נהדרות, נחמדות וגם לא נעימות</p>
<p>צוות שמגיע למצב שאף איש צוות לא רוצה לעשות את המשימה שצריך לעשות על פי התיעדוף של רשימת הצבירה כנראה עוד לא הגיע למצב שהוא מחוייב למכלול המשימות </p>
<p>ואז הייתי שואל, האם הם באמת צוות או שהם רק אסופה של אנשים עם משימות אינדיבידואליות</p>
<p>צוות שהוא מוכוון משימה ומחוייב לפרוייקט לא יגיע למצב שאף אחד לא רוצה לעשות משימה כזו או אחרת</p>
<p>אבל מה בכל שאת עושים כשזה קורה? קודם כל אני ממליץ לשקף את זה לצוות ואז לבקש ממנו לפתור את הבעייה האמיתית של מחוייבות הצוות שכן זוהי כנראה הבעייה האמיתית</p>
<p>אם ניתן לפתור את הבעיה הזו, אז גם בעיית החיתולים תיפתר ואם לא, אין טעם להמשיך במתווה הנוכחי של הצוות שכן חוסר יכולת להחליט ביחד על משימה היא רק סיפטום לצרות הרבה יותר גדולות שיתבטאו בחוסר מחוייבות כללית לפרוייקט, איכות נמוכה של קוד ובסבירות גבוהה איחור כללי של הפרוייקט</p>
<p>דנקו</p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1811" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspx שאלות מיילדות, שבע הלמותhttp://agileisrael.org/cs/blogs/danko/archive/2008/06/07/1786.aspx2008-06-07T12:01:00Z2008-06-07T12:01:00Z<p>אחד מהנושאים העיקריים שאני מעביר בקורס הוא תפקידו של הסקראם מסטר</p>
<p>וכחלק מתפקידו אני מדגיש שעדיף שהוא ימטבץ את האנשים ולא לפתור להם את הבעיות</p>
<p>שיתן להם כלים לפתרונות על פני קיצור זמן הפתרונות על ידי מתן פתרון בעצמו</p>
<p>בקיצור, כל מי שהוא הורה מבין מה שאני אומר</p>
<p>ואכן, להיות סקראם מסטר זה מאוד דומה בלהיות הורה בהרבה אספקים</p>
<p>אחד מהכלים שאני נותן הוא הכלי שקראתי לו <strong>שבע הלמות</strong> שהגדרתי אותו בתור היכולת למצוא את הבעיה האמיתית</p>
<p>איש צוות: יש לי בעיה ואי אפשר לפתור אותה</p>
<p>סקראם מסטר: למה</p>
<p>איש צוות: כי אני צריך שלושה סרברים ואי אפשר להשיג אותם</p>
<p>סקראם מסטר: למה</p>
<p>איש צוות: כי יוסי, המנהל האחראי על הסרברים נמצא בחול והוא לא שם אף מחליף</p>
<p>סקראם מסטר: למה</p>
<p>איש צוות: כי פעם קודמת מישהו לקח החלטה שלא מצאה חן בעיניו ומאז הוא היחיד שלוקח החלטות כאלו</p>
<p>סקראם מסטר: אהההה, עכשיו אני מבין את הבעיה האמיתית שלנו, אמון</p>
<p> </p>
<p>לאחרונה נפגשתי עם <a class="" href="http://agileisrael.org/cs/controlpanel/blogs/ereztatcher@gmail.com">ארז טצ'ר</a>, מי שהיה מנכ"ל אינטרביט ועכשיו קוצ'ר</p>
<p>אחרי שיחה קצרה גילינו כל כך הרבה דברים דומים בין סקראם וקוצ'ינג</p>
<p>כשסיפרתי לו על <strong>שבע הלמות</strong> הוא אמר לי שקוראים לזה<strong> שאלות מיילדות</strong></p>
<p> איך אהבתי את השם הזה! כל כך מתאים! פשוט מדהים</p>
<p>מכוון שזה שם <strong>ה ר ב ה</strong> יותר טוב, אני מתכוון להשתמש בשם הזה מעתה ואילך</p>
<p> בהצלחה לכולם עם השאלות המיילדות, הם לעיתים מעצבנות אבל למי שאמיץ מספיק, הם מגלות את הבעיות האמיתיות</p>
<p>מי יתן ויותר מנהלים ישתמשו בשאלות מיילדות ולא במתן פתרונות אד הוקיות</p>
<p>דנקו</p>
<p> </p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1786" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxThe pictures from PMI conference and the presentationhttp://agileisrael.org/cs/blogs/danko/archive/2008/06/07/the-pictures-from-pmi-conference-and-the-presentation.aspx2008-06-07T11:43:00Z2008-06-07T11:43:00Z<p>הנה לינקים לתמונות של הכנס</p>
<p><a href="http://www.itpics.co.il/ThePeople/2008/PMI_28.5.08_cd3-WWW.html">http://www.itpics.co.il/ThePeople/2008/PMI_28.5.08_cd3-WWW.html</a></p>
<p><a href="http://www.itpics.co.il/ThePeople/2008/PMI_28.5.08_cd2-WWW.html">http://www.itpics.co.il/ThePeople/2008/PMI_28.5.08_cd2-WWW.html</a></p>
<p><a href="http://www.itpics.co.il/ThePeople/2008/PMI_28.5.08_cd1-WWW.html">http://www.itpics.co.il/ThePeople/2008/PMI_28.5.08_cd1-WWW.html</a></p>
<p> </p>
<p>וכאן תוכלו למצוא את המצגת שלי</p>
<p><a href="http://rapidshare.com/files/120729669/PMI_Danny_Kovatch_Transition_to_Agile.ppt.html">http://rapidshare.com/files/120729669/PMI_Danny_Kovatch_Transition_to_Agile.ppt.html</a></p>
<p><img title="Danko Danny Kovatch Scrum PMI conference" style="WIDTH:900px;HEIGHT:600px;" height="600" alt="Danko Danny Kovatch Scrum PMI conference" src="http://www.itpics.co.il/ThePeople/2008/PMI_28.5.08_cd3/Pmi_215.JPG" width="900" /></p>
<p> תהנו</p>
<p> </p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1785" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxPMI conferencehttp://agileisrael.org/cs/blogs/danko/archive/2008/05/29/pmi-conference.aspx2008-05-29T10:45:00Z2008-05-29T10:45:00Z<p>אתמול הייתי הכנס והיה לי מדהים! מדהים לראות כמה אנשים עדיין עובדים בשיטת המפולת</p>
<p>ההרצאה שלי התחילה בחמישים דקות איחור ופתחתי אותה בהבאת הברושור הענק שמראה את זמני הסשן והדגשתי שכל תוכנית היא טובה אבל המציאות חזקה מאיתנו</p>
<p>שתי ההרצאות הקודמות לי עסקו הראשונה בהטמעה במוטורולה והשניה כל סמכות ארגונית</p>
<p>כל כך חבל לי שההרצאות לא נעשות באג'ייל ולא ברוח הסקראם</p>
<p>עוד יותר חבל לי שמטעים את הקהל במושגים לא נכונים ותכנים לא נכונים</p>
<p>בואו נעשה סדר ובלי שמות של המטעים</p>
<p>סקראם <strong>כן</strong> יוצר יותר איכות</p>
<p>סקראם <strong>כן</strong> יותר גיבוש בין אנשי הצוות שגורם לחיפוי הדדי ולעמידה במכלול המשימות הצוותי</p>
<p>ישיבת התכנון של הספרינט הבא נעשית <strong>בסוף</strong> הספרינט הנוכחי ולא בתחילת הבא</p>
<p>ויש עוד אבל אלו העיקרים</p>
<p>אני אפרסם את המצגת אחרי שאעלה אותה</p>
<p>הנה מה שיופיע מחר בגלובס</p>
<p><img title="PMI" alt="PMI" src="http://agileisrael.org/cs/files/folders/1723/download.aspx" /></p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1724" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxאוגוסט השחור, ספטמבר האפורhttp://agileisrael.org/cs/blogs/danko/archive/2008/05/27/1683.aspx2008-05-27T10:43:00Z2008-05-27T10:43:00Z<p>והנה עוד שני מושגים לזכור כשעושים ישיבת היערכות ותיכנון לפני ספרינט</p>
<p>כידוע, צוות ספרינט יושב ביחד ביום האחרון של הספרינט וניתן את היכולת שלו לספרינט הבא</p>
<p>בישראל יש נטיה לשכוח את אוגוסט השחור וספטמבר האפור</p>
<p>בייחוד לגברים שביניינו</p>
<p>וזה הולך כך</p>
<p>בעל: את לא תאמיני היום בעבודה תיכננו את הספרינט הבא, אנחנו יודעים כמה כל אחד עומד לתת</p>
<p>אישה: איזה כייף, אגב מה קורה בשבוע הבא עם הילד, איך אתה רוצה להתחלק</p>
<p>בעל: למה את שואלת? יש משהו מיוחד כנראה</p>
<p>אישה: כן, זה שוב סוף אוגוסט ושוב ב"הפתעה" צריך מישהו לשמור על הילדים</p>
<p>בעל: זה משהו חדש? אני לא זוכר שזה</p>
<p>אישה: בודאי חדש, כבר ארבע שנים שיש לנו אותה בעיה</p>
<p>בעל: אין מה לעשות את תצטרכי לקחת חופש כי אני כבר התחייבתי</p>
<p>אישה: ברור לי שאני אקח את הרוב אבל אני רוצה שתיקח יומיים לפחות</p>
<p> בעל: טוב, אם אין ברירה, אבל אני אצטרך לתקשר לצוות על הבלתם הזה</p>
<p>אישה: איך אמרת לי שהסקראם מסטר עונה לכם בהנתן בעיה שאת חודעים איך לפתור? ב ה צ ל ח ה</p>
<p>:-)</p>
<p>בקיצור, אל תשכחו את אוגוסט השחור! ואם מישהו שוכח תזכירו לו</p>
<p>ומה לגבי ספטמבר? האם אתם באמת חושבים שהילד שלכם הוא שק תפוחי אדמה? ביום הראשון הוא לא צריך יותר זמן אתכם בגן?</p>
<p>נכון, יכול להיות שביום יומיים זה יהיה בסדר אבל כשהוא יבין שזה הולך להיות קבוע הוא יצטרך ובצדק יותר זמן בבוקר אתכם</p>
<p> תנו לו את הזמן, ילדים גדלים מהר והם בשיא החשיבות יותר מכל דבר אחר</p>
<p>חישבו על זה לפני הזמן שאתם מתקשרים לצוות, ספרינט עובר מהר מאוד</p>
<p>ב ה צ ל ח ה </p>
<p> </p>
<p>:-(</p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1683" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxHuman Progress bar http://agileisrael.org/cs/blogs/danko/archive/2008/05/22/human-progress-bar.aspx2008-05-22T19:45:00Z2008-05-22T19:45:00Z<p>The day before yesterday I gave a presentation about estimatin and planning for novice in the user forum of Pnina Zinger at Microsoft quarters</p>
<p> It was fun (and hope efficient). I gave a short intro and then we practiced planning poker (90 minnutes)</p>
<p>All of it is well familiar, however I did what I named as the Human Progress Bar (HPB). </p>
<p>I took a large piece of paper and rap it into a ball and gave it to the first person on the left. Then I asked the audience to move this "ball" from one to another with the target of giving it to the last person that sits at the very end at the end of the presentation. This way I could see how much time is left. </p>
<p> Please feel free to use it (but please free to contribute me some credits...:-)</p>
<p>Danko</p>
<p> </p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1631" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxמיזוזו בופאתhttp://agileisrael.org/cs/blogs/danko/archive/2008/05/22/1630.aspx2008-05-22T17:43:00Z2008-05-22T17:43:00Z<p>ולכל אלו שעדיין לא מכירים את המאכל הזה, זה מאכל האהוב על אירופאים הנפוץ בישראל ובתורכיה</p>
<p>אני משתמש במאכל הזה כמו גם במאכלים אחרים בתרגיל הערכות בקורס </p>
<p>דנקו</p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1630" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxThird day of the Scrum gatheringhttp://agileisrael.org/cs/blogs/danko/archive/2008/04/19/third-day-of-the-scrum-gathering.aspx2008-04-19T05:45:00Z2008-04-19T05:45:00Z<p><br />What an excellent fun and efficient day it was !!!! <br />We continued the sessions from yesterday. <br />I gave the session "it is 2012 and Scrum had failed, what we did wrong?" <br />which is called the premortum technique for surfacing the risks . <br />Then we had a closure of the open space by hearing Ken's lecture <br />"Why the SOS was killed and what is got to do with the DoD" <br />(I hope I remember it correctly). As a big finale, there was a lecture of two people from force.com <br />that described the way Scrum had been assimilated into their organization. <br />This was a great efficient fun lecture that you rarely see. <br />They were synchronized to the details. The presentation itself was served in a most interesting way <br />(despite of the fact that most of it was numbers, interesting numbers, but still numbers. <br />I would have sent at least 8 CEOs that I am familiar with and a similar number of R&D VPs <br />to learn how to communicate results of a process without a single excel chart). <br />A big WOW for Salesforce.com and for these two guys!!! <br />No doubt it was worth staying till the end. <br />I highly recommend downloading this presentation and showing it to your manager.<br />It was strange seeing in a snap how a Scrum hotel with spark people turn into just an hotel <br />with unbearable elevators… but this is life. <br />It was fun and the next gathering will be held in Stockholm on the 20-22 of October. <br />My next conference is the Israeli PMI. I will give a lecture to the waterfall people <br />about transitioning to Agile (and to think that only a year ago <br />I had to struggle myself into this event and give an intro to Scrum …:-)</p>
<p> </p>
<p> </p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1509" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxSecond day of the Scrum gathering in Chicagohttp://agileisrael.org/cs/blogs/danko/archive/2008/04/16/second-day-of-the-scrum-gathering-in-chicago.aspx2008-04-16T13:12:00Z2008-04-16T13:12:00Z<p>Day 2<br />Yesterday<br />For those who are familiar with the open space session, I was kind of a butterfly <br />trying to catch as much information and knowledge with all the lectures<br />that were held at once (I must not forget brining my cloning device to Stockholm :-)</p>
<p>In the morning I participated in Dan Rawsthorne's session called "Complex Backlogs". <br />Beside the fact that I enjoyed the session, it was very effective one. </p>
<p>The term "Groups" in related to product backlog was described by him <br />(we also mentioned that the term "Product backlog" is kind of a residue <br />from the past while nowadays the backlogs contains not only items that related<br />to the product but also items that related to the team). </p>
<p>The 30/30/40 law was represented, the terms "ghosts" and more. <br />We had a lot of exercises and had a lot of fun. I did miss an exercise <br />from the last session in order to quickly visit Pradyumn Sharma's session<br />about "Applying Scrum for an In-House Software Project". </p>
<p>There was also another interesting session but I could not participated<br />in both so I went back (cloning device, I need it!!). After a short break <br />(well, even Scrum people need to eat …), I participated in Giora Morein and George Schlitz's session <br />called "“Ambassador Model for Effectively Distributed Scrum Programs” where they presented their model. </p>
<p>I know Giora from Israel and let me tell you that the Scrum is strong with him. </p>
<p>This session was a must for all the people that are running distributed teams in their organization!<br />In parallel a session of Mike called "Prioritizing Your Product backlog" <br />was held and I forced to quit their lecture in order to partly participate in Mike's lecture.</p>
<p>At lunch we heard about "Navigating State Farm Through its agile journey" which was very interesting <br />(I will elaborate later on). Last activity was the open space which will continue to the next day. </p>
<p>We were introduced with the concepts and we started to suggest issues. <br />I suggested having the premortum question (AKA TMQ, time machine question) about Scrum. </p>
<p>One of the methods I am using in order to get all the risks of the team BEFORE the sprint begins <br />is to imagine themselves that it is the END of the sprint and we FAILED to do each and every user story. <br />Then I asked them what did we do wrong. This technique surfaces at once all the things we want to avoid <br />during the incoming sprint. I suggested to do the same with Scrum. <br />Let us imagine it is 2010 and Scrum is no longer the leading (Agile) development technique. What did we do wrong? <br />Other suggested sessions were<br />• Scrum and CMMI<br />• Scaling quality with Scrum<br />• Ways to know if you are a CrAgilist <br />• What is the "Done" for internal customers<br />• Coaching – the practice or the theory<br />• Strategies of dealing with passive aggressive line managers that do not buy in<br />• Definition of "Self organized team"<br />• Games for facilitators, doing it not talking, not doing<br />• Metrics<br />• How to introduce scrum to service teams<br />• Retrospectives<br />• How to do software testing in the Agile world <br />…and more. </p>
<p>For the complete list, please wait for my update from Israel, there is a limit to what I can remember). <br />I am sure tomorrow will be fun and efficient!</p>
<p>The day ends with a fun fun cocktail hosted by DRW trading group. <br />Since I had couple of beers, a lot of sea food and other snacks, <br />the only thing I remember was that I didn't win the iPod . <br />While I will analyze the pictures I took, I may have better visibility <br />on this event (I am sure that there was some lecture about visibility yesterday….)</p>
<p>Tomorrow, <br />I am going to participate in the open space, jumping around between the sessions <br />and earn as much knowledge as I can. I will keep you posted </p>
<p>Impediments: None! :-)</p>
<p> </p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1504" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspxTech Ed presentations http://agileisrael.org/cs/blogs/danko/archive/2008/04/15/tech-ed-presentations.aspx2008-04-15T12:15:00Z2008-04-15T12:15:00Z<p>Can be found <a class="" href="http://www.microsoft.com/israel/techedevent/list.aspx">here</a></p><img src="http://agileisrael.org/cs/aggbug.aspx?PostID=1501" width="1" height="1">Dankohttp://agileisrael.org/cs/members/Danko.aspx