People love buzzwords—they help make you part of the conversation. Unfortunately, they can also make you look foolish if you really don’t know what you’re talking about.
When it comes to software development, Agile has become one of those words. In the last eight months, I have interviewed over a hundred product managers, directors, and others. All of them threw “Agile” out there as a part of the conversation: “Oh yeah, we’re an Agile shop, we gave up Waterfall years ago.”
Here’s the problem with that sentence, specifically the word Agile: everyone has his or her own definition of what it means. Agile has generally been a software development word, a repositioning of development away from Waterfall. But it’s also much more than that.
To understand Agile a bit more, let’s step back and understand what Waterfall software development is and where it came from. Waterfall is based on the idea of having requirements upfront, getting design and implementation after the requirements, and doing verification and maintenance at the end. This method was a carryover from manufacturing and construction, where everything had to be very well thought out and planned ahead of time, because even the slightest change would be hugely expensive.
In these situations, the notion of a Waterfall approach makes perfect sense. If you’re going to build a bridge, you better not start without knowing where the bridge is going to connect on the other end, and you better have a huge amount of specifications for everything. But for software development, where things move quickly, and the cost of adjustments are minimal, this type of development just doesn’t make sense.
That’s where Agile comes in. Instead of planning everything out in advance, Agile favors lots of small incremental decisions, and it can also adapt to changes throughout the process. There are lots of flavors of Agile out there: there’s scrum Agile, non-scrum Agile, kanban Agile, and hundreds of others. Then there’s the kind that unfortunately tends to be the one I hear described most often when people talk to me about Agile. It’s fake Agile.
Fake Agile is just that, it’s fake, it’s not even close to what Agile is meant to be. Fake Agile is a company’s attempt to mask Waterfall software development.
In any kind of Agile, the massive specs that Waterfall requires are replaced with “user stories.” But in fake Agile, the product owner has to spend a massive amount of time making sure that upper management signs off on the user stories, and also that the user stories have “acceptance criteria.” (For instance, we will build a house, and the house should have four windows and each window should open and close, and the house will have a door, with a doorknob, that opens from the inside out, and the lock should be double bolted.) Oh, and each user story must have a “time to completion” so that upper management knows when everything will be finished.
If you just read the above and said, “yup, that’s how we do Agile,” then I’m sorry to be the bearer of bad news, but you are surrounded by fake Agile, and you’re really in a Waterfall shop.
A fake Agile environment is tragic (and I speak from experience). It’s destined to fail: no one can know all of the aspects of a product (design, usability, functionality, and value) before any work has begun. Most important, it removes the ongoing conversation between developers, product owners, and the most important person in the process: THE USER.
Agile is not just another buzzword, and it’s not just about software development. Agile is about conversation, it’s about feedback, it’s about adjustments, and ultimately, and most important, it’s about innovation. The best products I ever built were built by making sure that I had the right people as part of the process. As the product owner, you are responsible for the value of the product, but you cannot bring a product to life with having a developer to make sure the product is feasible and a designer to make sure the product is usable. The three of you should be focused on thinking about how a product might work and getting something in front of users as soon as possible to get their feedback.
Being Agile and building great products is about making sure that you have four perspectives always accounted for; value, feasibility, usability, and demand (in other words, do users want it). Conversation, feedback, adjustments, and innovation are how you will be able to build a successful product, impress upper management, and succeed as a product owner.
This level of understanding of Agile has been so successful that more and more companies are starting to speak about Agile as more than just software development; they view it as a way of running a business. Companies understand that having a one- or two-year roadmap only works if you are willing to be flexible in what it is you are looking to accomplish. You may want to focus on internationalization in Q4, but halfway through the year you realize that there is a larger opportunity to continue to expand domestically. Being able to make this change midstream is fundamental for success, and failing to make this adjustment could be a huge mistake for the company.
Planning is good, knowing where you want to be is better, but being able to adjust along the way is the best.
