Ever since our days in elementary school, we’ve been taught to fear failure. How many of us ever looked forward to going home on the day we received our report card and showing our parents the “F” we received for one (or more ) of our classes? Hopefully none of you ever experienced that, but was it because of the fear of failing that you did everything you could to ensure that you passed the classes you were taking?
Now think back to the days of the waterfall methodology in software development. Was there ever much worry amongst developers regarding failure of the project they were working on? Hardly… Most developers just did what they were told to do by the software architect, finished writing their code and threw it over the wall to the testers, and then went on to work on something else. Rarely (if ever) did they hear about how well customers liked (or didn’t like) the final offering since customers didn’t get their hands on the offering until months after the developers had finished writing the code, and there was typically a separate support team that handled any customer issues that came up after the offering was released. Additionally, most developers never interacted with customers (I even know of some organizations where developers were prohibited from talking to customers!).
Now, with the advent of Agile and DevOps, everyone is much more closely in tune with what customers think of your offerings – and this is a good thing! It clearly reflects the very first principle of the Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The key word here is “valuable.” How do you know what you’re delivering to your customers is valuable? After doing some initial investigation of the marketplace, discussing options with current and potential customers, and doing some brainstorming within the team on creative ways to try to satisfy the needs, the best way to determine if what you’re creating is valuable is to deliver it! Put it out there – and see how your customers react. But, what if they don’t like it? Isn’t that just a failure…?
If you’ve adopted some of the main tenets of Agile, you’re likely delivering new features on a regular basis with very short intervals (vs. putting out a big bag of features once a year like in the old waterfall days). This is the “continuous delivery” that the agile principle above is getting at. Thus, even if you find out quickly that your customers don’t like something you’ve just delivered, it’s not a failure! You’ve just gotten some important feedback that you can immediately use to determine what needs to be changed, or perhaps determine that the new feature needs to be removed altogether. Being able to get quick feedback from your customers, and make quick changes to address the feedback you get (even if the feedback is unfavorable), is how you succeed.
In sum, put out small features on a regular basis. This allows you to get immediate feedback from your customers regarding the value of the features that have been delivered, and use your continuous delivery capabilities to make quick changes in response to the feedback. Like I said, even if customers don’t give you positive feedback, the feedback is still important so that you can respond quickly with better value. This is not failure – it’s the road to success! Thus the popularity of the phrase, “Fail fast, succeed sooner!”
As always, please feel free to ask questions and share your experiences. We look forward to hearing from you!