Last week I was in Holland helping a client with their agile adoption and digital transformation. When the subject of teams came up I started talking about Minimally Viable Teams. Yesterday I found myself writing an e-mail to the client expanding on the idea. And it seemed to me that the e-mail – or an edited version – was worth sharing here…
The idea of an Minimally Viable Team (MVT) is based on the observation that if a team is overstaffed then team members will find work for themselves – Parkinson’s Law.
Mix in Conway’s Law: the recognised phenomenon where team copy the organization structure they are in. So for example, if you have a database expert on the team the final design will use a database whether one is needed or not.
If one is aiming for a self-organizing, goal-directed, value-seeking team then making any decisions about the team, the software design, or even the problem before work begins is questionable. The more decisions that are made the more the team is constrained, the more the team is constrained the less it is master of its own destiny.
Further, those decisions made before work begins: one expects them to be rational, which means some pre-work is needed to understand what decisions are needed and make the decisions. That pre-work costs time and money. The more money that is committed then the more difficult (i.e. more career threatening) it becomes to reverse those decisions if things go wrong.
Some companies spend an awfully long time thinking and planning to do something: longer than it takes to actually do the thing. I once visited a company which had spent five years planning a particular project and not building anything.
Add two more things to this.
We know from experience that planning has rapidly diminishing returns. A little bit of planning creates great learning, but after a little while the rate of learning drops off. Very soon learning by doing becomes more effective, i.e. switch from thinking about what might be done to trying to do it.
This has never been truer than today – 2018: with the computing power and tools it is faster and cheaper than ever to build a prototype, a concept, an MVP, version 1, alpha version or whatever else you want to call it.
However, going to the other extreme and doing no pre-work doesn’t make a lot of sense either.
Enter the Minimally Viable Team: the team jumps to doing, all that pre-work is given to the team. They get to decide what is needed.
To traditionalists the team/project/product is launched prematurely but actually all we are doing is extending the start date backwards so that the pre-work is now part of the thing. By tasking the initial team with all the traditional pre-work the team becomes master of their own destiny again. And they can choose to approach the mission with a traditional approach (market research, architecture design, resource planning) or in an agile/digital fashion (build a small product and test it) – that is their choice.
The MVT idea is to “starve” the team and make them pull only the necessary resources as and when they need them. When organizations decide who (which roles) will be on the team in advance they are in effect designing the software.
And since agile approaches and modern tools allow us to make progress that much faster why not move more quickly to a working product? Minimise the design, postpone the architecture.
This approach also means the initial team can be kept small which means they are cheap. So if they conclude the project shouldn’t be done the organizational inertial is less and the project can be cancelled. Which hopefully means the organization will take more chances on more ideas.
Try this thought experiment.
On Day-Zero there is nothing.
Someone decided there should be Product X. How did this happen? They may have had the idea days ago and have spent the intervening time researching the market, the competition, the problem and so on. (During which time their normal job has been disrupted, the sooner they can dedicate themselves to the new idea the faster things will happen.)
On Day-Zero they talk to an architect who considers a design.
This takes a few days at the end of which there is an outline design and the architect suggests the team needs four programmers, two testers, a UXD and a DBA. Plus a project manager and product owner. 10 in all.
It now takes time to make the business case and gather those resources.
At that point work can officially begin, call that D-Day.
Then the team need to learn to work together, build something and launch it into a market.
They also need to understand what the architect had in mind.
Officially the project began on D-Day, or perhaps the day the business case was approved.
How much time has been spent so far? Without testing the market? Allowing competitors to do something? – all this time cost of delay has been at work changing the business case.
How has all that “getting ready” time been accounted for? How has this work been managed?
The MVT approach says: Time is of the essence the team should decide all these things.
So, as quickly as you can, spend a little venture money on an MVT.
That team has to investigate the market, competition, problem, etc. The team can think about architecture but their primary aim is to build something, and MVP, a prototype, a proof of concept, whatever – build it, show it to customers, launch it, put it in the market.
By keeping it small the team can quickly invalidate ideas which don’t work. Ideas that do work can be built on. They are free to learn.
The initial MVT will do all the same things that a “pre project” phase would do but in a much more agile/digital way. The MVT also allows for continuity, when the team find success the team that can be expanded and grown – applying Gall’s Law.
This also looks a lot more like a start-up than a normal corporate project.
If the idea of a Minimally Viable Team is new to you then check out the discussion in Continuous Digital or some of my earlier blog posts on MVTs.
| Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: Minimally Viable Team in a nutshell Opinions expressed by Java Code Geeks contributors are their own. |
