Agile Gone Wrong

Most people will agree that the adoption of agile is now mainstream. This adoption is rightfully so, as agile can be an excellent framework for building software. This being said, I’ve noticed a few common mistakes when product teams are adopting agile, most notably:

• Focusing on velocity, with almost a disregard for quality
• Only building, and forgetting about the measure and learn principles

These are not small issues. The benefits of embracing agile is that you can bring valuable products to market quicker through user validation. I’d argue that making these mistakes will actually slow a team down in the long run.

Don’t Move Fast and Break Things

Agile followers have almost certainly heard Facebook’s famous mantra ‘Move fast and break things’. Seems like a great strategy, after all, the goal of agile is to ship product faster, right?

The issue with ‘Move fast and break things’ is that it gives the impression that velocity is more important than quality. This is extremely short-sighted. Cutting corners on quality may lead to short-term velocity, but it also builds a mountain of technical debt that will need to be addressed at some point.

What a lot of people don’t know is that Facebook recognized the issue with their famous mantra, and decided to change it. They removed the ‘break things’ portion, and replaced it with basically the opposite ideology of ‘stable infrastructure’. There have been reports that the reason for this change in motto is due to the code base of the product eroding, which in turn slowed product development in the long term.

“We used to have this famous mantra … and the idea here is that as developers, moving quickly is so important that we were even willing to tolerate a few bugs in order to do it. What we realized over time is that it wasn’t helping us to move faster because we had to slow down to fix these bugs and it wasn’t improving our speed.” — Mark Zuckerburg

Product teams focusing on velocity may argue that in the future they will reach a place where they have time to circle back to fix technical debt. This is never true, there is always pressure. A team needs to consciously decide to make stability a part of value delivery, otherwise lack of stability will become part of the team’s culture.

Problems Compound

When a product is young, velocity is important. It can become easy to focus on building new features, as this attracts new customers. New customers will likely request more new features. In order to keep up with demand, quality may be sacrificed to get these features to market.

Ignoring quality simply delays issues. The longer the technical debt is left, the more risk a product has of unplanned problems. It will also result in a shaky foundation for the product. At some point products will want to scale up, and this is very hard without a stable foundation.

The larger the product grows the more important monitoring technical debt becomes. As you grow and scale, the product naturally becomes more complex. This is because there are more pieces of the puzzle working together. Seemingly small bugs may end up spiraling into larger issues, which leads to unplanned time spent on fixing bugs.

Build → Measure → Learn → Repeat

The reason that agile is effective is not simply because it allows you to build faster, its because it allows you build faster by validating, learning, and pivoting faster. The way to validate and learn is by getting in front of customers.

The longer a team goes without validating (ie. talking to customers), the higher the risk of building features that do not actually add value to the customer experience. It also indicates that the product is becoming development driven and not market driven.

Most teams seem to be transitioning to operating in a scrum format: releasing in sprint cycles, and claiming that this alone is making them agile. However, there seem to be a lot of teams that still wait until a feature is completely built before getting customer feedback.

Customer feedback should be brought in as soon as possible. Show them a mockup, show them a sketch on a napkin, or simply ask them questions. Products are built for the user, not for the product team. In agile, accountability is key, and everyone, including the development team, is responsible for validating work.

If a team waits until the feature is complete before gathering customer feedback, the team is pretending to be agile. It’s taking a mini-waterfall approach, but adding in scrum meetings. This can potentially be a detriment, because scrum includes a lot of sprint meetings — standups, retros, planning, release, etc— which can actually slow you down if you are taking a waterfall approach.

The reason scrum has a lot of meetings is to ensure that a team remains agile by incorporating customer feedback as soon as possible, and making on the fly pivots. If a team is taking a waterfall approach, and isn’t gathering customer feedback, the goal should be to get the finished product out the door, and more meetings will slow this down.

Take a look in the mirror and be honest with yourself on the approach your team is taking. An agile approach is not the end-all-and-be-all of development methodologies. Yes it is probably one of the best, but products have succeeded taking a waterfall approach as well. This is especially true for products in the later stages of the product lifecycle, or very simple products.

Slow Down to Speed Up

One of the mental models that Warren Buffet and Charlie Munger have used to grow Berkshire Hathaway into the most successful investment firm in history is to fix problems as they arise. As Warren mentioned in the 2018 Berkshire Hathaway meeting:

“Charlie says an ounce a prevention isn’t worth a pound of cure, it’s worth a ton of cure, and he’s pushed me all my life to make sure I attack problems when they surface,” — Warren Buffet

There’s a reason it’s called technical debt, debt compounds. Issues start to pile up, and combine into larger issues. Eventually a product has a bunch of small issues, which not only can become overwhelming to address, but it also makes adding new features messy.

Ignoring problems also takes away a learning opportunity. Mistakes are typically due to human oversight. If the mistake is not caught in a timely manner, similar mistakes are likely to keep happening because the person committing the mistake hasn’t had a chance to learn from it.

Slowing down to evaluate the mistake when it happens will allow a team to be faster in the long run. You’ll be amazed at how many of the mistakes you discover were completely avoidable. People learn from mistakes, and going forward, the likelihood of a similar mistake is much lower.

From a leadership perspective, an over-focus on velocity gives the team the impression that continuous improvement is alright regardless of the consequences. Advocate for around 20% of your time to be spent on proactively fixing technical debt, and learning. Set a precedent that value includes stability.

Balance is the Key to Success

Find the balance that works best for your team. If you have technical debt piling up, you aren’t taking enough time fixing things. If you are taking forever to ship, you can likely benefit from speeding up.

Just be aware of the risks. Too much focus on velocity can result in bad code and a poor foundation for the product. Overly focusing on quality, you’ll never ship, and never make money. Either way you increase the likelihood of creating an unsuccessful product.

If your product is in a stage of the life-cycle where waterfall would work better than agile, embrace waterfall. Work towards the best version of waterfall that you can. Don’t try to mash waterfall and agile together just because everyone is using agile. If you are a newer product, agile will likely be your best approach. Just make sure you measure and learn as rapidly as you build.

Thanks for reading!

If you liked this article check out a few of my others, and feel free to connect with me on Twitter.