“Perfection is the enemy of progress”
The quote is commonly stated in the world of startups. I’ve found it plastered on office walls and referred to during sprint planning meetings. But what does the quote actually mean?
I love the quote because it truly encapsulates a foundational principle of Agile development. At its core, the Agile process is about staying present and non-reactive, while honing in on the next step that’ll move a product forward. The Agile process forces us to put aside perfection for progress and helps us understand why “perfectionism” can be the personality trait that’s holding us back.
In this post, I’m going to walk you through a contrived example of the development of a new feature over the course of one two week sprint. I’ll highlight a few areas where the “perfectionism” mindset leads to adverse outcomes. My goal in highlighting these examples is to help you identify non-helpful perfectionism at the moment when it occurs and subsequently course correct.
Setting the Stage
Our post is going to feature three people:
- Bill — The Account Manager
- Stacy — The Software Engineer
- Aarti — The Product Owner
Bill, Aarti, and Stacy work together at The Made Up Company. We’ll follow them through a sprint where the goal is for Stacy to begin work on a new feature initially requested by one of Bill’s clients. Aarti’s job is to break the work up into logical buckets and decide on the best way to implement it in the product.
We’ll look at the sprint through the lens of three meetings. The sprint planning meeting before the sprint gets kicked off, one of the mid-sprint standups, and a retro at the end of the sprint. During each meeting, we’ll highlight key conversations and decisions and demonstrate how they can become wayward due to various forms of “perfectionism”. Let’s go!
Sprint Planning Meeting | Thursday before Sprint Kick-Off
We begin at the sprint planning meeting. Aarti, Bill, and Stacy are meeting to decide on what work should be prioritized for the upcoming sprint. Bill lets the team know that one of his clients has made a feed of their sales data available to The Made Up Company through an API.
Bill proposes building a new feature in the analytics portion of the product that uses the newly available data to report on the financial performance of each of the client’s products.
The idea is a good one, and Stacy and Aarti are excited. The Made Up Company had been trying to convince their clients to make sales data available for several months and Bill’s proposal represented a big win for the company. Stacy asks a simple question, “Are there any other feeds of data the client is willing to make available to us?”.
Bill lets Stacy know that over the next year the client would be making 4 more feeds of data available. In the excitement of the news, Stacy, Bill, and Aarti spend the next hour discussing the numerous different features that they could build with these new data feeds. The imaginary new features are exciting to discuss as they represent the future potential of the product and company.
Aarti suddenly realizes there are only 5 minutes left in the meeting. She hastily creates a ticket titled “Ingest new client sales data”, assigns it to Stacy, and the team moves on to their next meeting.
Let’s pause.
“Perfectionism” takes on many different identities. In this case, it took on the form of imagining a future utopia. The team spent a large percentage of a sprint planning meeting discussing features and data feeds that didn’t exist yet and wouldn’t exist for several months. It’s a natural (often exciting) tendency to discuss what could be, or what will be. Startups are inherently stressful and chaotic making it fun to talk about a future state where everything is “done” and “perfect”.
It’s less exciting to discuss what needs to happen right now. The topics are more mundane and often come with problems to navigate. Yet it is by focusing on the now that we drive the product forward.
This doesn’t mean one should never discuss and dream about the future, but it’s probably best left to discussions that aren’t hugely important in the execution of a sprint.
The fall-out from the team’s pontificating? The software engineer Stacy is left with a high-level, ambiguous ticket that doesn’t accurately capture the breadth or depth of her work. Let’s see how that impacts her ability to work effectively.
Mid Sprint Standup| Friday of The First Week
Bill calls Aarti 30 minutes before standup occurs. His client would like the new feature to be built out within 4 weeks. The client states that the extension of their contract is heavily based on the presence of the new feature.
Bill asks Aarti “I would love to see a working demo of the new feature by the end of next week, is that possible?”. Bill also states that his goal is to take screenshots from the demo and share it with the client to keep their interest high.
Aarti feels as if the timeline is rushed but doesn’t want to disappoint Bill or the client, so she obliges. Without a ton of information to run off of, she creates two new tickets for Stacy, “Sales Analytics-KPI Calculation” and “Sales Analytics-UI Development”. She adds them to the sprint. Feeling the heat, Aarti lets Stacy know during standup that these new tickets are “extremely important and must be done sooner rather than later”. The 15-minute standup ends and the team moves on.
Let’s pause.
As you’re reading this you might find Aarti & Bill’s behavior frustrating. How can they not see that adding large buckets of work to the sprint in the middle of it doesn’t make sense? How can this outcome be the result of a 30-minute call?
“Perfectionism” takes on many forms. In this case, it is “wanting to appear perfect to a client”. Rather than pausing, taking a breath, and having a working session to truly scope out what a reasonable MVP would be, Bill & Aarti give in to the pressure they feel from a client call and behave reactively. They add work mid-sprint. They don’t appropriately scope things out. They commit to an unrealistic deadline. Pressure and anxiety create mistakes.
Bill & Aarti could have avoided their mistakes if they were willing to appear “imperfect” in front of the client. Rather than committing to having “screenshots from a demo” for the client within a week (a cool but completely unrealistic goal), Aarti & Bill could have committed to:
- Weekly updates to the client on feature progress
- Being able to share a timeline on a demo/feature availability after they sit down to work out the details.
- Joint working sessions with the client to iron out business logic and receive feedback.
You’ll notice that none of the 3 commitments above need to involve Stacy initially. Leave the sprint alone!
Let’s see how Aarti & Bill’s reactive behavior impacts the sprint through Stacy’s lens.
The Sprint Retrospective| End of The Sprint
After the sprint is complete, Aarti, Bill, and Stacy huddle back together to complete a post sprint retrospective review. To Aarti & Bill’s surprise, no tickets have been completed yet all three are in progress. “What went wrong?” they ask Stacy.
Stacy, known for her direct and honest communication style lists three things:
- The initial work wasn’t scoped out appropriately. Stacy had to meet with Bill several times over the course of the first week of the sprint to iron out details of the new data ingestion including API credentials, end-point documentation, rate-limits, and more. She didn’t get to start on the true data ingestion until mid-sprint.
- When Aarti created tickets mid-sprint for Stacy and emphasized that the work had to be done by the end of the sprint, Stacy pivoted her approach. Knowing that she wouldn’t have enough time to ingest real data and build out the analytics features, Stacy decided to pivot and create dummy data so that she would have something to display in the analytics features. Creating the dummy data proved to be more work than originally expected and the analytics “feature” ended up being not build out enough to demo in front of the client.
- Because Stacy pivoted to working on the analytics features mid-sprint, she did not have time to truly complete the real data ingestion, thus it did not get done.
Overall, not a great sprint for the team!
The pursuit of perfection often comes from a place of ego and leads to chaotic, non-iterative work. How did this manifest in our product owner Aarti?
In the initial sprint planning meeting, Aarti got distracted with the discussion of future work (an egoic high) and failed to appropriately scope out the data ingestion ticket(s) with Bill. If the two of them had aligned on the credentials, rate limits, documentation, etc. before the sprint several meetings between Bill & Stacy could have been avoided.
Post client call, when Bill came to Aarti with the request to accelerate the development of the feature and add in another step (the quick creation of a demo) Aarti came from a place of fear of disappointing the client (an egoic low) and let that fear dictate her communication with Stacy.
The end result? Nothing meaningful got done during the sprint and the team is left with a few quarter-done tasks and little re-useable work.
Perfection is a destructive concept. The promise of it makes us feel good and the fear of not living up to it makes us feel bad. When we let it dictate our work the work becomes frenetic. Too much freneticism leads to frustration and burnout.
As product owners, we must accept that perfection is just a concept. It doesn’t exist in the real world. The chasing of perfection does not drive sprint velocity and mostly serves to distract and stress out the engineering team. What really drives sprint velocity is:
- Clearly defined, manageable buckets of work
- Fewer meetings and more uninterrupted time to get into a state of flow
- A calm environment that promotes clear, creative thinking
When engineers are able to start each day with a manageable, non-changing, list of tasks that are clearly scoped they can more easily focus and actually get the work done.
So the next time you feel yourself seeking out perfection, take a deep breath and focus your time on finding that next iterative step forward.
Till next time!
Arjun Arun is the Senior Manager of Product & Analytics at Curation Health, a healthcare technology startup. Outside of writing Python code and obsessing over the current sprint, he loves running, reading, and the occasional craft beer.