Manage Learn to apply best practices and optimize your operations.

Agile thinking: Failure is the new success

Agile thinking allows for mini failures along the way, leading to success.

Even when I'm not looking for it, I see evidence of Agile thinking everywhere.

On television, an American Express ad, championing success, features GoPro founder Nick Woodman talking about failure. "When I failed at my first business, I thought my dreams were over," he said, snowboarding down a steep slope like an expert. And then the voiceover: "Here's to the next generation of hacks, duds and failures."

The notion of failure as a prerequisite for success is yet another example of Agile thinking. Agile thinking rejects the old way of developing software, where, typically, no one acknowledged things weren't working until far too late in the game.

Because Agile teams release software in small increments and seek feedback, the Agile approach by definition allows for a bunch of mini failures along the way -- all as a means for getting to success. That didn't work? Let's try this instead.

In theory, Agile thinking lets teams experiment with ideas on a small scale. When the ideas don't turn out well, they move on and try something else. Teams aren't afraid to fail because they understand the so-called failures aren't epic. They're prerequisites for success. Team members have put their faith in a process that lets them change course until they achieve success.

But in reality, for most of us it's difficult to admit missteps, misguided ideas -- let alone failures. It flies in the face of human nature, our own egos and how we work in groups. And it requires us to admit when we're wrong, to others and ourselves, in a way that isn't always entirely comfortable.

And yet Agile thinking -- the idea that mini failures lead to success -- is a good approach for developing software, provided we can acknowledge our missteps along the way and change course accordingly.

Here are two common software development situations where plowing ahead is easier than admitting something isn't quite right.

Agile thinking: Getting requirements right

It's a common scenario. You're defining requirements for the application under development. Business stakeholders are taking part, but you don't really have enough of their input or time. Maybe you don't even have the right people. It's tough to be honest about this, but follow your instincts and speak up -- even when people more senior than you say things are good to go. Do we really have the information we need? Do we fully understand the application requirements? It's a difficult problem to solve. But if you're not there yet, speak up -- and get back to the drawing board for ideas on getting business executives involved in the process.

Agile thinking: Be aware of biases

Our own biases are notoriously difficult to identify because they operate on a subtle level. But gaining awareness of them can help signal when things aren't working and we need to change course. According to software quality expert Gerie Owen, biases can involve simple, technical things like bugs. You see a bug you've seen before. Instead of delving deeper to find the source, you automatically assume what caused this bug is the same thing that caused the last one. But you may be dealing with a very different situation, Owen explained.

Biases about people can also lead to trouble. Say for example you're working with a business stakeholder for the application under development and he stops showing up for meetings. You tell yourself: "That's so typical; he always loses interest." In your mind, your conclusion is a fact, but it's exactly your own bias at work. As test management consultant Johanna Rothman recommends, do the more difficult thing and ask him why he stopped attending. What you find out might get you to change course and ultimately deliver the right application. In other words, better to admit your mini failure now -- when there's still time for it to lead to success.

Failure to say something is not working -- even though Agile thinking guides us to do so -- would be the biggest failure of all.

Next Steps

Top 10 Agile development myths

Learning Agile best practices

This was last published in July 2015

Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How have your mini failures led to success?
Cancel
Absolutely, there is no shame in experiencing failures. Just learn from them and grow. Build on what works and change what doesn't. One thing that I really like about agile development is having a restrospective meeting after each iteration where everyone has the opportunity to bring up issues and ideas.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close