When a New Feature is Coded, Who Decides That It's Ready to Go Live?

Every day online and offline, CEOs, CTOs, sales leaders, marketers and engineers connect with each other within First Round's Community to learn. They share best practices and give advice freely — and it helps everyone make better decisions, grow and move forward.

We're taking inspiration from this ask-and-answer format to surface the most common questions from inside of our companies and then get the best answers from subject matter experts both internally and externally. We're calling this new series "1:1" and we'll cover everything from engineering to marketing.

To that end, here is our very first 1:1 featuring an answer from Edward Hieatt, COO at Pivotal Labs. He's been a collaborator of ours since he joined us for a session at the First Round CTO Summit in 2012.


Q: When a new feature is coded, who decides that it's ready to go live? Typically QA people make sure the feature works as spec'd. But that requires a well-written spec. Who has time? And that's so non-agile. A QA person could do it, or programmers can check each others' work, but it does seem that ultimately it's the person who has the product vision who should be the one saying "Yes, that does what it's supposed to and it doesn't do what it's not supposed to.

A: Ideally, determining when a feature is ready to go live is a decision that should be made by the Product Manager - the person who came up with the requirements for the feature in the first place.

Here’s how it works at Pivotal Labs. The idea is that in the steady state of product development, rather than using a traditional QA team that relies on a written specification, we integrate the Product Manager (PM) with the development team, and employ strict Test-Driven Development (TDD). The result is a huge improvement in efficiency and productivity.

First, features are defined in the smallest possible increment that represents concrete business value, called stories. Stories are written and prioritized by the PM. Since stories are narrow in scope, the PM can review a story fairly quickly by playing with the new functionality, checking that it behaves as he/she intended. Typically stories take a day or less for a pair of engineers to implement and roughly 15 minutes for the PM to accept. It’s also common for the PM to “look over the shoulder” of the engineers while they’re building it to increase the chances that when the engineers think they’re done, they really are.

Second, our developers practice strict Test Driven Development. This means that as they implement a story, they write unit and functional tests that verify that the application behaves as the PM describes. A piece of code isn’t done until the test passes. And while the PM is reviewing new features, the TDD process ensures that nothing else breaks.

Once the code is checked in and all the tests are proven to pass, the feature is “delivered” to the Product Manager in a staging environment. The PM makes the final decision to either accept or reject the feature. Only after the PM's acceptance is the feature considered “done” and ready to be put in production.

In this environment, a traditional heavyweight QA process doesn’t pull its weight. It’s not that it wouldn’t be valuable - it’s just that it’s only slightly valuable in this setup, and the amount of time spent on it costs too much to justify. Instead, QA resources are best employed using techniques such as exploratory testing. Of course, if a product has a huge audience and a large amount of new functionality is about to be deployed, some semblance of a traditional QA process makes sense.

 

As Chief Operating Officer, Edward Hieatt oversees all operational aspects of Pivotal Labs’ consulting business, including engineering, client services and the company’s open source product strategy. In this role, he drives revenue growth and performance, and is responsible for managing all regional offices across the U.S. and overseas.

Get Actionable Insights in Your Inbox

Start Reading