Export to

• Google Calendar
• iCalendar file
• hCalendar markup
  <div class="vevent h-event"> <h1 class="summary p-name">Agile PDX Downtown Pub Lunch: Grappling with the Business's Need for Predictability</h1> <div class='date'><time class="dtstart dt-start" title="2014-11-07T12:00:00" datetime="2014-11-07T12:00:00">Friday, November 7, 2014 from noon</time>–<time class="dtend dt-end" title="2014-11-07T13:00:00" datetime="2014-11-07T13:00:00">1pm</time></div> <div class="location vcard p-location h-card"> <a class="url" href='http://calagator.org/venues/202394597'><span class='fn org p-name'>McMennamins Ringler's</span></a> <div class="adr p-adr h-adr"> <div class="street-address p-street-address">1332 W. Burnside</div> <span class="locality p-locality">Portland</span> , <span class="region p-region">OR</span> <span class="postal-code p-postal-code">97202</span> <div class="country-name p-country-name">US</div> (<a href='https://maps.google.com/maps?q=1332%20W.%20Burnside,%20Portland%20OR%2097202%20US'>map</a>) </div> </div> <div class="description p-description"> <p>We frequently encounter Agile teams struggling within larger organizations that are not Agile. The resistance to Agile frequently centers around predictability. Executives feel pressure to report to the Board of Directors what software will be delivered in the coming year. Product Owners are asked to work out long-term strategies and priorities. Sales is working with customers who want to know what features are coming and when. And Marketing departments are pulling together advertising campaigns for the coming year.</p> <p>In each of these cases, there would be real and undeniable benefit in knowing what the future holds...but we don't. Agile is very clear on this point--software development is not predictable. And development teams are often hesitant to offer any form of prediction out of fear that the prediction will be taken as a "promise".</p> <p>This AgilePDX Pub discussion is an attempt to imagine what an Agile team would offer in the way of predictions if we did not have that fear, if we were to give the best information we can devise about the future of our projects (in an Agile fashion). As a starting place, it pulls together a lightweight process for estimating size from the book "How to Measure Anything" by Douglas W. Hubbard, along with, recent research into common human biases that impact our assessment of risks.</p> <p>Michael Kelly has been thinking about this a lot (see the thread he launched on the AgilePDX Yahoo Group in October), and he'll set context and get the discussion going for you.</p> <p>Michael is a veteran of numerous software development campaigns. He has built software for power companies and banks, for the trucking industry and education, for internet start-ups and established companies, for his own companies and for others. Throughout, he has worked hard to master the craft of writing software and delve to the mysteries of Agile. Currently, he is working with the excellent folks at DAT Solutions, leading a team developing the next generation of software for the trucking industry.</p> <p>As usual, look for us in the back of the pub. RSVP to <a href="mailto:jean@azuregate.net">jean@azuregate.net</a> if you can. We nearly swamped the wait staff in October, and we'd like to provide a little warning if that may happen again. However, don't let lack of ability to RSVP keep you from showing up.</p> <p>Bring your questions, your objections, your burning issues around agility and predictability. Bring your Product Owners and executive staff and THEIR burning issues.</p> <p>Usual pub grub. The beer never stops flowing. See you there!</p> </div> <h3>Links</h3> <ul> <li><a class="url u-url" href="http://www.agilepdx.org">Website</a></li> </ul> </div>