“Winners never quit”. It’s an old saying that has much truth to it.
Thomas Edison, the great American inventor of many gadgets and devices that are still very much in use today, was a shining example of someone who never gave up. Without his persistence, we may have never been blessed with important inventions such as the light bulb, the phonograph and the motion picture camera.
Some of Mr. Edison’s quotes are a testament to the power of persistence.
“I have not failed. I’ve just found 10,000 ways that won’t work.”
“Many of life’s failures are people who did not realize how close they were to success when they gave up.”
I’m not here to deny the power of dogged persistence. In many, if not most circumstances, persistence is the engine behind success.
However, I experienced an epiphany at work recently that made me rethink my views on persistence.
Sometimes the only way to succeed is to QUIT.
I’m part of a software development team that practices Agile. We have a product owner who helps to define and prioritize the work our team will work on. We have a scrum master (myself) who conducts daily standup status meetings and does everything he can to finish all the team commitments of a sprint.
For the past two sprints (2 weeks total), our team has been working furiously to try to get a microservice up and running in a full production server environment.
Some of you may be wondering what it’s taken two whole sprints to get a single microservice working?
After all, a microservice is nothing but an API that connects two endpoints together … what could be simpler than that?
That’s exactly what we thought. We all thought we could knock this microservice out of the park in a single sprint with time to spare.
Two sprints later, and we’re still struggling to get it done.
The crux of the problem is that word … “done”.
The way we’ve defined our acceptance criteria for our work, is directly affecting our team’s progress.
Our acceptance criteria for our microservice story states the microservice development can be considered done when the microservice, and all its relevant dependencies, is fully deployed and verified to work in our production environment.
The problem is that we’re struggling with the “relevant dependencies” piece of our agile story.
There are two aspects of our microservice requirements that our team has been struggling for the past two sprints.
- The microservice needs to live on a new data center environment
- The new data center environment needs full network connectivity to our other data centers
As part of a general IT directive to move existing and new in house developed software to our new data center in Las Vegas, we’re spending additional time and resources provisioning the new server with the necessary software and frameworks needed by our microservice.
Our microservice requires connectivity to two other data centers, in order to properly do its job.
And therein lies the biggest obstacle to considering our microservice “done”.
Our new datacenter does not have full network connectivity to the other two datacenters. And until that happens, we continue to struggle with the progress of our microservice.
At the end of our last retrospective, I had a very fruitful conversation with our product owner. We’ve all been feeling the pressure and getting frustrated that we haven’t been making more progress than we thought we should have.
And she asked a very insightful question. Why were we all killing ourselves, continuing down the path we’re all struggling with?
She essentially asked us if it’s worth considering QUITTING what we’re doing and figuring out a better way to get our microservice done?
And when the team stopped and thought about it, we discovered we could get our microservice to work, by removing a dependency on one of the data centers.
It wasn’t a LONG TERM solution, but in the short term, it would give us a fully functional, full production ready microservice.
Though I have been critical about certain aspects about scrum and agile, the one positive quality I can say about agile, which was difficult to accommodate in traditional waterfall development, is that agile recognizes that software requirements often change.
And that sometimes QUITTING and changing direction, will get you where you ultimately need to end up to succeed.