Everyone Fails: What Has Failure Taught You?
In the Agile Mentors Community, we asked members to tell us about a time they failed with their careers and what they learned from that experience. We got a lot of admissions of some pretty big failures, but most people were grateful for what they’d learned and in the end it helped them to be even better agile practitioners.
Validate Your Market
Mike Cohn kicked off the discussion by sharing a story of a failed company that he made the mistake of joining. The failure was so big that it was the last company he worked for as an employee.
During his interview for his role as VP of Software Development, the CFO said that his biggest concern was that there wasn’t a market for their product. The company sold exactly 70 copies of their high-priced software and then sales stopped completely. It turned out that there was only a niche market of exactly 70 scientists and all of them already owned the product!
“That company taught me the importance of validating your market. No matter how much you think you know about what your users want, you may not be right. This Chief Scientist knew what his audience wanted but didn’t validate there were more than 70 of them in the world,” Mike said.
Surrender Your Position
A business analyst member from Montana chimed in saying, “I learn something from failing every day. One of the things I’ve learned is that sometimes ‘surrendering’ is the ultimate key to learning and success.”
He added his own story about trying to help a business subject matter expert write user stories. This person refused to listen to his advice on writing epics and stories and resisted anything to do with agile. Initially, he wanted to teach the SME the ‘right way’, but decided to just surrender and see what would happen. And the result was what he expected: The requirements caused a crash and burn and the team failed to deliver what the business leadership wanted.
“By ‘surrendering’ and not fighting what the SME wanted to do initially, we eventually all learned something, and maybe next time we’ll all be on the same page,” he said.
Don’t Make Assumptions for Your Customers
A product owner from Bolivia shared her story. She was a product owner for a small part of a large product. Another product owner was making all of the big decisions, so she followed her lead, assuming she had taken the time to analyze the market.
She said that the product they delivered completely missed the mark! “[We were] providing tennis shoes to some babies expecting they’ll start to run,” she said.
The lesson learned: The needs of the daily work are completely different than what the market actually needs and analyzing market needs is a very important part of building a product.
Because we are constantly asking for feedback, it seems a lot of our designs are “failures” but now the team is building software where a change is no longer a “failure” but an “adjustment” and expected.
Building a Complex Product Can Lead to Big Failures
An agile coach from Texas shared her story about a big product failure! The customers and business leaders wanted to get a very complex software product exactly right with an all or nothing launch. The team suggested they release a minimally viable product to see if it works and then build in more options. The team was told no, and after building it out entirely, it didn’t work! The team had to go back to each option bit by bit to get it working. It was frustrating for the team, but they learned that building incrementally meant less overall rework. Sure, they had to tweak and adjust, but that wasn’t nights and weekends fixing buggy software!
We hope you learned some new tips and tricks for creating a steady flow of completed work on your team. For more great ideas on this topic and many more, we invite you to join the Agile Mentors Community. Visit https://www.agilementors.com for more information on membership.