To Kick-Start Your Agile Project, Begin with a Minimum Viable Team

Imagine you want to build a new product, with a new team and a new project.

Of course you are going to use agile. You want the team to be self-managing, to be largely autonomous, and to start by delivering a minimum viable product (MVP). The MVP may focus on producing a small product meant to probe the market and add to our understanding of customer need, or it might produce the smallest set of features that will provide a fully functional product.

For now, the direction we take with our MVP doesn’t matter, as we have more pressing challenges: Where do we begin? How many people need to be on our team? What skills are necessary? How long should this project last? And above all else, how much will it cost?

I know of one European bank that frequently spends a year getting ready to begin work. Another company I met had been talking about and planning to get started for five years. Imagine spending all that time getting ready to build something! Perhaps that explains why so many projects are late.

Let's explore the traditional, rational way to start work. Then let me suggest a better way: the minimum viable team.

The Typical Project Beginning

Most projects start by asking an analyst to consider what requirements need to be addressed for a particular market opportunity. The analyst probably comes up with a list of features, and hopefully also a statement of the expected benefits, customers, and stakeholders. An architect gets involved to recommend technology and help create a software design. The technology and design often dictate the skills a team will need.

Information on the business opportunity, necessary technology, the design, and staff needs is pulled together into a business case by a project manager. The PM often brings financial discipline to the project and forces cost to be a major consideration. Then the PM, architect, and business analyst decide on staffing together. Do we need a big team or small team to get to market? Is a database specialist required? What about a user experience designer? How many programmers? How many testers?

The business opportunity typically goes before a review body, which might grant funding or might knock the case back for refinement. (And if it gets knocked back, it might get revised and resubmitted.)

With a little luck, all this preproject work takes a few weeks. If you are unlucky, it could be months—or, as in the cases I described above, even years. Finally, you start to hire the team. Hopefully one or two of the preproject team members stay involved. Over the next few weeks, team members start to appear, and the typical forming-storming-norming-performing pattern plays out. Only after the team is fully staffed do you have a productive team.

But There’s One Small Problem

There’s a problem with this traditional, rational setup: This team isn't really autonomous or self-directed. The analysts have bequeathed them a requirements document and an end state, but the team has only a limited ability to change either of those. The architect created a design to follow, and that influenced whom to hire and what skills they would need. Similarly, the business case and plan produced by the project manager and agreed upon by the review committee has constrained the team’s agility significantly.

On one hand, this is good governance. The corporation has constrained what the team can do. On the other hand, this team is far from agile. If they were to suddenly find a shortcut to the end state using different technology, there are few incentives for them to use it. Lots of rework would be necessary to get such a change approved, and if the new technology only needs half the team and half the budget, there are good reasons for sticking with the original plan. Deviating from the business and technology plans given to the team also carries personal risk, as subsequent problems could be seen as stemming from that decision. Sticking with the plan is safer for team members because others can be blamed for problems.

Doing the preproject work, recruitment, and team formation all took time. During that time, the opportunity was changing. Competitors might also have begun work or even entered the market. Delay in starting work becomes a delay in delivery, which means lost value.

The Minimum Viable Team Alternative

An alternative to the above approach for project startup is to create a minimum viable team (MVT). With an MVT, you pull together a tiny team—only two or three people—as soon as you can justify a little seed funding. The team begins work immediately. Small budgets mean little risk and tight feedback cycles. The team analyzes the problem, explores the opportunity, and comes up with potential solutions. They will also begin implementing these solutions at the earliest opportunity.

Initial team staffing must include analysis and development skills. But rather than spending time considering what those skills might be by creating heavyweight requirements and a design, initial staffing is approximate and most likely includes an experienced analyst and an experienced coder. The team can do traditional requirements analysis if they want, but they should also use prototypes, proofs of concept, and models they can show potential customers. The team learns from analysis, planning, and building, and more importantly, they kick-start the feedback cycle and allow the team to test ideas in the market far sooner.

A small team will form, storm, and norm much more quickly than a large one and will reach peak performance far sooner. If things look good, the team will pull in more skills and people. The team will need to demonstrate a successful track record of both product discovery and product development to justify more investment.

Governance of a MVT looks more like venture capital than traditional corporate portfolio management. The MVT has a little money and a deadline: a month, three months, whenever the money runs out. At the end of that time, they must show what they have built and propose the next move. If things look positive, they get granted more time and more money, possibly enough to grow the team. If not, then it’s game over, and everyone moves on to something else.

Working like this gives the team more autonomy. It also avoids sunk costs: At each review point, the team shows what they have learned and built. Effectively backdating the project to the point where preproject work normally happens opens options and improves governance.

Keep Projects in Check and on Track

Traditional projects have a habit of becoming too big to fail. Large projects continue to attract more money because not funding failing work raises questions about how money was initially allocated. Such questions become threatening to those who initially allocated the money, thereby creating an incentive to throw good money after bad in the hope that everything will work out, resulting in sunk cost. Large organizations and government projects fall prey to this thinking regularly.

The MVT approach prevents this “too big to fail” problem because each piece of work is small, so no one team or project will threaten a career. Indeed, teams are almost expected to fail because they are working in risky fields.

MVTs have another benefit, too: Because teams get starved of resources, they cannot afford to do more than the minimum. Like at a start-up company, every penny must count. And because teams have minimal staffing, nobody needs to make work to justify their role.

To put it another way, if you want to build a minimum viable product, use a minimum viable team.