At a family gathering several years ago, I spoke with my great Aunt’s new friend, a man who had just retired after 40 years of teaching golf. He told me that during the last three years of his career, he switched to teaching a method called Natural Golf. It produced vastly superior results than traditional golf instruction. He said, “Josh, if I could refund the people I taught for 37 years, I would. Natural Golf is so much better.”

Have you ever wondered if perhaps there is a better method for what you teach?

Better Agile Estimation

I spent over 6 years teaching thousands of people how to estimate user stories with story points, calculate a team’s velocity based on story points and strive for a consistent velocity (number of story points completed) per iteration. I don’t do that anymore. The approach, which seemed quite reasonable at the time, proved to be consistently awkward and difficult for Industrial Logic’s clients. Despite a lot of hard work to clearly define a story point, students continued to struggle with the concept. One student suggested that a story point ought to be called a Nebulous Unit of Time (NUT). Managers compared teams by velocity even though we explained that velocity was never meant for that purpose. Under pressure, teams increased velocity simply by inflating story point estimates. Problem upon problem materialized over those six years. Improved training didn’t help. Ultimately, my colleagues and I began to experiment with easier, faster, and more graceful ways to accomplish estimation without story points (read my 2012 blog, Stop Using Story Points). Today, we use a variety of techniques, including probabilistic forecasting based on cycle time. Like Natural Golf, these techniques have proven to be vastly superior to traditional (outdated) agile estimation approaches.

Testing Business Rules

Industrial Logic used to teach FIT (Framework for Integrated Test) as part of helping people learn Acceptance Test-Driven Development/ Behavior-Driven Development. We loved FIT, another fantastic innovation by Ward Cunningham. Yet, we repeatedly observed students struggling to write simple examples for complex business rules. And that made their FIT tables awkward and complex. We took that as a signal to improve our training, but that didn’t change the outcome. It finally got to the point where we felt we needed to teach “table smells”, a collection of FIT anti-patterns. But we never did that. It was a new signal telling us that perhaps FIT was simply too difficult for our clients. We eventually abandoned FIT, including training materials we’d work very hard to build and refine. We ultimately found simpler, easier-to-adopt, and less error-prone approaches. One such method doesn’t involve learning a framework, building HTML tables or writing fixtures. Non-technical or technical people simply write English-readable acceptance criteria that can be easily turned into composed methods, like so:

public void CheckLoyaltyDiscountNotOfferedAfterPurchase() {
    customer = CreateLoyaltyCardCustomer();
    customer.addLoyaltyPoints(DISCOUNT_THRESHOLD - 1);
    customer.purchase(LARGE_LATTE);
    checkNoDiscountProvidedFor(customer);
}

Rethinking Product Ownership

For many years now, I’ve seen blogs like this:

Is there good advice in these articles? Certainly. However, they also raise the question, are there consistent, repeated problems with the Product Owner role and is there an easier way? I believe so. I’ve experimented with having product management skills distributed within a team and dropping the PO role altogether (see Eliminating the Product Owner Role). Product ownership by a whole team has worked. In Finland, Maaret Pyhäjärvi has experienced similar success with teams that have no Product Owner (watch my #ModernAgile Show interview with her). For my teams without Product Owners, chartering has been critical for helping maintain focus on desired organizational outcomes. The teams figure out how to accomplish outcomes and everyone stays aligned by regularly reviewing and updating the charter (i.e. actively chartering on a regular cadence).

Experiment Rigorously

In 2001, the authors of the Manifesto for Agile Software Development said “We are uncovering better ways of building software…” They did not proclaim that they had uncovered the one right way. “Uncovering” is the word that invites us to keep exploring better, faster, simpler ways.

My colleagues and I at Industrial Logic love experimenting rigorously with principles and practices. We have no issue dropping something we cherish in order to discover what happens without it. We once thought that XP’s Iterations or Scrum’s Sprints were essential to being agile, but now we know better (read The Day We Stopped Sprinting). Rigorous experimentation has helped us discover easier, less frustrating ways to become more agile. Today, our practice of agility looks nothing like it did in the 1990s, when we first began experimenting with lightweight software development methods.

Simplicity is elusive, yet well worth pursuing. We love to discover simpler, safer, speedier ways to accomplish work. And we love to remove learning impediments. When we discover that some practice is repeatedly and predictably difficult or error-prone for clients, we don’t simply work to improve our training or write articles about how to avoid common mistakes. Instead, we begin experimenting with simpler, easier ways to accomplish the same thing. Sometimes that yields breakthroughs.

When something is repeatedly difficult for people, we say “It’s On Us” to fix it.

"It's On Us" encourages us to
innovate rather than patch problems.

Patching problems and making small adjustments is sometimes the right approach. But if the problems persist, it may be time to try a fresh approach. And unlike the golf instructor, you need not wait until you’re near retirement to discover better ways. Pay careful attention to repeated, predictable problems as they are often a signal to explore new ways to get far better results.