Fail Fast - a real life story

Startups and established companies using the agile methodology have a mantra - "fail early, fail fast, fail often."  I've been a big champion for failing fast over the years and I even won an "award" at a previous employer for failing during an innovation day. 

One weekend, I logged onto my work email and noticed with dread that I had 100+ unread emails. At that time, I was only on one project and that project might have 3-4 emails a day.  I quickly noticed they were a similar type of email but were unique to each of the 100+ records that this project is focused on.  I also noticed that these messages only went to internal staff - whew!  This project was launching the final phase and I just configured the messages for the external recipients. 

I quickly turned off the notification and made a note to reach out to the support team on Monday to determine what additional criteria might be needed on this notification.  All 100+ records did not satisfy the criteria from Friday night to Saturday morning. I also composed a quick message to the internal staff members that also received 100+ emails in their inbox assuring them we would fix the issue and to ignore the notifications. 

This moment was not the only "fail fast" example on this year-long project.  After multiple weeks of reviewing and cleaning up data from multiple sources, I finally imported the data into the system.  At the weekly project meeting, I found out that the data I was given was not the correct data.  Another example of failure came as we tried to generate a document for each record in the database to capture a snapshot of the record.  We ran the process and started to attach the documents to each record.  A colleague noticed that each document had the same data on it, which was not what we expected.  It turned out you cannot generate these documents in bulk, you needed to generate the documents record by record.

All of the above moments had different levels of "failure" and frustration for the project team.  In each of the cases, we took a moment to acknowledge the failure and then addressed how we could adjust the workflow or the ongoing process so that the failure didn't happen again.  Society has a negative perspective of failure. This perspective can be hard to overcome especially when you are trying to gain the confidence of your team.  For me, finding the loopholes in the workflow or processes only makes the end product stronger.  

In this year-long project, we were fortunate to have almost every use case come up so that we could talk through the workflow and have a plan in place.  Were the workflows perfect on day one? - No!  But the missteps and miscommunications were minor and allowed us to iterate on the workflows and make them stronger.  

Embracing the "fail early, fail fast, fail often" mantra can take some time.  But "celebrating" a product's faults can only make it stronger in the end. 

What kind of "fail fast" moments have you had recently?