Back to Agile Basics

A few years ago, I embarked on a “Back to Basics” agile campaign. SAFe 4.0 had just introduced a third layer, above Release Trains, known at the time as Value Streams. Agile tools had become mostly artifact repositories for detailed requirements. Formats, like user stories and stand-ups, had become prescriptive dogma. Many “Agile Coaches” were more focused on their client’s adherence to a process, rather than the outcomes that process produced. They measured success not by the delivery of working software, but by the adoption and implementation of specific practices. The trouble: for many, these practices had become unmoored from the principles they were intended to support.

I felt as though the essence of Agile was being lost. The process people had taken over. They were, after all, in need of something to do. Few software development organizations wanted to use Waterfall any longer. So, a multitude of Portfolio, Program, and Project Managers updated their resumes to include “Agile experience” and then migrated into roles such as Scrum Master, Chief Scrum Master, Release Train Engineer, Value Stream Engineer, Agile Team Coach, or Agile Enterprise Coach. There was no shortage of opportunity.

The Agile market had become saturated and commoditized by big-box resellers who didn’t really understand what it was all about. Suddenly, every company was “going Agile,” most of which made the fatal flaw of emphasizing predictability over adaptability. Few companies actually became Agile. Meanwhile, the war stories of failed transformations were often packaged and retold as “successful case studies.” These companies were just going through the motions – focused solely on doing Agile rather than being agile. For them, it was about adherence to a process, replete with layers of hierarchy, nested features, and quarterly release plans known as Program Increments. In spite of the terminology changes, these implementations of Agile looked a lot like Waterfall. The former “process experts” wanted to create a checklist for every scenario a team might encounter, in a futile attempt to eradicate the thinking from knowledge work.

Something has to be done, I thought. Those of us who have been part of a mature implementation of Agile must show the way and light the path for others. I decided to lead by example and went on a personal crusade to get back to Agile basics. I wanted to explore the essence of agile as a verb, not as a noun. To embrace adaptiveness in pursuit of higher value, by lowering the cost of change. Not to add complexity through layers of process, but to reduce it. I didn’t want to force adherence to a set of practices, but instead sought to use empirical evidence and collapsed feedback loops to inform how company practices and products should evolve.

It was during this time the Scrum Alliance reached out to me and asked if I would be interested in participating as an instructor in the Scrum Foundations pilot program. The goal was to develop a four to eight-hour course that would focus on the basics and serve as an introduction to Scrum prior to people attending other role-based training. The timing was uncanny, given my newfound personal mission. Here was an opportunity to help others embark on the same “get back to basics” journey that I was on.

If you trace back through the Agile movement, I believe things began to go awry in 2010. This is when the conversation shifted from simplifying an organization to scaling Agile, so it “will work in a large, complex, matrixed environment.” Most Agile adoptions I see move organizations in the wrong direction — with a focus on scaling instead of descaling — and there are few people in the company who realize how detrimental this truly is. The problem being that you can’t solve complexity by adding more complexity. This merely increases the odds of failure by expanding the number of potential failure points within the system. Instead of adopting Agile to become more adaptive, most companies adapt and redefine Agile until it matches them. In the end, what has been transformed?

I often hear the adage, “You shouldn’t scale Scrum until you’re doing Scrum, otherwise you’re just going to scale your problems.” But how many organizations are actually doing Scrum? How many Development Teams deliver working software every sprint? How many Product Owners actually own the product, or are they business analysts with a glorified title? How many Scrum Masters have actually mastered Scrum?

If you ask me, I think it’s high time we get back to Agile basics. Learn Scrum as it was intended, not as some big-box vendor — or your organization’s PMO — interpreted and redefined it. If you’re just starting your Agile journey, put your best foot forward. If you’ve been on the journey for a while but could use a reminder of what it’s really about, then go back to where it began. The well is deep, and there’s a lot to learn that still awaits beneath the surface.

Sometimes, the way forward is back.