Minimum Viable Development Team

Imagine that you’re tasked with recruiting a development team to build a new product. What would that team look like? How big would it be? Who would be on it?

Well, you’d probably want a team that’s lean, efficient, self-sufficient, and highly productive. You’d also probably want a team large enough to deliver whatever is needed, but not larger. In short, what you want is a Minimally Viable Development Team.

I Want My, I Want My, I Want My MVDT

My MVDT would consist of 10 people:

• 6 software engineers
• 2 product engineers (project managers, business analysts, UI/UX designers)
• 1 test engineer
• 1 devOps engineer

Developers

Let’s start with developers. First off, why six? In my experience, 3 dev pairs* are just enough to make progress, absorb unexpected interruptions, continually clean up the code base, and most importantly keep up momentum. I find that it’s just too easy to break momentum with a smaller team.

Why is momentum so important? At the risk of stating the obvious, it’s important because people yearn for accomplishment. Nothing motivates quite like seeing stories fly off the backlog at a healthy clip. It’s invigorating and infectious, it creates a virtuous cycle of productivity, and it’s a lot of fun.

For my six devs, I’d have one tech lead, two senior devs, and three devs. Everyone is expected to write great code. Seniors are additionally expected to make major positive contributions to the code base (pioneering new technologies, spearheading significant refactorings, implementing necessary performance/scale optimizations, mentoring others, etc).

The Tech Lead is expected to do everything that Senior devs do plus he has the responsibility for the overall health of code. This means that he has to worry about things like code metrics, keeping the stack current and sane, and guiding the team through the trade-offs inherent in architectural decisions being made. He also gets the deciding vote in case of conflict.

Product Engineers

Next, let’s talk Product engineers. They’re primarily responsible for uncovering and refining user needs, expressing those needs in form of user stories, and verifying that the final product meets those needs. (I say “primarily” because ideally everyone on the team should be concerned about this sort of thing.)

Product engineers should have the necessary skills to uncover user needs: user interviews, prototyping, hypothesis testing, etc. Product engineers should also have the necessary skills to translate a need into product: analysis of complex business domains, information architecture, user interface design, visual design, and so on.

Finally, product engineers should have a complete understanding of the product. They should know the feature set inside and out, understand how different parts of the product work together, what external dependencies exist, etc. They should also know how various user personas interact with the system.

Test/DevOps Engineers

Last but certainly not least, we have the Test engineer and the DevOps engineer. Now, you can argue that the responsibilities covered by these two roles should be owned by everyone. After all, shouldn’t everyone test? Shouldn’t everyone worry about infrastructure and build/deployment pipelines?

Of course they should. For instance, testing should be deeply ingrained into the development processes. Devs should be writing unit and integration tests as they go along. Yet I believe that it’s still important to have a dedicated test engineer for two reasons.

First, test engineers provide a perspective which devs typically lack. I find that too often devs tend to think happy path and have a tough time uncovering edge cases and boundary conditions inherent in their code base. On the other hand, test engineers are great at finding ways to break software, typically via unexpected interactions and untested assumptions.

Second, the types of tests written by test engineers tend to be at a higher scope than those written by devs. While devs are typically concerned about verifying smaller units (via unit tests) and their immediate interactions (via integration tests), test engineers are usually concerned with verifying paths through the application (via functional tests).

DevOps is another area where it helps to have someone waking up everyday thinking about it. It’s good to have someone focused on optimizing the machinery which underlies the development process. It’s important for someone to constantly work on bullet-proofing the deployment pipeline, optimizing the use of infrastructure resources, maintaining the build system, setting up proper monitoring/logging/backups in production, and so on.

And yes, devs could do most of this as well. However, I find that even with the best intentions, devs end up doing the bare minimum to get things rolling, but no more. Optimization of the type I described above is rarely top of mind for devs because they’re (rightly) focused on feature building.

Final Thought

The Minimally Viable Development Team I described above is unlikely to work for everyone. It makes a lot of assumptions about the culture, the processes and practices used, and, quite frankly, the caliber of people involved.

It also assumes a certain level of maturity in the product vision. In other words, I wouldn’t throw a dev team of 10 people on an unproven idea because searching for a product-market fit with a full dev team is hugely wasteful.

* I should note that this setup obviously reflects my bias for pair programming. That said, even without pairing, you need a critical mass of devs to move things along.

You may also like:

• The One Million Dollar Team
• You Can’t Teach Height
• A Social Developer
• Developer Tribes
• Reading for Devs

• agile
• development
• people

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!