013 – Agile for Humans


Ryan Ripley, Zach Bonaker, Amitai Schlair


It’s a miracle that this episode happened. Zach Bonaker (@zachbonaker) got lost in an English bog, Amitai Schlair (@schmonz) was wandering in Guatemala and Ryan Ripley (@ryanripley) was nearly sucked in to the power fueled DC world, but the three managed to come together to ponder some questions about coaching agile teams.


We started with defining coaching, then mentoring, and finally consulting. And ultimately came upon an important insight. If the team knows how to learn together and has a high level of skill in conducting retrospectives, they likely need little coaching. However, such stars rarely align. We discussed if the team should choose when a coach is needed, and managements role in the process. We then moved on to our next question:


When the checks start to bounce, of course! This is another difficult situation to handle. It takes a great amount of awareness to realize that the team can find success without you (the coach). Watching the teams behaviors, the systems they are working within, and the response they have to the coach are all important considerations. On the other hand, we did discuss that in professional sports, the coach never leaves. Even LeBron James has a coach.

The conversation then pivoted in to agile transformations. At the heart our discussion was the idea of influence vs coercion and how coercion can tank an agile transformation quickly. The tendency to hold on the old practices, even harmful ones, is hard to break as teams new to agile often struggle to embrace self-organization. Trust was also a key theme throughout.

Amitai was kind enough to share episode 8 (care) of his podcast: Agile in 3 Minutes. He creates art each week by focusing on one agile idea each week. Insightful and poetic, Agile in 3 Minutes is clearly a labor of love that I’m grateful to enjoy each week. I hope you give Agile in 3 Minutes a listen and subscribe via rss here.

Finally, Zach told us about Victor Bonacci’s recent Kickstarter project: Agile Coaching Cards. Vic was a recent guest on Agile for Humans and taught us how to play Lean Coffee. He’s now selling a deck of cards on Kickstarter designed to help teams get up to speed quickly with Lean Coffee discussion. This is a fun tool that can help teams facilitate conversations about agile topics.

And then…we called it a night.

If you would like to continue the conversation, please visit www.agileanswerman.com/ask-a-question. You can record a message that could end up on the show or send us an email with your feedback, topics, and questions. We hope to hear from you soon.

Resources, Plugs, and More




Agile for Humans is brought to you by audible.com – get one FREE audiobook download and 30 day free trial at www.audibletrial.com/agile

012 – Agile for Humans


Ryan Ripley, Zach Bonaker, Woody Zuill


Woody Zuill (@WoodyZuill) joined Zach and Ryan to talk about experimentation in Agile. Woody talked about his early experiences in the workforce and the need to investigate. These experiences taught him to never take anything for granted and to be inquisitive about all things. This lead to one of his key mantras: Question the things that you have the most faith in.

We then moved on to The Pattern of Continuous No Improvement. This phenomenon occurs when teams set out to correct the same issue sprint over sprint but cannot seem to make progress. Often this pattern is caused by not addressing the root cause of the issue. We talked about 5 why’s as one means to discovering the root cause. We also talked about the team’s need to recognize this pattern and to confront it head on.

#NoEstimates was born from this insight as a team tried repeatedly to improve their estimates but continued to miss that goal. Finally the team decided to work without task estimates and found some improvement and later on, success.

#MobProgramming is another idea brought to the agile world by Woody. He described its origin as an impromptu presentation during Agile 2012. Fortunately, that open jam session was popular and an important conversation about how teams get their work done was born.

Asking the inverse of a question was highlighted as a powerful probing technique, especially during retrospectives. We all agreed that frequent retros bring valuable insights to the team and that effective mob programming is fueled by effective retrospectives.

The discussion then shifted to how teams can measure their agility and the renaissance of craftsmanship in the software development world.

And then…we called it a night.

Resources, Plugs, and More

Ryan – http://agileanswerman.com

Zach – https://www.linkedin.com/in/zachbonaker

Woody – http://zuill.us/WoodyZuill/

011 – Agile for Humans


Ryan Ripley, Victor Bonacci, Jon Jorgensen


This episode is a cross-over between The Agile Coffee Podcast and Agile for Humans. Victor and Jon host Agile Coffee and do a great job of cultivating interesting topics and engaging guests. Not too long ago, Victor joined me on Agile for Humans and we had so much fun that we thought we’d give this cross-over experiment a try.

I have to say that it was a lot of fun having someone else do the facilitation. :-) We managed to cover a wide range of topics that we hope you all enjoy.

  • The HR Side of Agile – Performance Reviews, Raises, & Transparency
  • The Business of Agile – How we justifiy the investment in agility
  • Ken’s Complaint -Trademarking Scrum User Groups
  • Crossing the line – Pushing and pulling hair
  • Organisational Psychotherapist, the new coach
  • Agile Transformation – The REST of the story
  • Agile games, simulations, and learning activities

Resources, Plugs, and More

