Podcasts about release planning

Ever wondered about why you hunger for an episode on Release Planning or why Brian's Spotify rant struck a chord?Get the inside scoop at this retrospective feast!  We'll examine the recipes for our most popular content from 2024, revealing the juicy trends and themes that tickled your fancy. Plus, we are giving a sneak peek into future episodes, inspired by your binge-worthy favorites!0:00 Topic Intro0:46 AP17: Scrum Master's Role in Release Planning2:41 Back-up Communicator6:27 Playing the Role10:55 Acceptance Criteria12:51 Sprint Review Checklist14:51 Tricky AC & Stories20:00 Agile vs Traditional Software Budgeting26:04 Roadmap Features and Milestones in Agile30:33 Gantt Charts33:38 AA120 - Did AirBNB Fire All Their Product Managers?38:46 Build vs Buy (or Extend)40:07 AP2: Brian Hates on Spotify & Capital One45:07 Take-Aways= = = = = = = = = = = =Watch it on YouTubePlease Subscribe to our YouTube Channel:https://www.youtube.com/@arguingagile= = = = = = = = = = = =Apple Podcasts:https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Spotify:https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Amazon Music:https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast= = = = = = = = = = = = 

Hosts Dan Ivovich, Owen Bickford, and Sundi Myint kick off the 11th season of the Elixir Wizards podcast. This season's theme is “Branching Out from Elixir,” which expands the conversation to compare notes with experts from other communities; they discuss their experiences with other languages like JavaScript, PHP, Python, Ruby, C#, Go, and Dart before and after learning Elixir. This season's conversations will illuminate how problems are solved in different languages vs. Elixir; upcoming episode topics teased include education, data processing, deployment strategies, and garbage collection; the hosts express excitement for conversations analyzing similarities and differences between communities. Topics Discussed in this Episode Season 11 branches out from Elixir to compare notes with other programming communities Sundi, Owen, and Dan introduce the season theme and their interest in exploring these conversations The hosts compare their experiences with PHP, JavaScript, Python, Ruby, C#, Go, Dart and Elixir The Wizards compare and contrast differences in their personal experience building similar things with different languages Dan dreams in Ruby and uses it for quick prototypes Comparing problem-solving approaches across languages will reframe perspectives Upcoming episodes explore data processing workflows, machine learning, and game development Pop Quiz: Who's that Pokémon... or language, or framework? Links Mentioned https://smartlogic.io/ https://codepen.io/ https://i.redd.it/0lg7979qtr511.jpg

In this episode, Eric Landes addresses a question about how the Definition of Done impacts Release Planning. If you are interested in attending Scrum training, check out our public Scrum training courses. Does the Definition of Done help the PO in Release planning? In a recent class, the idea of how the Definition of Done (DoD) affects a release plan and the Product Owner came up!  So, I wanted to walk through what the Scrum Guide says, and impart some practical advice about planning with the DoD.  The scrum guide states that "The moment a Product Backlog item meets the Definition of Done, an Increment is born".  Couple this with the Increment guidance, "an increment must be usable", this helps the Product Owner in forecasting when the increment gets in customers' hands.  The Product Owner uses the team's throughput, or whatever complimentary metric they prefer in their forecasting.  Then during Sprint reviews, the Product Owner shows stakeholders forecasts of when features and functionality can be delivered to customers.  The Product Owner adjusts forecasts as more learning occurs through each Sprint. The Definition of Done impacts the Product Owner's forecasts when it does not include quality steps to get the increment to that usable state.   Product Owners want actual feedback from customers using the software in the wild, to help guide their goals.  The transparency of the Definition of Done can be used by the Product Owner to help move toward a usable Increment. For instance, if the team needs a compliance review before something can go to production, the Product Owner should ask how the team can include this in the DoD.  The Developers might suggest collaborating with the compliance group on automated solutions.  This might add some items to the Backlog to get that automation included in the team's delivery automation.  Now that this is in the Definition of Done the Scrum Team is in control of getting the Increment in front of the customer.   This is one example of how the Product Owner can use the transparency of the Definition of Done to improve the value they deliver. Want to Learn More or Get in Touch? I'd love to hear what you think. If you have a question or a comment, please email us at podcast@agilethought.com. For more information on AgileThought's available courses, go to agilethought.com/services/training-certifications.  This information is also available on the page of this podcast.  Thanks for listening!

To view the video recording of this show and access the master list of website links, please visit the Spilling Ink YouTube Channel. https://youtu.be/9pqc99BLbp8 Spilling Ink the show that takes you behind the book to meet the authors and professionals in the publishing industry. #writerscommunity #writingcommunity #authortube #indieauthor  Our Hosts: Katie Salidas  https://www.katiesalidas.com/ J.E. Taylor  https://jetaylor75.com/ Shout Out to our favorite Indie Podcasters!  Go Indie Now The online Indie Artist network. They offer exciting new content weekly, monthly, and seasonally.  Remember... "It's Always Time to Go Indie Now."   Website: https://goindienow.com Facebook: https://www.facebook.com/GoIndieNow/ YouTube: https://www.youtube.com/channel/UCC3l1LtjS3M7ogb9IyKZHZg AF Stewart Excellent indie author adivice and interviews. https://www.youtube.com/c/AFStewart The Plotaholics Pop Culture Commentary and Reviews https://www.youtube.com/c/ThePlotaholics Margaret Pinard Books, Author Interviews, & Writing Insights http://www.margaretpinard.com/ https://www.youtube.com/c/MargaretPinard Joshua Pantalleresco Writer& Podcaster  https://jpantalleresco.wordpress.com/ Tim Niederriter  Writer & Podcaster  http://www.timniederriter.com/ Rebekah Jonesy Author of realistic fantasies both sexy and killer. https://www.amazon.com/Rebekah-Jonesy/e/B00NQ5Z1CS? https://rebekahjonesy.blogspot.com/

The topic of this week's show is Release Planning and Strategy and joining me on the show is artist manager Jeff Ojeda from Phase Management. Jeff and I had a great discussion about the best ways to plan and release your new album or new single or new video or whatever you're releasing! And there's definitely a lot of great tips, so if you're an artist with new music but don't know where to start when it comes to releasing it - this is the show for you. It was a really great chat and I hope you enjoy it!FRESH CONTENT LINKSJeff recommends: Don Amero - Nothing Is Meaningless Jen recommends:  The Beatles: Get Back documentarySOTWKyle McKearney - Devil WaterYou can learn more about Jeff at phasemgmt.comAnd learn more about Fritz Media at fritzmedia.ca

How Does a Scrum Master Contribute to Release Planning? Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley. What do you think? Let us know in the comments! Take a Professional  Scrum with Kanban Course with Todd, Ryan, and Daniel Vacanti! https://www.eventbrite.com/e/professional-scrum-with-kanban-psk-online-certification-class-psk-i-tickets-167900832911 Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems -  https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course:  https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #scrummaster See omnystudio.com/listener for privacy information.

In this episode, Brian Orlando and Om Patel explore the Scrum Master's role in Software Releases. This includes both Release Planning and the actual Software Release Deployments.0:00 Topic Introduction2:05 Facilitating Release Planning5:47 Team's Role in Release Planning9:50 Scrum Master in Deployments12:58 Working from your Email14:27 Tell the Story of Progress (or not)17:24 Backup or Redundant Communicator20:10 Large Team vs. Small Team Releases21:33 Scrum Master Shielding the Team23:05 Deployment Failures27:50 Insulate Teams from Noise30:20 Stop Doing Manual Release Notes34:01 Topic Review / Summary35:59 Non-Automated Deployments36:46 Wrap-up= = = = = = = = = = = = Also available on YouTube:https://www.youtube.com/watch?v=8U_9KtXJnGEPlease Subscribe to our YouTube Channel:https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1= = = = = = = = = = = = Apple Podcasts:https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3Byb3V0LmNvbS8xNzgxMzE5LnJzcwSpotify:https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Amazon Music:https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-PodcastStitcher:https://www.stitcher.com/show/agile-podcast-2

Planning and delivering product releases is what keeps most PMs busy most of the time. In this lecture, we'll define what a release is, talk about release types and governance, discuss scope in terms of an MVP (minimum viable product) and more.

