Additional 15.0 Background

By now, you have hopefully read through the site’s background on what Agile Dialogs itself is about.

If you haven’t looked over it, our Agenda is posted below the schedule on that page. The proceedings will follow that structure.

Our theme as you may have noted was:

“Agile Predictions: Exploring the tools for making sound business decisions with & without estimates”

Who Attended

We had a good mix of folk from various sectors and roles. We had reached out to a variety of folk on both sides of the debate.  We didn’t really wind up with anyone at either end of the spectrum. (i.e. We didn’t have anyone that not willing to have their assumptions challenged if they were proestimates and we didn’t have anyone that tried to avoid estimates at all cost.) We did have people that had never not estimated and we had some folk that had dropped at least certain kinds of estimates. Here’s a quick breakdown of some of the attendees:

• We had private and public sector (Government) representation both as contractors and at least a former GS type.
• We had folk that had worked all different sizes of projects/prduct development activities.
• We had people that served as coaches both internally and externally (i.e. hired coaching consultants).
• We had Scrum Masters/agile team leaders.
• Our private sector representation were from the finance, insurance, embedded system, broadcast media, and large-scale website development.
• Our farthest attendee came from Saint Louis.

One interesting thing to note about participants: all those that had experimented with #noestimates had come from a background of using estimates.

Why We Structured Like We Did

When you look at our agenda, you may ask why didn’t we take an Open Space approach? When Trent and I discussed whether that would work, we included that the self-organization aspect of OST would get us there most likely, but it may take longer than the day we had set apart.  Not knowing the attendees ahead of time, if we had people that had been arguing over Twitter or via their blogs, people that had never before suspended their assumptions about the other side, then it may take too long to actually have fruitful discussion.

Additionally, while some polling to both sides indicated some wanted data to argue, we knew that data could be used to prove either side. We felt that would take away from the story-telling we wanted to use at the start.  Experiences are different than data.  I could be totally on target with accurate estimates, yet the experience may yield something that we called a failure if the business wanted IT to get started and the estimation process was frustrating them. The same could be in reverse… (estimates aren’t needed, but the experience produces what we would consider a failure).

So we settled on a set of structured questions, again you can see these on the Agenda/Schedule page.

Resources

At the beginning we provided references (people, blogs, and books) on both sides that we felt were thoughtful in how they approached their side (and the other). We did not try to be exhaustive, so here is what was put on our lists:

Want to get better at estimation? Follow these people!

• Mike Cohn, @mikewcohn http://mountaingoatsoftware.com
• Glen Alleman, @galleman http://herdingcats.typepad.com
• George Dinwiddie, @gdinwiddie http://blog.gdinwiddie.com
• Henrik Ebbeskog, @henebb http://kodkreator.blogspot.se

Other resources:

• Agile for Humans podcast @AgileforHumans by @RyanRipley (covered both sides)
• Agile Estimation and Planning by Mike Cohn

Want to learn more about #noestimates? Follow these people!

• Woody Zuill, @woodyzuill http://mobprogramming.com
• Vasco Duarte, @duarte_vasco http://noestimatesbook.com
• Neil Killick, @neil_killick http://neilkillick.com
• Troy Magennis, @t_magennis

Other resources:

• Agile for Humans podcast @AgileforHumans by @RyanRipley
• Engineering Culture at Spotify (2 part video)
• This Agile Life podcast @ThisAgileLife

What We Estimate

Throughout the day, we asked people to post what they estimate. Here’s what made the list –

• Swag in time looking at a UX mock-up understanding the tech stack
• Throughput
• Value to Customer
• Impact to mission
• Trips to Home Depot
• Complexity of Story
• Cost
• Time to Complete Release
• Level of Effort (LOE) to implement/complete a change request
• Revenue