As we create products at Corso, all we want to do is work together, have fun, and create products our customers love.
Because of this, here at Corso, we intentionally don't adopt the word Agile.
I know. The Agile loyalists out there think Agile is the only viable option and that anything else is a death knell for software development.
"If you're not Agile then what are you?" they say in attempt to demonize the ultimate strawman. "Waterfall?"
My casual answer is always the same, "We work together, have fun, and create products our customers love."
And therein lies the rub. Today's implementation of Agile, in our opinion, actually inhibits these simple goals...
...especially the fun part.
Agile = Scrum
I've actively participated in most of the popular Agile frameworks. In this case, when I say we don't adopt Agile, I am really referring to Scrum because most people think they are one and the same thing...
...which is the heart of the problem.
I've had conversations with Agile Coaches that went something like this:
"Seems like this is just a bunch of forced recurring meetings," I say.
"It's Scrum," they reply.
"It doesn't seem very agile," I push back.
"Scrum is Agile," they say with a straight face that would make any professional poker player proud.
"Uh," I'm obviously confused. "Your implementation of Scrum, or SAFe, or LeSS or whatever-you-call-it is the least agile thing I could possibly think of."
"Well, your boss told us we need to be Agile so this is what we are doing," they demand with all the command-and-control that Agile is supposed to prevent. "You better get on board."
I can't get on board
Part of my inability to "get on board" with Scrum is the cult-like vocabulary with words like scrum master, artifact, grooming, and ceremonies...
...it's kinda weird.
But mostly, I've yet to experience a scenario where the Scrum process didn't evolve to become more important than the products themselves, an outcome which completely removes the collaboration, creativity, and purpose of the product.
As one of my colleagues once wryly stated, "The process is the product now."
I realize some companies may understand agility in scrum and it is working great for them. But for most, 20+ years after the publication of the Agile Manifesto, today's Agile best practices have become so unagile as to completely erode the principles they claim to be founded on.
"We do standups and have sprints. We are Agile," so many still say in job descriptions and recruiting campaigns without understading a single agile principle that Scrum is founded on.
As Dave Thomas, one of the original signers of the Agile Manifesto, said almost 8 years ago, “The word 'agile' has been subverted to the point where it is effectively meaningless and seems to be an arena for consultants and vendors to hawk services and products...let’s abandon the word agile to the people who don’t do things.”
And it has only gotten much worse in the last 8 years.
No hard feelings
Three of the four Corso founders have deep product and Agile experience on our résumes. The fourth member, our head of growth, is a product guy at heart. In this regard Corso is a unique company.
But when we first started in our product roles, we had to carve our own career path based on passion, instinct, and a desire to deliver something great. We had never heard of Scrum. In fact, we had no knowledge of what we were doing other than anything and everything to make the product successful. All we really had was one article written by Ben Horowitz, and we were constantly defending the question, "What do you say you do here?"
Then Agile -- and in particular, Scrum -- started to spread. With Scrum there was an official role on the development team kinda related to what we were doing as product professionals. It was called the Product Owner. For the first time we felt like our existence was validated! We can thank Scrum for the explosion of Product Manager and Product Owner job titles over the past 15 years.
The Scrum eclipse
So many great products have been built with Scrum. It has served the advancement of technology in amazing ways. Yet it always comes down to the same simple question. Does the process support the people or do the people support the process?
Usually the answer to that question is determined by the talent and influence of the person leading your products, regardless of their job title (CEO, Head of Marketing, Product Manager, VP of Engineering, CPO, etc). The person leading the products should inspire people to work together, have fun, and create products customers love.
"Follow me," a good product leader says, using the products (not the process) as a guiding light for everyone to see.
We can all feel it.
We can tell the difference when a product has been built by a culture of creative people versus a product that has been built by a culture of forced process. Without good product leadership, the products will always devolve into a rote process. And when the Scrum framework is allowed to usurp product leadership, like a solar eclipse, Scrum will completely block out the the energy, momentum, and life of the product.
Things go dark fast.
The products stop shining.
Agility is for products, not process
Good product leaders obviously need to understand agility in product development. They need to have enough practical experience to comprehend the concepts of unknown work, early validation, and ongoing iteration. Good product leaders build a culture of agility around the products. So it should go without saying, then, that in order for an Agile framework like Scrum to work effectively, it also needs good product leaders.
Unfortunately though, Scrum is no longer a framework for product people. What once was a simple structure to help product teams with agility, has been hijacked by project and process people. Scrum is now their way to justify a project management agenda. And having full-time process people – consulting and hanging around the office – gives them way too much time to conjure up unnecessarily complicated processes, making things less and less agile as they go. After all, that's what they feel their job is, and that's how we end up with monstrosities like "scaled agile" in the forms of SAFe or LeSS.
So sadly, despite it's original intentions toward agility, the Scrum framework has become something else entirely. It has become what Dave Thomas expressed, a framework for the people who don't actually do the work of product development.
So what's the consequence of an Agile framework not being agile. Well, it's confusing, exhausting, and mind-numbing. Not exactly the words we want to describe our product culture. So rather than beating our heads against the Scrum wall, trying to explain to people that Agile isn't agile, it is so much easier to say, "We don't do Agile. We don't do Scrum. Join us and we will teach you how to work together, have fun, and create products customers love."
That feels good, doesn't it?
Our guiding principles
Our guiding principles are simple. They are mostly based on the original Agile Manifesto along with a few things we have learned through practical experience over the years.
We believe in these principles. They are ours. We live them. And as always, our goal as product creators — which we all are here at Corso – is to work together, have fun, and create products customers love.