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.
Top 10 Agile development myths
Learning Agile best practices