שלום וברוכים הבאים לפודקאסט מספר 406 של רברס עם פלטפורמה - התאריך היום הוא ה-16 במרץ 2021, ואנחנו שוב נמצאים באולפן שלנו בכרכור, בביתו של אורי - שלום אורי, מה נשמע? (אורי) אהלן(רן) והיום אנחנו מאחרים את ישי בארי, שאני חושב, אבל לא בטוח, שאירחנו אותו כבר פעם אחת פה, אבל בין אם כן בין אם לא - ברוך הבא, או ברוך שובך,(ישי) תודה רבה, שלום(רן) אז ישי מ LinearB - איתו אנחנו הולכים לדבר על נושא שנקרא Smart software delivery.לפני שנצלול לעסק, בוא ספר לנו קצת עליך - מה הרקע שלך, מאיפה באת ומה אתה עושה היום?(ישי) אני, בהכשרה שלי ובמקור שלי, מפתח.באתי מ-8200, למדתי באוניברסיטה העברית מדעי המחשב, ואת, נגיד, החצי הראשון של הקריירה שלי - משהו כמו 18 שנים - התעסקתי ב-Consulting. מיד אחרי השירות הצבאי הקמתי, עם עוד כמה חבר’ה מהיחידה, חברה בשם Platonix - והתפרנסנו מלכתוב קוד עבור אחרים.מוצר ה-Licensing הראשון של Check Point, בימים שזה עוד היה ב -Access DB . . .(רן) זה אתה?! [ד”ש מפרק 1 באפריל?](ישי) לא אני אישית - אחד החבר’ה [זוהר?]מגוון של פרוייקטים, קצרים ובעיקר ארוכים, לכל מיני חברות, גדולות, קטנות . . .(רן) אגב, אנקדוטה - בפרק שעכשיו כבר פורסם, בזמן שאתם שומעים את זה, של 1 באפריל (2021), דיברנו על האפשרות להתקין Access על Cluster של Kubernetes, ובכך לבזר אותו . . .(ישי) אני לא רוצה לדעת . . . [אכן](רן) כן . . .אז התפרנסנו הרבה שנים, בעצם, מלעזור לחברות לפתור בעיות בעולם של תוכנה - לכתוב מוצרים, לדבג (Debug) דברים קשים, לרוץ יותר מהר.הייתה תקופה שגם השקענו בסטארטאפים, ע”י זה שכתבנו עבורם את הקוד ולקחנו Equity בתמורה - סוג של “Sweat Equity” או “Sweat VC” שהפעלנו במשך כמה שנים.[לא היה אז NFT, עוד #נישתי1באפריל . . . ]ב-2014 “עברתי את הגדר” והפכתי להיות שכיר בפעם הראשונה בחיי - זה היה אחרי שעשיתי פרויקט עבור לסטארטאפ מגניב בשם CloudLockאחרי משהו כמו שנה וחצי של עבודה שם כ-Contractor הם שכנעו אותי לבוא ולהצטרף שם כ-Full-timer [בדרך כלל לפרקי 1 באפריל לוקח יותר זמן להפוך לרלוונטיים . . .]אז הצטרפתי ל-CloudLock, סטארטאפ בעולם של סייבר ו -Could Securityהצטרפתי שם ל-CTO Team, עבדתי עם אחד ה-Founders והקמנו את ה-CTO Team אחרי שנתיים וקצת נמכרנו ל-Cisco - ביליתי כמה זמן ב-Cloud Security ב-Cisco, ניהלתי קצת את ה-Site של Cisco בתל אביבולפני קצת יותר משנה עזבתי - לקחתי את המשפחה לספארי באפריקה, רגע לפני הקורונה, חזרנו לארץ ב-28 לפברואר (2020) . . .(רן) ישר לפיראט האדום . . .(ישי) בערך, הרגשנו מאוד ברי מזל . . .(אורי) איך אתה זוכר את זה?! . . . (רן) אני אגיד לך איך אני זוכר את זה - היום במקרה נסעתי בכביש, לא קורה הרבה שאני נוסע בזמן האחרון אבל במקרה היום נסעתי, וראיתי חנות עם שלט ענקי, בנתניה לדעתי - “הפיראט האדום”, אז נזכרתי בזה . . . [אחלה מיתוג, סוג של . . . ](ישי) כשישבנו שם, בסוף הטיול שלנו בזנזיבר, מוקפים בתיירים מאיטליה, והתחלנו לשמוע מהחדשות בארץ שיש כנראה איזושהי בעיה באיטליה, שיש שם משהו רגיש.עוד שבוע קדימה ולא היינו מצליחים לחזור או לצאת בכלל, אז אנחנו מרגישים מאוד ברי-מזל.(רן) האמת שגם אני זוכר איפה הייתי בדיוק כשזה קרה כל הסיפור הזה באיטליה - היו לי כרטיסי טיסה לאיטליה ביד . . . במקרה הייתי באילת בחופשה, אבל שבוע אחרי זה הייתי אמור לטוס לאיטליה, והשאר הסטוריה, כמובן. [איטליה? אכן היסטוריה . . .](ישי) כן . . . אז חזרנו, נחתי קצת אחרי Cisco ובמאי הצטרפתי ל-LinearB - סטארטאפ שאת שני הפאונדרים שלו הכרתי מ-CloudLockשניהם היו, אחד אחרי השני, VP R&D ב-CloudLock - אורי קרן ודן ליינס.אז הצטרפתי ל-LinearB ומאז אני שם - וזה מה שאני עושה היום.(רן) אוקיי, אז LinearB, כן - נשמע לינארי . . . מה זה LinearB? ספר לנו - מה אתם עושים?(ישי) ב-LinearB אנחנו עוסקים באיך לעזור לצוותים לשפר ולהאיץ את הפיתוח שלהם, להאיץ את ה-Delivery של תוכנה.אנחנו, בבסיס, נשענים על מידע שמגיע ממערכות כמו Git - מנתחים אותו, מוצאים Insights, מטריקות, ועוזרים לצוות, למפתח הבודד, לראש הצוות, בסוף גם לאנשי הפרודקט ולמנהלים - למצוא את ה-Bottlenecks, להעיף אותם, לשפר את התהליך ולעבוד חכם.(אורי) אתה יכול לתת דוגמאות ל-Bottlenecks? ישי) כן - כתבתי קוד, הרמתי אותו, יש Pull-request שמחכה שמישהו יסתכל עליו, אבל המישהו הזה לא פנוי, או לא יודע או שכח שהוא צריך להסתכל על הקודאז עכשיו הקוד הזה מחכה, ואם אני לא אזכור להזכיר לו אז זה יחכה יותר מדי.מתישהו זה יקרה, מתישהו אני אגיד “רגע, מה קורה עם זה?”, אולי אציק לו, אולי הוא יתפנה או מישהו יתפנה.זו דוגמא ל”פקק” שאפשר למנוע.(אורי) אבל זה פקק שהוא בסדר גודל של שעות? של ימים?(ישי) זה מאוד משתנה - זה יכול להיות שעות, ויש צוותים ששעות זה חשוב.יש צוותים שימים זה רגיל והבעיה היא כשזה משהו שנגרר ליותר מזה.(רן) אני גם חושב, אורי, שזה . . . אני לא יודע אם “Bottleneck” זו ההגדרה הנכונה, אבל זה איזשהו גורם מעכב - והשאלה המתבקשת היא האם זה פוגע ב-Latency או ב-Throughput?[המלצות קריאה - The Goal הקלאסי וגם The Phoenix Project שהפך די קלאסי]לצורך העניין, כי אם בזמן הזה שאתה לא עושה Review לקוד אתה אולי עושה משהו אחר חשוב, אז לצורך העניין זה אולי פוגע ב-Latency של אותו Pull-Request אבל לא פוגע ב-Throughput שלך כמפתח או ב-Throughput של הצוות כולו . . .מניסיוני לפחות, מן הסתם זה פוגע ב-Latency - אבל זה גם פוגע ב-Throughput, כי ככל שהדברים האלה נמשכים . . . לצורך עניין: Pull-Request, אם הוא נשאר הרבה זמן באוויר הוא הולך וניהיה חוב טכני, והוא הולך וניהיה יותר ויותר מורכב למרג’ג (To Merge) - כי ה-Master זז, כי אנשים שכחו מה הם עשו, כי הם עשו Context-switch למשהו אחר וכשהם יחזרו הם אולי כבר יעשו טעות, ישכחו מה הם עשו או שיניחו שכבר איזשהו Commit נכנס פנימה . . . בקיצור, ככל שעובר הזמן ככה אתה צובר סיכון, ובסופו של דבר אני חושב שזה גם יפגע ב-Throughput אז אני כן רואה את זה כאיזשהו מכשול, לא יודע . . . (ישי) יש באמת לא מעט מחקר סביב השאלות האלה, והאינטואציה שלך נכונה - שמה שפוגע ב-Latency פוגע גם ב-Throughput, גם מהסיבות שאתה תיארת.בסופו של דבר, עבודה על קוד, עבודה של מפתחים, היא עבודה שהיא יצירתית - היא דורשת מחשבה, בתקווה ... (אורי) היא דורשת פוקוס . . .(ישי) . . היא דורשת פוקוס - היא דורשת להיות “In the zone”, ויש מחיר ל-Context-switch, יש מחיר כבד להרבה דברים באווירגם אם ה-Master לא זז - העובדה שיש Pull-Request שאני צריך לדפדף בינו לבין הדבר הבא שאני עובד עליו ולחזור, זה Tax שבסופו של דבר פוגע ב-Throughputמשם בעצם מגיעה אחת המטריקות שאנחנו . . . העולם הזה, של איך למדוד תפוקה של צוותי Engineering בעולם המודרני - מתמקדים ב-Cycle-time, מתמקדים בשאלות של Latency, כי הן עוזרות ל-Throughput.(רן) אבל אם נסתכל שנייה וננסה לקחת את זה לפן המוצרי - מה שאני רואה זה איזשהו מוצר שהוא “נודניק”: יש Pull-request פתוח - אם הוא פתוח שעה אז ננג’ס (Nudge), אם הוא פתוח יום אז ננג’ס יותר חזק . . . פתוח שבוע? שולח אליך חץ ומנג’ס יותר חזק.אבל מה מעבר לזה?(ישי) אז יש פה, אולי ברמה הכי בסיסית, איזשהו אלמנט של “נודניק” - אתה יכול לעשות איזשהו Snoozer סביב משהו שתקועאבל אם אתה לוקח את זה קדימה, אז קודם כל בוא תיהיה חכם - לא על כל דבר אתה צריך לנג’ס באותו מידה, ולא תמיד רק ניג’וס זה הדרך לפתור דברים.[אבי היה הראשון לזהות]לפעמים Awareness זה הזדמנות למישהו להיכנס ולעזור - אולי לא יעזור להציק לך, אבל יעזור שהצוות יכיר את הבעיה ואת העניין, ואולי מישהו יכול להיכנס ולעזור.אולי יש פה “התחפרות” ולאו דווקא בעיה של Attention? יש הרבה בעיות שונותתיקח את זה עוד שלב - אתה בעצם יכול להתחיל לעשות דברים חכמים עם ההגדרה של התהליך עצמו, ושל מה אני, כצוות, או אנחנו כצוות, רוצים שיקרה בתהליך הפיתוח שלנו - מתי משהו נחשב “חריג” ודורש התערבות?האם אנחנו רוצים שכל העבודה ב-Git תיהיה מלווה ב-Ticket ב-Jira - כן או לא?האם אני מרשה לעשות Merge בלי Review? ואולי אני מרשה, אבל רק אם זה Bug שמסומן באיזשהו Flag ב-Jira שהוא נורא דחוף?(רן) אוקיי - מה שאתה מתאר פה זה תהליך עבודה, אבל איך הכלים שאתם בונים יכולים לשפר את התהליך הזה?(ישי) אנחנו קודם כל מתחברים למערכות - קודם כל ל-Git ול-Jira, בתור המערכות שמהן אנחנו שואבים מידע על תהליך הפיתוח ועל האינסטנסים (Instances) של העבודהבעולם שלנו זה Branches ו-Pull-requests ו-Merge-request וכו’, Stories ב-Jira או ב-Project Management.השכבה הראשונה זה לייצר מטריקות (Metrics) ו-Analyticsזאת אומרת - מה ה-Cycle-Time, ותיכף אפשר גם להרחיב על מה זה Cycle-Time ולמה הוא חשוב - אבל זאת מטריקה שקל למדוד אותה אם יש לך את המידע הנכון, והיא מאפשרת לצוות ולמנהלים לראות איך אנחנו (עכשיו) ואיך ואיך אנחנו משתפרים.אם אני לוקח איזשהו Goal להשתפר - האם אני עומד בו?(רן) הקלטנו בעבר, לפני כמה חודשים [אוגוסט 2019 זה לפני שנה וחצי, אבל 2020 זה מרחב-זמן אחר], פרק עם בועז מ-Bizzabo, שבו דיברנו על כלים למדידת מפתחים - אני לא בטוח שהכותרת עושה צדק עם הנושא - וכנראה שכל מפתח ששומע את זה, וגם אז . . . ישר נדלקת איזושהי נורה של “רגע! איך אפשרת למדוד אותי?” . . . דרך אגב, אמרת קודם “יצירתיות”, אז איך אפשר למדוד יצירתיות? אז השאלה הראשונה היא(1) איך אפשר למדוד?ו (2) - האם המדידה עצמה אינה פוגעת ביצירתיות, במורל, אולי בסופו של דבר בשורה התחתונה של החברה, באיזשהו אופן? ו (3) - אם כבר קיימת כזו מדידה, אז אנחנו יודעים שטבע האדם הוא לכוון רק למקום שמודדים, ולא לעשות שום דבר אחר, ואז אנחנו עלולים למצוא את עצמנו בבעיה הפוכה - אולי המפתחים משפרים איזושהי מטריקה, אבל הם משפרים רק אותה, וזה, שוב, לא בהכרח עוזר לשורה התחתונה של החברה . . .אז אני מניח שזה מסוג הבעיות שגם אתם מתמודדים איתן ביום-יום, ואני סקרן לשמוע את דעתך . . .(ישי) כן . . . אז יש פה באמת כמה סוגים של בעיות, והן גם משתקפות בהיסטוריה של האיזור הזה בשוק, או של הפתרונות שצצו ושהתפתחו לאורך השנים סביב השאלות האלה.אנשים תמיד אהבו למדוד דברים, תמיד רצו להישען על Data, אבל היו כמה False Starts בעולם הזה, כשבאמת זה הציף את הבעיות שאתה מתאר.קודם כל, כשאתה מתמקד בלמדוד אנשים, ובודאי אנשים שמתעסקים בעבודה יצירתית ולפעמים גם יצרנית - אתה יכול בקלות לפגוע ב-Culture, לפגוע באותה יצרתיות, לייצר תסיסה.ויותר ויותר מבינים שהדבר הנכון הוא לא למדוד אנשים - זה לא שלא דיברו איתנו מכל מיני חברות בהודו ואמרו “אני רוצה כלי שבאמצעותו אני אחליט כמה לשלם במשכורת - תמדוד לי משהו על המפתחים ולפי זה אני אשלם”.זו, בנינו, טעות - כשאתה מתמקד בלמדוד אנשים, אתה מהר מאוד הולך להשוות אותם, עושה טבלה - מי למעלה מי למטה - ואנחנו חושבים שזו גישה הרסנית, עד כדי . . . שלא תיתן לך את התוצאות שאתה רוצה.אז המוקד הוא לא למדוד אנשים אלא למדוד את התהליך ולמדוד את הצוות, זו רמה אחת.דבר שני שראינו שקרה, זה חברות יותר ותיקות, אם תסתכל כמה שנים אחורה, שמייצרות מטריקות ונותנות אותן למנהליםיש לך Dashboard לאיזשהו Executive, שמראה מטריקות - אני מודד את הארגון שלי ויש לי KPIsאני ה-Consumer של המטריקות האלה ואני “מנחית” KPIs לעובדים שלי של “בואו תשפרו את המטריקות”.(רן) סתם, כדי לעשות את זה מוחשי, בוא נגיד KPI בסגנון מספר הפיצ’רים שדולברו (Features delivered), מספר הבאגים שנסגרו, מספר ה-Pull-requests . . . (ישי) אני מצטער להגיד לך . . . (אורי) . . . או תכנון מול ביצוע . . .(ישי) אני מצטער להגיד שיש חברות בעבר, ועוד כאלה היום, ששואלות שאלות כמו “כמה שורות קוד המפתח הזה כתב?” . . .(אורי) יש כאלה חברות? . . .(ישי) יש . . .(אורי) עדיין?(ישי) זו דוגמא . . .(רן) השאלה שלי היא האם זו בעיה בהגדרת ה-KPI או עצם זה שבכלל יש?(ישי) אני אומר שזו בעיה בהגדרה שלהם של מה הסובייקט שאני מודד ומה ה-KPIs שאני מגדיר.והבעיה השנייה היא מי הצרכן של המדידות - זה גם הולך לכיוון של “מי משתמש בתוצאות האלה ולמה הוא משתמש בהן?” אבל גם, כחלק מזה - מי מגדיר מה צריך למדוד?(רן) זאת אומרת שהבעיה היא כשהמנהל עם השיער המחודד הזה, ההוא מדילברט - הוא זה שהולך ומסתכל על ה-Dashboard וככה הוא מודד את המפתחים שלו - וזה הולך ליצור בעיה, כנראה שלא חשוב מה ה-KPI, אפילו אם זה ה-KPI הנכון - עצם הסיטואציה שהמנהל מסתכל על ה-Dashboard ולא המפתחים עצמם מסתכלים על ה-Dashboard זה מייצר בעיה.(ישי) בהחלט(אורי) וגם אם המנהל מחפש למדוד את המנוהלים, במקום למדוד את התהליך של עצמו . . .(ישי) נכון.אז אנחנו חושבים ששתי הבעיות האלה מזינות אחת את השנייה - הן חיות נפרדות, אבל הן עובדות ביחד.מי משתמש במטריקות ובשביל מה, ומה אתה מודד.אז הנטייה שלנו - אבל אנחנו לא היחידים בעולם הזה - והדרך, שבנינו היא החיובית, שאפשר לגשת ולפתור בעיות בעולם הזה של ה-Delivery - זה למדוד את הצוות, למדוד את התהליךלא את התפוקות - אל תמדוד כמה פיצ’רים (Features) הוצאת או כמה קומיטים (Commits) או כמה שורות קודתמדוד את התהליך עצמו, תבין את ה”בריאות“ של התהליך - ותשתמש במדידות ככלי לאנשים עצמםכלי ל-Introspection, כלי לצוות שרוצה לשפר את העבודה שלו, לא ככלי שמודד “ומעניש” או מודד ומצ’פר את מי שעלה במדד.(רן) אבל זה נשמע כאילו בלתי נמנע שזה יקרה . . . ניקח, לדוגמא, את המאגר הביומטרי: נניח שהמטרה של המאגר הביומטרי בישראל היא מטרה נעלה וטובה והכל - אבל עם זאת, ברגע שנוצר מאגר ביומטרי יש איזושהי סכנה שהוא ידלוף, יש איזושהי סכנה בעצם היצירה של מאגר מידע כזה.אז הנמשל של זה - גם אם זה כלי שיצרת לצורך המפתחים, כדי שיוכלו לשפר את הביצועים שלהם עצמם, הם תמיד אולי יחשבו “אוקיי, אבל מה יקרה אם המנהל שלי גם יסתכל על זה, ופתאום ימדוד אותי במספרים ולא לפי השיער היפה שלי או לפי האופי המקסים שלי?” . . . אז אני מנחש שעדיין, גם אם אתה בא ומוכר את זה למפתחים ככלי לעצמם - הם כנראה יסתכלו על זה בחשדנות.(ישי) יש סכנה כזאת, אני אנסה לא ליפול לקלישאות סביב איפה הבעיהאבל אני אומר - קודם כל, המידע קיים . . . המידע שאנחנו מוצאים - לא המצאנו אותו, חילצנו אותו ממערכות קיימות.בהרבה מקרים החברות שאנחנו מדברים איתן הן חברות שלא באות בלי שום מטריקות ובלי שום Practice.אז הן “תופרות” את זה בעצמן או בונות סקריפטים או בונות משהו חלקי - כמעט אין ואקום של “אני לא מודד כלום”.הסכנה היא שדווקא אם אתה עושה את זה קצת Less informed וקצת יותר פארטצ’, יש סיכוי שתיפול לבורות של המדידות הקלות . . . קל מאוד למדוד שורות קוד, הכי קל בעולם - אז יש ארגונים, שאם האלטרנטיבה היא לא לעשות כלום, אז יקום הבוס הזה עם ה Pointy hair וימדוד את השורות קוד, כי זה מה שהוא יכול להרים בסקריפט קטן בצד, או לקנות בזול - וישתמש בזה לרעה.האם במטריקות שאנחנו מייצרים אפשר להשתמש ברעה? אני מניח שכן.(אורי) אבל אני מניח שכמעט כמו כל חברה שנותנת כלים למדידה, בסוף היא חושבת על מה הם ה-KPIs שאתם רוצים למדוד, ומאחורי זה ישנה איזושהי תפיסה של מהו תהליך נכון או מה זה “תהליך טוב” ואיזה KPI מייצגים אותו - אז בואו נמדוד אותם. השאלה האם יש לכם, בהנחת המערכת, איזושהי תפיסה כזו? אני יכול להגיד מה זה תהליך טוב מבחינתי - מבחינתי, תהליך טוב זה כשהמפתח הוא כמה שיותר Self-sufficient, אין לו מעצורים - הוא יכול לקחת משהו מרעיון ל-Impact בשוק לבד.הרעה החולה, מבחינתי, ביעילות של דברים כאלה זו קבלת החלטות - אם אני נעצר על קבלת החלטות . . . אני לא אראה את הדברים האלה ב-GitHub בכלל - איפה שאני נעצר על קבלת החלטות.יכול להיות שאני אראה משהו ב-Jira תקוע או כל מיני . . .(ישי) נכון - אז קודם כל, Git לא מייצג את כל התמונה - יש לו יתרונות אדירים, אני חושב שהמעבר של עולם ה-Software ל-Git זה איזשהו Seminal change שמאפשר, בין השאר, גם את העולם שאנחנו מתעסקים בו, ואת החלק הזה של העולם של Analytics על תהליך הפיתוח.הוא לא מייצג את כל התמונה - תהליך של פיתוח ויצירת Value בקוד נשען על Git אבל מתחיל הרבה לפני כן, וממשיך הרבה אחרי ה-Git בתהליך של “איך הלקוחות משתמשים” . . .(אורי) . . Go to Market . . .(ישי) . . . וה-Impact של הקוד על העולם - והכל נחשב, הכל רלוונטי.לגבי השאלה של “מהו התהליך הנכון” - אז אנחנו מצד אחד מודעים מאוד לשוני העצום, ואנחנו רואים אותו, בין ארגונים ואיך שהם עובדיםמה חשוב להם ואיפה הם נמצאים היום - גם ארגונים שיש להם את אותו Target דימיוני, אותו כיוון - הם במקומות לגמרי שונים, אתה לא יכול לשפר את הסוסיתא של שנות ה-60 ואת מכונית המירוץ הכי חדישה באותם כלים, למרות שהמטרה (בשני המקרים) היא “לנסוע יותר מהר”.הכלים שונים כי אתה נמצא במקום אחראז מצד אחד, פתרון - גם שלנו וכל פתרון Viable בעולם הזה - חייב להביא בחשבון את השונותומצד שני - יש ערך בלבוא עם Opinions ובלבוא עם . . . לא רק להגיד “שמע, אני מודד לך מיליון דברים, תסתדר ותפיק מזה מה שנראה לך”.פה למשל הבחירה שלנו להישען על Cycle Time כאחת המטריקות החשובות זו בחירה שיש מאחוריה Opinion, ונסיון להגיד ש-Latency יותר חשוב מ-Throughputאו ש-Latency מייצר Throughput יותר טובזה (א) טעון הוכחה ו(ב) אולי לא מתאים לכולם.(רן) נשמע שבכדי למכור מערכת כמו שלכם צריך מאוד “לחנך את השוק”, וזה נשמע ככה אתגר, אתה יודע - א’-ב’ של יזמות זה “במקום שבו יש Market Education, קח הרבה אוויר, זה ייקח הרבה זמן” . . . (ישי) האמת שאני קצת מופתע לטובה, בהקשר הזה.אני נמצא ב-LinearB קצת פחות משנה, ואני רואה, גם קצת ממה ששמעתי בזמן לפני שהגעתי אבל גם תוך כדי הזמן שאני נמצא - יש לא מעט Educated Market כבר באיזור הזה.עיקר ה-Business שלנו מגיע מ-Incoming - אנשי מוצאים אותנו . . . אנחנו עושים Marketing, אבל אנחנו כמעט לא עושים Direct outreach.מוצאים אותנו ופונים אלינו עם Intent - “אני מחפש כלי ואני רוצה לקנות”, לא “ספר לי למה זה טוב”.לא שאין את זה, אבל ה-Intent כבר קיים - אנשים מבינים יותר ויותר, מחקרים וספרים כמו Accelerate ודור המטריקס וכו’ . . . אנשים כבר מכירים את זה.(רן) דרך אגב - אתה חושב שלהשפעה של תקופות הקורונה ושל העבודה מרחוק - שיש לזה השפעה . . .?(ישי) כן, בהחלט, חד משמעית - זה לא משנה את ה-Education, אבל זה מייצר יותר דחיפות . . .(אורי) אני בטוח שזה היה . . . אתה יודע, אלו שאלות שהגיעו מ-Boards [הנהלות, לא של Jira], מ-Executive Teams - “החבר’ה עברו לעבוד מהבית - איך אתה יודע שה-Velocity נשמר? שה-Throuhput של הצוות נשמר?”(ישי) אז או שזה בא למלמעלה, בחברות קצת יותר גדולות, או מהבטן של מנהלים, שאומרים “אני מרגיש שאני מאבד שליטה” - ואחת הדרכים לחזור ולהבין מה קורה “ולחיות את הצוות” זה אולי קצת למדוד ושיהיו לי מערכות . . .(אורי) היפה הוא שהאשליה ש”אני נמצא במשרד עם האנשים אז אני יודע שה-Velocity הוא טוב” זה . . . אתה מגלה כמה שזה היה פיקציה . . .(ישי) נכון - אז אני חושב ש . . .(רן) ה-Velocity של הקפה . . (אורי) כן, המכונת קפה . . .(ישי) תראה - יש מקרים קיצוניים שבהם לפני Covid-19 ישבו כולם באותו חדר, ישבו 6-7-8 אנשים באותו Space והתקשורת הייתה ב”להרים צעקה” למישהו או להסתובב עם הכיסא, ופתאום הם נשאבו לעולם כזה, למעיין Void שבו כל אחד בבית, ואז אני בהחלט מבין את התחושה של “אני לא יודע מה קורה”אז אני חושב שהקורונה ייצרה עוד דחיפות, אולי ייצרה עוד תקציבים לארגונים שפחות יכולים לצטייד ו(עכשיו) יש להם הצדקה.היא לא ייצרה מודעות “יש מאין”.(אורי) אנחנו שלושה אנשים פה, כל אחד מחברה אחרת. כולנו עברנו את הקורונה . . . איך אתם קיבלתם ולידציה (Validation) על עצמכם, שאתם בסדר, במעבר הביתה?(ישי) מה שאני עושה כמעט בכל Demo שאני מראה את המערכת . . . אני פותח את המטריקות שלנו.ה-Demo-אים שאני עושה זה תמיד LinearB על LinearB . . . אין לי Demo Data, יש לי Production Data - ומה שקורה היום זה מה שהלקוחות יראו.אני פותח את ה-Metrics שלנו ומסתכל אחורה, לוקח אחורה עד ינואר 2020 - ומראה לכולם את ה-Spike שיש לנו ב-Cycle-time, שקפץ במרץ, ב-Lock-down הראשון, פי איזה 2 . . . כי היינו קבוצה קטנה ופתאום נהיינו Remote וה-Cycle Time שלנו סבל, לקח לנו קצת זמן להחזיר אותו.כי כל התהליך של תקשורת על איך קוד נכנס והופך ל-Production השתנה . . .(אורי) אז סבלתם מזה?(ישי) סבלנו מזה - רואים את זה ב-Dataאני לא הייתי אז בחברה אז . . . אני רואה את זה ב-Data אבל שמעתי את זה גם מאנשים, מה הם עשו ואילו תהליכים הם עברו כדי להתמודד.ומה שגם ראו, ושמענו את זה מעוד חברות - גם מלקוחות אבל גם סתם מדיבורים - אנשים כתבו יותר קוד . . . אנשים בבית עברו לעבוד ב-remote והרגישו שהם מפגיזים - כותבים יותר קוד ויש פחות הפרעות, יש פחות פגישות, עוד הייתה קצת רומנטיקה בסגר הראשון . . .אנשים הרגישו שיש להם יותר תפוקה.מצד שני - האיזורים של התיאום והתקשורת, שצריך כבר 2-3 אנשים לשתף פעולה כדי שמשהו יקרה - הם סבלו.אז כתבו יותר קוד - אבל ה-Cycle Time התארך, ולקח יותר זמן לגמור דברים ולהביא אותם ל-Production.(אורי) איך אצלכם (רן)?(רן) האמת שקשה קצת להגיד, משתי סיבות - (1) הייתי בהרבה פעמים מנהל, אבל בתקופה שלפני הקורונה דווקא לא היית בפוזיציה של מנהל, ופחות או יותר כשהתחילה הקורונה אז נכנסתי שוב לפוזיציה של מנהל, כך שקרו שני שינויים בו-זמנית, ואין לי Test ו-Control Group, אז קצת קשה לי להשוות . . . [אבל לגמרי רואים את השפעות החשיבה הסטטיסטית….](אורי) אבל השאלה הזו נשאלה - האם אנחנו בסדר? מה המעבר הזה ל-Remote עשה?(רן) כן - השאלה הזו נשאלה, אני לא יכול להגיד לך מה התשובה . . . אני לא יודע מה התשובה.סליחה - אני כן יכול להגיד לך שברמת המאקרו, התשובה היא שאנחנו הצלחנו לשמר Velocity, אפילו לשפר Velocity, בצורה שמאוד הפתיעה אותנו, ואת השוק גם היו עוד כמה שינויים, אגב - אצלנו ספציפית היו גם הרבה שינויים של השוק לאור הקורונה, שגם הם ככה די, אולי בפוקס, רתמו את כולם לאלונקהוכולם נכנסו מתחת לאלונקה וכולם עבדו - מה שאולי בחברות אחרות לא קרה.בשורה התחתונה, אני אני חושב שאנחנו הצלחנו להפתיע את עצמנו בפרודוקטיביות בתקופה הזו, אבל אני חייב להגיד שאנחנו גם משלמים מס כבד ב-Retention, במוראל, בשחיקה של אנשים, שהוא מאוד מאוד משמעותיקשה אולי להגיד אם זה בגלל שעות עבודה או חוסר המסגרת הברורה של העבודהאולי זה שפחות רואים אחד את השני . . .מכל מיני סיבות, אבל בסופו של דבר - השחיקה מורגשת, השחיקה מאוד מורגשת וכל הזמן מדברים על זה.עכשיו - זה נושא אולי לפודקאסט אחר . . .(אורי) פוסט-קורונה, נעשה אותו אחרי ש . . .(ישי) מסתבר שמפתח הוא חיה חברתית, למרות הכל.(אורי) כן . . . אנחנו . . . בדרך כלל אנחנו לא מודדים, ואז באמת שאלנו את עצמנו “רגע - מה אנחנו יודעים?”אבל עוד פעם, ברמה של אני ומנהל הפיתוח, אמרנו “בוא נעשה לפחות איזשהו Sanity check, נראה שאנחנו בסדר”.והסתכלנו על מספר ה-Deployments, כי פשוט בשבילנו, מספר ה-Deployments הוא ה . . ה-Deployment היא הנקודה שבה המפתח מעביר את ה-”Intellectual Property” שלו למוצר אמיתי בשוק.וכשראינו שמספר ה-Deployments היומי ממש לא משתנה לאורך שבועות או . . .אז אמרנו “אוקיי, המצב כנראה בסדר”.[רפרנס לפרק 368 Kubernetes and Dyploma at Outbrain](רן) כן, זהו - אז זה קצת מביא אותי לשאלה של “אוקיי, אז אתם מודדים מספר Deployments, ישי - אתה מדבר על . . . “(אורי) עוד פעם - זה לא שאנחנו יושבים על המפתחים “מה קורה עם מספר ה-Deployments?!” . . . אנחנו מסתכלים על זה באירועים כאלה כדי לעשות לעצמנו ולידציה שהכל בסדר.(רן) כן, זה איזשהו מדד-מאקרו, זה לא . . .(אורי) לגמרי.(רן) עכשיו ישי - אתה מדבר הרבה על ה-Cycle-Time - אתם אצלכם מודדים Cycle-Time ואתה חושב שזה משהו חשוב, שה-Latency משפיע האופן מאוד משמעותי על ה-Throughput. . .בוא נדבר רגע - מה זה “Cycle”? איך מודדים “Cycle”?[מעניין גם בהקשר של Effort Estimations](ישי) אז אקדים ואומר ש-Cycle-Time הוא אחד המדדים, ולמשל . . .(אורי) כמו ב-Intel, כשמגדילים את ה-Cycle-Time של ה-CPU . . .(ישי) אפשר לחשוב על זה כעל סוג של RPM, סוג של סל”ד של הצוות . . . אם אתה מסתכל על קצב ה-Deployment אז הוא סוג של דואל (Dual) לחלק מה-Cycle-Time - אתה לא יכול לדלבר (Deliver) ולעשות Deployments תדירים אם ה-Cycle-Time שלך נורא ארוך.אז ה-Cycle, בעולם שלנו, זה כמה זמן שלוקח ליחידת עבודה מהשורת קוד הראשונה שנכתבת עבורה ועד שהיא בחוץ, בידיים של הלקוח, עד ה-Deployment.זה ה-Cycle שאנחנו מסתכלים עליו.(רן) אוקיי, אז אתם לא מודדים את כל מה שלפני שורת הקוד? - Design ו-Product-Market Fit ו . . .(ישי) אלה דברים שחיים לפעמים בהגדרות של Lead-Time, והיום אנחנו פחות מתעסקים בהם.היום אנחנו עדיין סטארטאפ, אבל הם רלוונטיים לשאלות ולעולם הזה של דליברי (Delivery).(רן) אז מרגע כתיבת שורת הקוד ועד מתי?(ישי) עד שהוא בחוץ . . . עד שהוא Deployed . . .(רן) עד שהוא Deployed, אוקיי . . . ואם, לצורך העניין, הוא Deployed אבל Embarged ועם Rollout אז יש לזה טיפול מיוחד? (ישי) אז ההגדרות של מה זה “Deployed” מתחילות בצורה יותר נאיבית של משהו בינארי - זה בחוץ או לא? ואם כן אז מתי?וזה צריך להתפתח ל-Target - האם זה יצא? האם זה מודלק (On) אצל הלקוחות? האם משתמשים בזה?(אורי) כן - כי יש הבחנה בין “Deployed” ל-”Released” . . .(ישי) לא כל הארגונים מבחינים . . .(רן) לא כולם יודעים, אתה אומר . . .(אורי) “Deployed” זה אומר “הקוד שלי יושב כרגע בסביבת Production”, ו-”Released” זה אומר . . . זו החלטה מרקטיאלית (Marketing), זו לא החלטה אנג’ינירית (Engineering) . . .(ישי) נכון, אז (א) יש הרבה ארגונים שבהם זה קורה ביחד . . .(אורי) מצומד . . .(ישי) . . . ולא ממש מבחינים, או שגם לא מייצרים לעצמם את המנגנון שאומר “זה חי ב-Production אבל עוד לא Released”.או שהם אומרים “אין אצלי את ההבחנה הזאת, וקוד שיצא הוא GA ללקוחות, כולם רואים אותו, כולם משתמשים בו והכל טוב”.אנחנו מאפשרים חופש כלשהו בהגדרה של כל (שלב) שהלקוח עושה לעצמו, או אפילו בכל שלב של Repository, של מה זה אומר “Released” - “אצלי”כשהמטרה היא למדוד את מה שמעניין אותו כדי להשתפראם (עבור) צוות מסויים, הדבר שחשוב שחשוב לו זה “שמתי את זה על Staging ומפה זו לא הבעיה שלי Anymore”, אז אני לא אתווכח איתו ואני אעזור לו למדוד את זה.יכול להיות שמכאן עכשיו זו בעיה של צוות אחר - DevOps או צוות Deploy או IT . . . יש הרבה Flavours בעולם.המטרה היא למצוא את הנקודה שבה ה-Value יצא, וההגדרה מה זה בדיוק “יצא”, זה יכול להשתנות.אולי זו ספרייה ואז שמתי Artifact איפשהו וזהו . . .(רן) בוא ועכשיו אני אהיה “פרקליט השטן”, ואני אגיד “אתה מודד את ה- Cycle-Time? אז אני אקטין את ה-cycles . . .”במקום לדלבר פיצ’ר שלם, אני אדלבר ככה חצי-פיצ’ר . . . ואחר כך אני אוסיף עוד קצת ועוד קצת ועוד קצתככה יהיו לי הרבה מאוד Cycles קטנים, כשכל אחד מהם יהיה מאוד מאוד קצר - ושיפרתי את ה-Cycle-Time שלי . . .למה שאני לא אעשה את זה? אני אראה יותר טוב בעיני המנהלים שלי, נכון? (ישי) שתי תשובות, והן משלימות - (1) שוב - זו מדידה של תהליך ושל צוות, שהוא עם קצת פחות Incentive to game it, כי אני לא גורם לעצמי להראות יותר טוב כי מודדים אותי אישית, יש קפיצה פה של “בואו נרתום את כל הצוות לתהליך, לשחק עם המטריקה”.אבל הדבר היותר חשוב (2) - אם הצלחת לעשות את זה, ויש לך Cycles קצרים כי חתכת את העבודה לאלמנטים קטנים - הרווחת.זה חלק מהמטרה של Cycle-Time - אם הצלחת To Game it, בגלל שהוא מקיף את כל התהליך, אם הצלחת לגרום ל-Cycle-Time להיות קצר, אז המוטיבציה שלך פחות חשובה לי, התוצאה היא טובה.אם שברת את הפיצ’ר לכמה חתיכות שהן Deployable - אני בעד, זו המטרה.(רן) אוקיי, אז Cycle-Time - אמרת שזה מדד אחד אבל לא המדד היחידי, ודיברנו עליו והוא באמת מאוד חשוב.תוכל לתת דגומא למדד אחר, שאתם משתמשים או שהלקוחות שלכם משתמשים?(ישי) כן, אז אורי הזכיר את הנושא של Deployment Frequency - כל כמה זמן, באיזו תדירות ובאיזו רציפות אנחנו מוציאים Value החוצה - זה אחד המדדים החשובים, וגם הוא מופיע במעמד של כבוד במטריקות של DORA ודומים להם.הוא מדד מצויין כדי להבין את הבריאות של תהליך הדליברי.שוב - הוא לא יכול להיות טוב אם ה-Cycle-Time לא טוב ולהיפך - הם משלימים אחת את השני באיזור הזה של הצד של ה-Deployment.יש ארגונים שעוד לא פיתחו את כל השרשרת של ה-CI/CD ויש שם “בלוק טכני”, מה שנקרא - הם לא בנויים להוציא כל הזמן, לעשות Deploy כל הזמן.אז יכול להיות שיש להם ועדה שעושה Deploy ו-Release פעם בשלושה שבועות, אז התוצאה של המדד הזה תיהיה “פעם בשלושה שבועות”, כי זה מה שהחלטנו . . .(אורי) כן, אבל איך אומרים - אם אתה לא מודד אתה לא משתפר, אז במקרה הזה, ברגע שמתחילות מדידות, אז “אה, אוקיי - אז איך אני מוריד פה Bottlenecks?” או “איך אני משפר את התהליך?” . . .(ישי) נכון - אז חברות כאלה, ויש לנו לקוח שגם כתבו על זה בלוג, על איך שהם עברו ל-Release יומי - ממצב כזה של פעם בכמה שבועות, הם עברו למצב של פעם ביום Release, וזה היה שיפור אדיר מבחינתם.אז גם כשאתה עובד במצב של “וועדה” שמייצרת Release פעם בשלושה שבועות - להבין, למשל, כמה זמן הקוד שלך מחכה - זה בממוצע חצי מהשלושה שבועות אבל אתה יכול לקבל קצת יותר הבנה של איזה חלק מהקוד מחכה, האם אני נותן Push לקראת סוף הספרינט ואז יש לי מלא קוד ברגע האחרון ואז הוא בעצם מחכה רק יומיים ל-Release - אז דרך המדידה אתה רואה את אלה.גם אם לא תשפר את השלושה שבועות, אתה תבין קצת יותר את הדינמיקה של כמה זמן הקוד שלך “שוכב”, בעצם בלי להביא Value לאף אחד.(אורי) זה נשמע לי . . . לא יודע, רן בטח גם לך - קצת . . .(רן) שנות ה-80 . . .(אורי) . . . פרה-היסטוריה . . .(ישי) מה - Delivery פעם בשלושה שבועות?(אורי) אפילו פעם ביום . . . (ישי) תתפלא . . . (רן) . . . פרויקט הלביא . . .(ישי) תשמע, יש חברות שה-Delivery שלהם זה Hardware, ואז זה Firmware שנכנס למשהו שהולך ונכנס לקופסא . . . יש כאלה.(אורי) לא על זה אנחנו מדברים וזה בטח גם לא רוב קהל הלקוחות שלך, נכון?(ישי) נכון - אבל יש לנו גם כאלה שתהליך ה-Delivery שלהם תלוי באישורים מגורמים רגולטוריים, מה לעשות?(רן) דרך אגב - גם על זה הולך להיות לנו פודקאסט, על איך עושים Continuous Delivery תחת רגולציה מאוד כבדה - אז !Stay Tuned - אבל לא היום.אנחנו ממש ככה לקראת הסוף, ורציתי לשאול משהו שמאוד מענין אותי - אז בעצם, דיברת בעיקר על Visibility, ודיברנו על מדידה של Cycle Time ומדידה של מספר ה-Deployments ודברים אחרים שאולי הארגון רוצה למדוד.אבל אוקיי, עכשיו ראינו - מה עכשיו? האם הכלי הזה גם נותן איזה שהם כלים של פרודוקטיביות (Productivity)? איזושהי אוטומציה או . . .(ישי) כן, אז דיברנו על Visibility כי זה ה-Entry Point בעולם הזהזה הצעד הראשון - בלי Visibility אתה לא יכול לעשות כלוםאתה לא יכול לשפר שום דבר בלי למדוד אותו ובלי להבין אותואבל חלק מה-Evolution בתחום הזה, במעבר ממדידה של אנשים למדידה של Process, ממדידה שיושבת אצל הבוס למדדים שמגיעים לידיים של המפתחים ושל הצוות.הצעד הבא של ה-Evolution הזה הוא לעבור ממדידות ל-Actions ול-Automations.אז דיברנו כבר על ה”נודניק”? הנודניק הזה הוא ההתחלה או המבשר של תהלכי ה-Automation - הוא הופך את זה מ”ראיתי שהייתה בעיה בחודש האחרון - בוא נעשה Retrospective ונלמד למה ה-Deliveries שלי מתעכבים” ל”בוא נפתור עכשיו, טקטית, נקודתית, את האחד הזה שמתעכב”והפכתי את זה לבעיה שהיא Reaction לאיזשהו Signal, ולא למידה ממטריקה.לשניהם יש מקום, אבל זה צעד קדימה.אם תיקח את זה עוד טיפה קדימה, ופה אני קצת נכנס לאיזורים של ה-Vision שלנו - אנחנו מדברים על תהליך פיתוח: איך אני עושה Branches? איך אני מחבר את זה ל-Jira? למה אני נותן עדיפות? איך אני שומר על . . . איך אני עושה Code Review וממרג’ג (Merge) דברים ואיך אני עושה את זה בתוך קבועי זמן שחשובים לי?את ה-Dev-Process הזה - אפשר לעשות לו Shift-Left ולהפוך אותו למשהו שהוא Automated, ויש לו Guard rails שהם בעצם מגיעים מהמפתחיםבוא תגדיר גם אותו בקוד, או ב-Configuration.כי היום הוא בסופו של דבר יושב במוח של האנשים בצוות, בתרבות שעוברת מיד ליד - מפתח חדש בא לצוות ואומרים לו “תשמע, אצלנו עושים ככה - ביום ראשון עושים Release” או “ביום חמישי עושים Planning”.וכמו כל דבר, כל דבר טוב - צריך לעשות פה Shift-Left: בסוף זה קוד והמפתחים הם ה-Owners של התהליך הזהלהגדיר מה זה חריג ומה להתריע ולמי להתריע, או לעשות משהו אחר עם הדבר החריג הזה.למשל - הם לעצור Release-ים ביום חמישי בערב, מה שאנשים היום עושים מהבטן, כי נהוג לא להוציא Release חשוב רגע לפני שהולכים לסופ”ש?את כל הדברים האלה - אפשר לעשות להם Shift-Left וממש להפוך אותם למשהו שהוא גם מוגדר ונשען על המון מדידות מכל המערכות, צריך לעשות Correlation בין כל המידע.(רן) אתה, כאילו, בא ואומר “בואו נקודד את התשוב”ע” . . . למדנו מניסיון של הרבה שנים שלא עושים Release ביום חמישי בשבע בערב, כי זה הולך לדפוק לנו את הסופ”ש, אוקיי.אז (1) זה באמת לבדוק האם יש . . . האם זו רק תחושת בטן או שבאמת יש Data שתומך בזהו(2) זה שאם יש באמת Data שתומך בזה וזה משהו שאנחנו לא רוצים לעשות - אז שיהיה מי שישמור, ואם באמת מישהו יבוא וירצה לעשות Release בשבע בערב ביום חמישי, אז מישהו יעצור אותו, או לפחות ידליק לו נורה גדולה אדומה מול העיניים, שידע שהוא עושה משהו חריג [שדינו סקילה].(ישי) כן, אתה רואה היום התחלות . . . לרוב זה קורה בצורה מאוד Fragmented [נישתי…] - כל מערכת יודעת לייצר Gates ו-Guard Rails לאיזור שלהאתה הולך ל-GitHub ואתה יכול להגביל מי יכול לעשות Merge ולמה, ואילו תהליכי Review צריכים לקרות קודם.אבל GitHub לא מכיר מה קורה ב-Jira, והוא לא יכול להשתמש בקונטסט הזה כדי להשפיע על החלטה כזו.(אורי) יש לי שאלה - האם אתה חושבים, ב-Vision של החברה, לחבר לזה ייעוץ? לדוגמא - “מדד מסוים הוא חריג אצלך, מה הכלים שלך להתמודד עם זה? מהם הכלים שלך לשפר את המדד הזה?”(ישי) כן, אז מעבר ליצירה של Insights שמבוססים על המדד, על ה-Best Practices ו-Benchmarks - יש תעשייה, יש Data.אבל גם Benchmarks שלך - “שים לב! יש לך עלייה באיזשהו רכיב ב-Cycle-Time לאורך זמן, הנה הגורמים ה-Possible של הדבר הזה והנה הדרכים שבהן כדאי לך להתמודד איתם”, זה בהחלט . . . (אורי) הרבה פעמים הפתרונות הם לא טכניים - הם תרבותיים לגמרי.(ישי) חד-משמעית.אני אקח דוגמא שלרוב קל להתחיל איתה, וככה אנחנו ממליצים לארגונים שאנחנו עובדים איתם - תהליך ה-Pick-up:ללכת והלתחיל לעשות Review למישהו על ה-Code שלו - זה זמן שהרי בהרבה מקרים מגלים שהוא ארוך, ו-Pull-Requests מחכים רק בשביל שיתחילו.ונורא קל לקצר אותו, כי אתה עושה מה שנקרא “Delivery Context switch” - לעשות למישהו Code Review זה הרי Context Switch, זו לא העבודה העיקרית שלי - אבל אני עכשיו חזרתי מ-Lunch או סיימתי פגישה, ואני עוד לא ב-Zone - עכשיו זה זמן טוב, בוא נעשה את זה באופן Delibrate, נחפש את ההזדמנות לעשות Review - זה משהו שהוא תרבותי לחלוטין.צוותים יכולים להחליט שבבוקר ואחה”צ “מנקים את ה-Reviews” - וחתכת את ה-Pick-up time שלך, או לפחות שמת עליו Cap של כמה שעות.(רן) יש שיטה לניהול זמן, ברח לי השם שלה, שהיא מתודולגייה דומה לקריאת אימיילים - אתה לא כל הזמן קורא אימיילים אלא קורא אימיילים, נגיד, 3 פעמים ביום, בשעות קבועות . . .(אורי) . . אבל ה-Inbox שלך ריק . . .(רן) כן, אז יש כמה דברים שם, אבל . . .. לשים איזה שהם קבועי זמן שמייצרים איזושהי שיגרה ואז הרבה יותר ברור . . . [זו אופציה - Pomodoro Technique]אתה גם לא נסחף - נגיד, אתה קורא אימיילים בין 1300 ל-1330 אבל לא יותר, ואת מה שלא סיימת אתה תמשיך אח”כ.וזה נותן לך איזה שהם מרווחי זמן אחרים, יותר קבועים וברורים, לעשות עבודה אחרת, שהיא כנראה יותר משמעותית כי, סתם בדוגמא של קריאת אימייל, קל מאוד להיסחף לפעמים ולא לתעדף נכון את העבודה.אז הגעת היום עם חולצות מאוד יפות, שעליהן רשום DEV INTERRUPTED . . . ספר לנו מה זה DEV INTERRUPTED?(ישי) אז DEV INTERRUPTED זה . . . (אורי) רגע! אני אעשה לך Interrupt . . .(רן) הוא לא Dev . . רגע, אתה Dev?(ישי) אני Dev . . . זה לא יורד במים, להיות Dev . . .אז DEV INTERRUPTED זו Community שאנחנו הרמנו - יש לנו Discord עם משהו כמו 800 Dev Leaders מכל העולם.פודקאסט שהולך ותופס תאוצה, פודקאסט באנגליתואנחנו בעצם בונים חבורה של אנשים שמתעסקים בהובלה של ארגוני פיתוח או של צוותי פיתוח, או מתעניינים בשאלות האלה של מה זה אומר להוביל ולהיות יעיל בעולם של פיתוח. וזה ה-DEV INTERRUPTED(רן) אוקיי - אז פשוט לגגל (Google) את DEV INTERRUPTED [או ללחוץ על הלינקים . . . ](ישי) . . . ותמצאו אותנו, ותמצאו את ה-Discord.(רן) בסדר, ואתה אומר שהשיחה עצמה היא באנגלית כי זה מכל העולם.(ישי) השיחה באנגלית - אנחנו עושים קצת Moderation אבל בסך הכל המטרה היא שזה יהיה אורגני ושאנשים ידברו על מה שמעניין אותם.אני חושב קצת בראש על לעשות נגזרת בעברית . . .(רן) אוקיי - ולמעשה אתם מדברים על נושאים כאלה של איך נכון למדוד ולשפר . . .(ישי) אז זה לא רק מדידות - הייתי אומר שכל העולם של מה שמעניין את מה שנקרא Dev Leaders - אנחנו מדברים שם גם על Hiring וגם Coaching של אנשים בצוות וגם על תפקיד של Senior שהוא לא Leader.השיחות הן באמת מאוד מגוונות - בסוף זה Community שאנחנו הקמנו והיום אנחנו דוחפים אותו, אבל הוא לא Focused רק על המוצר שלנו או אפילו רק על מטריקות ויעילות.(אורי) חיפוש של DEV INTERRUPTED ב-Google יגיע אליכם?(ישי) חיפוש של DEV INTERRUPTED ב-Google יגיע אלינו . . .(רן) וכמובן שגם נקשר ב-Show Notes[עוד הפנייה מעגלית? יאללה - DEV INTERRUPTED באתר וה-Discord Channel והפודקאסט]טוב - ישי תודה רבה! תודה שהגעת לפה, היה מאוד מעניין.הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

Today's question is about release planning on a Scrum Team. When it comes to deciding when to release, the Product Owner has a lot of input. But when it comes to how we release or what is released, the Developer has a say. From an efficiency perspective, even the Scrum Master could have an opinion. Listen in to see how Todd and Ryan sort out release planning on a Scrum Team. How does your Scrum Team handle release planning? Let us know in the comments! This is one of those Scrum Master interview questions that can throw you off. Do you understand all of the things that a Scrum Team can do make sure they are successful with release planning? These Scrum Master day in the life questions can be tricky. Perhaps some Scrum Master training could help? Want to learn more about Scrum? Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course: https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #professional scrumSee omnystudio.com/listener for privacy information.

A two minute talk on Working in Agile - Planning Releases and Sprints - Release Planning. w: 2andh.com 

This episode may surely become one of the most listened to episodes in the history of the Daily Standup Podcast! How can we leverage large scale planning to achieve a great forecast without burning out the team in a multi-day meeting? Join V. Lee Henson as we learn how the BIG meeting should flow, who should be there, and how to keep it streamlined! 

As states, districts and health departments begin planning to reopen schools in the wake of the COVID-19 pandemic, stakeholders are being encouraged to prepare for multiple scenarios and a variety of challenges faced by students, staff and local communities. A new set of planning considerations - released this month by the American Academy of Pediatrics - offers some important guidance regarding instructional time, physical and mental health, special populations, and more. Pediatrician and member of the American Academy of Pediatrics Council on School Health Dr. Nathaniel Beers joins the podcast to discuss the guidance, and what school might look like for millions of students beginning this fall.

In this Hasty Treat, Scott and Wes talk about feature and release planning — dealing with bugs, task management, best practices, and more! Sentry - Sponsor If you want to know what’s happening with your errors, track them with Sentry. Sentry is open-source error tracking that helps developers monitor and fix crashes in real time. Cut your time on error resolution from five hours to five minutes. It works with any language and integrates with dozens of other services. Syntax listeners can get two months for free by visiting Sentry.io and using the coupon code “tastytreat”. Show Notes 4:06 - Wes: Features are logged into software (Github, Jira, etc.) I use a Kanban board - I bubble them up and down in the order in which I want to release them I don’t plan for Q1, Q1, etc… Tear off an issue, tackle it, test and deploy. 10:39 - Scott: All issues/features get a priority tag (e.g. p1 → p4) regardless of the system Bugs go in Github Features and platform improvements go in Notion Table of priorities (with git branch, lead dev, release number, emoji icon, what it contains, etc.) Links Github Trello Kanban Jira Canny Notion Getting Things Done Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

We go one level deeper! Follow Matt on Instagram: https://www.instagram.com/mattbacon666/ Follow Curtis on Instagram: https://www.instagram.com/dewarpr77/ --- Support this podcast: https://anchor.fm/dumbanddumbest/support

One of the big advantages of story mapping, estimating, understanding velocity and what it takes to release is the ability to generate a relatively accurate estimated release date. Listen to how the pieces of the puzzle fit together.

In this episode we (01:07) A few words on the passing of David Hussman, (03:14) Agile Narrative Project: How do we build physiological safety in companies, (20:11) What is the benefit of waiting until Sprint Planning to task out a story instead of doing it in a Grooming session when the team is larger, (26:40) What are useful metrics to show leadership, Leadership wants to see metrics. (32:18) What is a best practice around Agile release planning, and (43:16) Can agile adoption on one team be different from another team.Support the show (https://www.agilealliance.org/membership-pricing/)

Roman Pichler, one of the leading voices in Agile Product Ownership has released a new book, "Strategize: Product Strategy and Product Roadmap Practices for the Digital Age", that presents a number of tools and techniques Product Owners and Product Managers can use to gain a deeper understanding the product(s) they are developing in order to stock and maintain a better product backlog. Show Notes: Why the wrote Strategize 00:26 Adding Product Strategy to Agile Planning 2:46 Vision to Strategy to Roadmap 5:37 How to use the Go Product Roadmap to feed Release Planning 6:00 Who you need to create the Roadmap? 8:40 How Strategize should help Product Owners and Product Managers 10:30 Is the focus on Product Ownership increasing and maturing? 11:50 Explaining the difference between and Product Owner and a Product Manager? 15:20 The key elements of Product Strategy 19:20 Aligning products across the portfolio 21:24 Product Owner at the Portfolio level 23:00 How often should you update your Vision Board and Roadmap? 24:05 How important is it that Team Members know the Product Vision? 25:50 If there was one misunderstanding about Product Ownership that you could fix, what would it be? 27:54 How to get in touch with Roman 30:00 If you'd like to get in touch with Roman, you can reach him at http://www.romanpichler.com If you'd like to pick up a copy of Strategize, you can find it here: https://www.amazon.com/Strategize-Product-Strategy-Roadmap-Practices/dp/0993499201/ref=sr_1_1?ie=UTF8&qid=1466442777&sr=8-1&keywords=strategize

We revisit our often debated topic of release planning.  Josh slipped up in episode 75 (http://www.meta-cast.com/2015/07/episode-75-squads-chapters-tribes-oh-my.html)  and mentioned a new appreciation for the process.  Given Josh's past comments about his disdain for release planning, Bob jumped all over him and demanded that our next episode centered on this topic.  Find out what caused Josh to evolved his viewpoints and hear Bob grill him on this new revelation! What are your views on release planning?  When is it appropriate?  If it is appropriate, how often should you do it?  Who should be involved?  We'd love to hear your thoughts. As a reminder, any listener question/topic that we discuss on air gets one of our fancy new stickers (https://twitter.com/metahyphencast/status/624694048582959104) !  Post questions in the comments, on twitter, or whatever your preferred channel is.  We look forward to tackling your questions and comments! Support this podcast

Vivek and Rick discuss many different topics in this conversation ranging from Governance to Training certification, Agile industry diversity to Release Planning, etc.  We breifly touch on our career goals of CST and CSC, and where we are at in our journeys.

Welcome to the Software Process and Measurement Cast 245 The Software Process and Measurement Cast 245 features my essay on the ins and outs of Agile release plans.I have been involved with very few projects that did not have to answer the age old questions: “When are you going to deliver?” and “What are you going to deliver?” In standard waterfall projects, we would answer those questions with requirements documents, charters and project schedules. In an Agile project a release plan answers the same what and when questions based organizational vision, project needs and team capabilities. The Software Process and Measurement Cast has a sponsor . . . As many you know I do at least one webinar for the IT Metrics and Productivtity Intstiute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI's mission is to pull together the expertise and educational efforts of the world's leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. THe ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars.  The Software Process and Measurement Cast recieves a fee if you sign up this link.  All revenue our sponsors goes for bandwidth, hosting and new cool equipment to create more and better content for you!  Support the SPaMCAST and learn from the ITMPI! THe Software Process and Measurement Cast is a proud member of the Tech Podcast Network.  Check out the Software Process and Measurement and other great casts like The ElegantWorkflow.Com!  http://ow.ly/lQO1r  Do you have a Facebook account?  If you do please visit and like the Software Process and Measurement Cast page on Facebook. http://bit.ly/16fBWV The Daily Process Thoughts is my project designed to deliver a quick daily idea, thought or simple smile to help you become a better change agent. Each day you will get piece of thought provoking text and a picture or hand drawn chart to illustrate the idea being presented. The goal is to deliver every day; rain or shine, in sickness or in health or for better or worse! Check it out at www.tcagley.wordpress.com.  Shameless Ad for my book!  Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team." NOW AVAILABLE IN CHINESE!  Have you bought your copy? Contact information for the Software Process and Measurement Cast Email:  spamcastinfo@gmail.comVoicemail:  +1-206-888-6111Website: www.spamcast.netTwitter: www.twitter.com/tcagleyFacebook:  http://bit.ly/16fBWV Next: The Software Process and Measurement Cast 246 will feature my interview with Tobias Mayer.  We discussed his new book, The People's Scrum: Agile Ideas for Revolutionary Transformation. I will meet you on the barricades next week!

แขกรับเชิญของเราคือ @roofimon มาเมาท์กับ Scrum Cat เรื่อง Scrum มี Release Planning หรือเปล่าหว่า?? Pod สด ณ วัง Roofimon มีทั้งเสียงทีวีและเสียงเด็กๆ ฮ่าๆ มีพี่ปุ๋ยนั่งเป็นพยานข้างๆ ด้วย

Bob and Josh come right back to the Release Planning topic to dig into some of its juicier bits.  In this episode, Bob and Josh tackle the ever challenging topic of estimation.  When should you do it?  Who should do it?  In the end, a basic blueprint is assembled giving guidance on these questions. Support this podcast

Bob and Josh return after a 5 month hiatus!!! In this episode, Bob and Josh discuss styles of release planning and some of the pitfalls we've run into in our travels. Support this podcast

Welcome to the Software Process and Measurement Cast 183!  The Software Process and Measurement Cast 183 features my essay titled, Agile Release Planning Is A Necessity   The essay begins . . . Release planning has even said to be not needed and a waste of time by those who feel that release planning is a retreat from agile. Alternately, it has been called both a black art and a communication vehicle by those who recognize it as a need. Simply put release planning is contentious.  Why the consternation over something so simple? Part of the angst is a relic of the past and part is a flaw in basic human nature. The first part is a memory of over planning we all have seen in some project and program methods and the second flaw is one of basic human nature in that when something is said it tends to be remembered (a delivery date for example). Shameless Ad for my book!  Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team."  Have you bought your copy? Contact information for the Software Process and Measurement CastEmail:  spamcastinfo@gmail.comVoicemail:  +1-206-888-6111Website: www.spamcast.netTwitter: www.twitter.com/tcagleyFacebook:  http://bit.ly/16fBWV Next The Software Process and Measurement Cast 183 features my interview with Steve Boronski.  We discussed Prince 2 which is the standard for project management in the UK and Europe!

Rachel Weston will go over the basics of the Release Planning meeting.