005 – Agile for Humans


Ryan Ripley, George Dinwiddie, Neil Killick, JB Rainsberger


#NoEstimates means many different things to many different people. The group defined #NoEstimates as a conversation around when estimates are appropriate and to which level of precision teams should target. We noted that the hashtag can lead to more “heat than light”, but also acknowledged that a rich conversation has formed around the questions that #NoEstimates poses.

We moved on to discussing estimates being useful at a portfolio level for deciding which projects to do and to forecast budgets. To some this did not go far enough and we continued to highlight other benefits of estimating such as:

  • Conversations that occur when estimating
  • Shared understand of programming activities
  • Enabling decision making at the executive level
  • Validating project/program/product assumptions
  • Indication of possible issues when reality and the estimate do not match

When discussing when estimates are needed, there are no stock answers. George highlighted the need to meet the expressed needs of those seeking estimates. Once that is understood, we can determine an appropriate level of precision and act accordingly. JB cautioned against the mindless use of estimates, but everyone agreed that estimates created with a goal of “making good decisions” are useful.

We turned to real world examples where burn-up charts are used to estimate the delivery of programs. This revealed some important considerations about estimates like the need to build uncertainty in to your estimates, while removing inappropriate levels of precision. We also covered situations with mandates and fixed dates where estimates may not be as critical as focusing on delivering the software frequently.

Part of improving estimates requires improving software engineering practices. If the team can deliver consistently sprint over the sprint, the creation of estimates can move be performed by the stakeholders. While this type of improvement is difficult, George reminded us that focusing on the little things can have a great impact of making delivery more predictable.

To wrap up, we circled back to the idea that we should focus on meeting needs. This aligns well with “individuals and interactions over process and tools”, but is also more difficult to do. Exploring how to meet needs requires soft skills, trust, and good relationships to succeed.

Resources, Plugs, and More

Ryan – http://agileanswerman.com

George – http://blog.gdinwiddie.com/



004 – Agile for Humans


Ryan Ripley, Amitai Schlair, Bob Galen


Agile isn’t simple anymore. We talked at length about the added complexity that has emerged in the agile community and the impact on transformations and projects. Amitai offered a lean start-up approach that we all agreed could be a competitive advantage to companies in years to come. We focused on organizing companies around products to limit risk and maximize value.

We moved on to what’s leading edge and new in the agile world. Bob shared his finding from many informal polls and discussion – that we are not leading edge. 70-90% of people polled acknowledge “bad agile” in their organizations. This has proven consistent when other speakers and coaches pose the questions to large groups and teams.

Next the team discussed meeting the needs of the people we serve and how trust, safety, empathy, compassion, kindness, and love play in to that end. Some of the questions covered include: Is it safe to say you don’t know something? Can you fail quickly in your organization? Do we trust one another to not cause harm in the workplace?

These insights led us down the past of advocating for coaching at the leadership level. This practice is critical as pressure and adversity can cause people to revert to comfortable patterns and practices. Leadership, however, can limit this by “being agile” through thick and thin.

Resources, Plugs, and More

Ryan – http://agileanswerman.com

Amitai – http://www.schmonz.com/


003 – Agile for Humans


Ryan Ripley and  Zach Bonaker


Zach is an independent consultant who recently posted a provocative article called: “The Subversion of Agile: Agile is a Cancer”. We discussed his post, talked about what the cancer is in the community that needs to be removed about posts from others in the community about the “death of Agile”.

We moved on to what Agile in a business language would look like – agile base patterns – and he shared some ideas that he and Dan Greening have been contemplating. We discussed the 5 pillars of an agile organization, which include:

  1. Measure economic progress
  2. Experiment
  3. Limit work in progress
  4. Embrace collective responsibility
  5. Solve systemic problems

From there the discussion pivoted to top down vs. bottom up agile transformations. We discuss how they work, the pitfalls of each, and our personal experiences with trying to help organizations adopt agile. Of course I found a way to bring up agile management. We added a few more books to Don’s book club, talked about the difficulty of filling the role of the product owner, and then…called it a night.

Zach was a great guest who I hope becomes a regular contributor to the podcast. He recently posted a follow-up to his original post called “Agile Cancer: Stop Whining and Cure It” which has expanded the conversation, set off a few flame wars, and provoked some important conversations about our industry.

Resources, Plugs, and More



002 – Agile for Humans

Agile for Humans is a podcast dedicated to the individuals and interactions that make agile work.


George Dinwiddie, Ryan Ripley, Amitai Schlair


First up was a lively discussion about the life of a consultant. Amitai and George represented the contractor side of the story, while Ryan talked about the full time employee side of the equation. We all agreed that life on the road may not the most glamorous, but the upside can be interesting. We had a quick follow on discussion about whether or not an agile coach needs to have a programming background to be effective.

Next the team moved on to the difficult art of facilitating retrospectives. A recent twitter exchange sparked a conversation about whether or not retrospectives were still needed or if teams should just fix issues in real time. We decided that retrospectives are critical to a teams success, but many of today’s retrospectives suck. We shared some thoughts on how to make retros better.

We then plugged back in to the management discussion and whether or not the agile community left middle management behind. The overall agile message can be overwhelming to management, but there is still a place for managers that we need to work on communicating in a more effective way.

Ryan proved incapable of saying Amitai’s name (AH-MEE-TY), we added more titles to Don’s book club, and then called it night.

Resources, Plugs, and More




001 – Agile for Humans

This week I’m excited to share episode one of the “Agile for Humans” podcast. This is a regular podcast hosted by a rotating group of agilists who take on various topics and issues. I’m working on getting a site setup for the podcast, but for now you can find the episodes here and eventually on iTunes.


Don Gray, Mark Kilby, Aaron Kopel, Ryan Ripley


On our inaugural episode the team started off by trying to name this new podcast, however, they eventually moved on. First we discussed Hala Saleh’s talk at Agile Indy 2015 title: My Agile is Better Than Your Agile. Overall the group agreed that empathy and kindness are key ingredients when talking about agile topics.

Next the team moved on to the caring and feeding of user groups. Aaron and Mark shared their experiences in this area and provided cautionary tales and solid advice to Ryan, who is looking to start and agile user group in Fort Wayne, IN.

Ryan discussed his recent talk at Agile Indy 2015 – Help!!! The Scrum Master IS the Impediment – and talked about the need for scrum masters to inspect and adapt their behaviors to avoid becoming impediments to their team’s success.

The team wrapped up with a some light talk about “change” and decided to table that large discussion for next time. Ryan completely butchered the word “cynefin”, Don started a book club, and then we called it a night

Resources, Plugs, and More