Group Picks

Question: What did you think of this experiment? Did you like the lean coffee format? Please let us know your thoughts below. You can leave a comment by clicking here.

010 – Agile for Humans


Ryan Ripley, Ron Quartel


Ron Quartel (@AgileAgitator) is an agile coach, blogger (blog.agileagitator.com) and the creator of the FAST Agile framework.

The FAST Agile (www.fast-agile.com) is a combination of Open Space Technology, Scrum, Extreme Programming (XP), and Story Mapping. After watching hundreds of participants use open space technology to organize and hold a conference, Ron decided that such self-organization practices could also be applied to software development.

Rather than relying control mechanisms like SAFe and LeSS, FAST Agile is a scalable agile framework that relies and individuals and interactions along with pulling work in to teams. Utilizing a 2 day sprint, FAST Agile implicitly requires teams to break their work down in to small chunks and to swarm the work in a #MobProgramming fashion.

Documentation on the FAST Agile framework can be found at (www.fast-agile.com).

We then moved on to the pain points of agile coaching, including:

  • Fixing bad scrum implementations over and over again
  • Lack of XP usage on scrum teams
  • Mis-understanding of what makes scrum work

Especially surprising is the low adoption rates of XP on scrum teams. According to the Scrum Alliance State of Scrum Survey 2015, only 16% of scrum teams also practice XP. The Version One survey had the usage rate even lower. Ron is giving a talk at Agile 2015 about using Scrum and XP for Hyper-productivity. If you’re going to be in DC for the “big conference” this is a must see session.

Finally, we wrapped up with a conversation about agile certifications. While the classes are good, Ron questions the value of “certifying” CSM’s after a 2-day course. He started the #SayNoToAgileCertifications and hopes to see improvements in this area.

And then…we called it a night.

Resources, Plugs, and More



Pragmatic Agile Estimation: Predicting the Unpredictable

Your estimate is a guess. It expires and it changes. In Predicting the Unpredictable, Johanna Rothman provides practical tips that increase trust, reduces bad management (hopefully), and helps teams transparently deliver valuable software to their customers.

Zoltar - Greg Lilly - Flickr

Zoltar – Greg Lilly – Flickr

I once inherited a failing project that simply could not fail. A mission critical application had to be replaced, otherwise products would not get loaded in to catalogs, point of sale systems, and online stores. Millions of dollars at risk.

This project had a lot of common problems. The planning and estimates were unrealistic. The features being looked at were too big to be understood and team members were working on multiple projects. Every feature was top priority and many of the features didn’t even exits in the current system.

Worst of all, the stakeholders no longer trusted the project team to deliver.

We needed a prioritized backlog of only the features required to replace the legacy system. It took time and coaching, but we were able to get a few sprints worth of prioritized stories back from our stakeholder. For the first time in months the team delivered a completed feature at the end of the first sprint.

Gradually, the stakeholders came back to the table as we continued to deliver and a great relationship formed. We collaboratively worked off of a product backlog and gained a shared understanding of the project. The were still difficult moments, but the trust was back and features made their way to production.

What weren’t we doing? Estimating. Our ability to deliver and build trust with the stakeholders removed the need to provide estimates. They knew roughly how many features we could deliver in a sprint and the cost of the team was a simple run rate calculation.

We focused on working software and got great results.

“There is an alternative to estimating. Make your features small, as in something you can deliver in a day or so. If you finish something each day, people can see your work product. They trust you. They stop asking you for estimates.” — Johanna Rothman, “Predicting the Unpredictable

How can you move to this kind of collaboration? Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost by Johanna Rothman provides ideas and suggestions to improve your team’s processes and ability to deliver value back to your stakeholders.

Rothman challenges the reader to consider why they estimate. “If you estimate because you always have, think about it.”

Management will continue to ask “How much will this project cost?” and “How long will it take?”. It’s how you answer that can make the difference on your projects.

Do you know the “do’s and don’ts” of providing estimates to your management? If not, Chapter 5: “Think About Estimates” will help you out. Have a fixed date and scope and are unsure what to do? That’s covered in Chapter 6. How do you coach a manager who still needs to know “when and how much”? Chapter 9 has your answers.

These are just some of the topics that Rothman covers for those who must fill the need of providing an estimate. For others, she provides a means to focus on working software and a rationale for doing so.

“When creating software, I want to see working software as we create it, because with working software, we learn.”

This is a practical book about the work of creating software and providing estimates when needed. Her estimation troubleshooting guide highlights many of the hidden issues with estimating such as: multitasking, student syndrome, using the wrong units to estimate, and trying to estimates things that are too big.

Overall, this is an immensely practical book that belongs on the shelf of anyone working on an agile team. The practical suggestions on how to handle providing estimates is worth the prices of the book, making the coverage of advanced topics like #NoEstimates a welcome bonus. Highly recommended!

Click here to purchase “Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost” on Amazon.com.