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.

009 – Agile for Humans


Ryan Ripley, Zach Bonaker, Glen Alleman


Glen Alleman has more than 30 years of experience as a program manager and performance management consultant in the aerospace, defense, and enterprise information technology fields. He is the author of the Herding Cats Blog. His latest book is called “Performance Based Project Management: Increasing the Probability of Project Success”.

Zach is an independent agile coach who brings a systems thinking approach to his coaching work. He is fondly known as the benevolent trouble maker, and is joining us again as co-host this evening.

To kick off the show, Glen talked about the need to estimate when working in uncertain domains and gave us a glimpse into how he makes decisions on his project and how he has implemented agile on large programs. We then moved in to the topic of #NoEstimates. The key question that Glen has about #NoEstimates is as follows:

“In what paradigm can you make a decision in the presence of uncertainty about a future outcome without making an estimate of that outcome?”

Glen shared how his teams approach estimation and gave some insights in to recent project failures that have made the headlines. He readily shared that estimates can be misused by management and was adamant that this kind of bad management must be avoided. In fact, this kind of management is the key reason Glen attributes to the #NoEstimates movement resonating with developers.

The wrap up centered around who ultimately pays the bill for #NoEstimates. Glen noted that much of the #NoEstimates behavior is driven by those who are not signing the checks – it isn’t their money. Exploration is paid for by someone and that someone has value at risk that must be mitigated. He advocated for better training for managers on how to use and create proper estimates.

From his latest blog post:

“This of course goes for the #Noestimates notion as well – ask those paying if they have no interest in knowing when those capabilities will be available and how much they will cost. You may get a different answer that the one provided by the developer, who does not own the money, the business accountability, or the balance sheet performance goals.”

Glen also provided notes on the discussion that can be found here and here.

Take Aways

  • Definitions matter: Is story slicing estimating? Are forecasting, projecting and estimating all interchangeable terms or do they have different meaningss to teams and stakeholders?
  • Upstream decision making should be addressed. Or is #NoEstimates purely a developer play?
  • Estimates as a dysfunction: Can we clearly state the dysfunctions that we are correcting by seeking alternatives to estimating?
  • Projects are still failing miserably with governance and estimating processes in place. Both sides are seeking to solve this problem but at opposite ends of the spectrum. One end wants to improve the estimating process and estimates, while the other is seeking alternatives. BUT how do we know that estimates caused the failures?

Resources, Plugs, and More




008 – Agile for Humans


Ryan Ripley, Victor Bonacci


Victor is an independent consultant who hosts the Agile Coffee Podcast. He helped organize this years Agile Coach Camp US West in California, and participates in many local events on the west coast.

We started the discussion on our involvement in the agile community and some of the conferences that we enjoy. We’re both connected by our love of the Agile Coach Camp conferences are both looking forward to this years meeting later in July in Washington DC.

The topic shifted to podcasting. We both host podcasts, product podcasts, and listen to podcasts. We fielded some of the questions that we sometimes get such as:

Which agile podcasts do we listen to – other than Agile Coffee and Agile for Humans?

How do you produce and record your shows?

What kind of equipment do you use?

We moved on to the recent Scrum Coaching Retreat in Seattle where Victor and his team worked on the concept of coaching dojo’s. Finally, we discussed pair coaching and the impact this practice can have on coaches who are mentored in this manner. The similarities to pair programming are hard to ignore, as are the immediate benefits coaches can experience.

And then…we called it a night.

Resources, Plugs, and More



007 – Agile for Humans


Ryan Ripley, Zach Bonaker, Tim Ottinger


We opened the discussion by defining the critic’s view against #NoEstimates:

Estimates are natural, ubiquitous, useful, and unavoidable in practical life and in business. Estimates are an important part of the process of collaboratively setting reasonable targets, goals, and commitments within an organization. The process of estimating, in and of itself, has by-products and benefits. Given that a rational estimating process is an integral part of making decisions in the presence of uncertainty, it is hard to understand why anyone would state that a desirable goal is to push forward into limiting estimates; down to zero where possible.

From there the discussion flowed in multiple directions as we discuss the many areas of agreement that we have with some of the #NoEstimates critics:

  • The process of estimating, in and of itself, has by-products and benefits far beyond the sheer “number” or other indicator of sizing that emerges at the end.
  • When asking for estimates, management is acting benevolently and is looking to have a need met.
  • Abuse of estimates is poor management and a sign of dysfunction
  • The word “estimates”, as used in our debates, has been interpreted in a wide array of possibilities – from guesses to predictions.
  • It’s reasonable to feel a sense of shock here. It sounds like people are saying to “just stop giving estimates” and leave managers hanging.

Throughout the conversation we shared what we have learned from the interaction with the critics and worked on clarifying many of these areas:

  • Ambiguity around the #NoEstimates tag and the lack of civility demonstrated at times by those supporting NE has damaged the discussion and limited collaboration.
  • The connection between agile principles & values and #NoEstimates is not clear.
  • The role of systems thinking in the approach to minimizing the role of estimates is also not clear.
  • The field of “professional estimating” is highly complex, sophisticated, and dedicated to continuously improving the quantitative practice of estimating software development.

The remaining time was spent on systems thinking, pre-conditions necessary to question estimation processes and value, and the role of excellent engineering practices in reducing the role of estimates in a software delivery system. Then, we called it a night.

Resources, Plugs, and More

Ryan – http://agileanswerman.com

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

Tim – http://agileotter.blogspot.com/