Team over group of randoms: 8 reasons why

Our observation is that when it comes to software development, an established team outperforms a group of randoms by, like, a serious margin. Maturing of a software team is certainly something that happens naturally with time, but the point being driven is that starting from a sufficient level of maturity makes more sense.

Here we approach this proposition by pitting some examples against some counter examples.

Before reading

On Team as a Service

Offering teams for hire is sometimes called “Team as a Service”, or TaaS. Although, we think that most of the players in this field are doing it a bit incorrectly. Our adjustment for this is that a Team needs to already have grown together into maturity, instead of being assembled when required. This “late assembly of a team” would still leave the client with the bill, risk and delay for the maturing process.

Definition of Group of Randoms

In this article, when talking about a group of randoms, we mean a group of people that have not done a software project together before.

Definition of a Team

When talking about a Team, we mean that it should:

• Have survived at least one project before.
• Be converged on mutual development practices and level of quality.
• Get along.
• Maybe have some accumulated tech and solutions for reuse.

Examples and counter-examples

Imagine it is a cold and stormy night. You hear wolves howling. With your favorite tea-cup in hand, snuggling warmly by the fireplace, it suddenly happens: you are struck with The Idea. And indeed, you want to go somewhere with it. You realise that to make the idea happen, you will need software professionals.

Having given a name to The Beast, you descend into a deep state of concentration while you meditate on the subject. You feel your mind leaving your body and see the life-cycle of the project forming before you. Concept of time loses significance. A dead shaman hands you a pergament of 8 arguments for your consideration.

1. Before going anywhere

A group of randoms: needs to be assembled. Someone will need to be responsible for gathering a working collection of required competences (eg. front-end, backend, UX, architecture, leadership, DevOps, agile specialist, database specialist, cloud engineer, usability expert, test automation expert, graphic designer, etc.) as people. This is tricky, and takes time.

A Team: is ready for holistic software development. Most general competences are already there, and what is missing can be compensated with the time saved in assembly. This can mean letting the Team pick up a new skill as it goes, or by complementing the Team by onboarding a specialized member (eg. AI-specialist, data-scientist or maybe a blockchain-expert).

How it feels when done right: you feel like you have made it easy with this one. Your scars of doing this the last time have not yet healed.

2. Getting going

A group of randoms: starts with very little. Convergence on stuff like build automation, code reviews, architecture, favored libraries, test-coverage, quality, etc. takes its time. Pushing forwards without agreement, risks consistency of code-base and thus velocity.

A Team: has an initial agreement on general stuff, and also has a familiar way of communicating with each other. Being able to move mountains as a unified front means a running start.

How it feels when done right: early flow of features and business value translate to trust, and simply a good bang for the buck, especially when cost-of-delay is a metric.

3. Keeping going

A groups of randoms: is more prone to accumulate unmaintainable technical debt due to lack of shared responsibility. This damages the velocity.

A Team: may have started strong, but also keeps going strong by not letting code base fester and rot as a shared effort. The Team knows that the only way to go fast is to go well.

How it feels when done right: a steady accumulation of business value means no friction in reporting your’s and the Team’s accomplishments further up in the chain of command. Progress remains constant and predictable.

4. Going well

A group of randoms: may have diverged opinions of what constitutes quality code. Fixing bugs in production is considered part of the job, with no requirement for introspection. The variations in quality can go unnoticed for a long time. Technical debt creeps in. Velocity is whimsical. There are talks of big rewrites.

A Team: has grown to abhor bugs and prides in well-polished features. Mechanisms of automated quality control are in place. The bar of excellence is universally set high, and no individual is alone responsible for upholding it. Reasons behind dips in velocity are carefully examined.

How it feels when done right: you feel pride in the quality of the project, and you are eager to see where it can go in the future.

Interruption!

A booming crash breaks your attention in the middle of yet another top-X list. Peeking out of the window you notice that a tree has taken a blow from a bolt of lightning just some 50 meters away. What does this mean? Are you being warned somehow? Have you angered the internet trolls? Are you being too unconditional with your thesis? You shrug it all off, fill your tea-cup and carry on with the list.

5. Going wherever it makes sense

A group of randoms: are most likely not there yet when it comes to reacting to change, as making this happen takes more than individuals. Instead, change is perceived as an inconvenience, and thus more fixed specification are preferred. Despite superficial claims of agility, waterfall emerges.

A Team: knows it takes team-effort to build a ship-of-software free to change its course, and also to actively seek the best course. All this is supported by eg. design philosophies, short feedback cycles and test automation.

How it feels when done right: changes in requirements and priorities are received business-as-usual. Common sense prevails. You feel nimble and agile.

6. Going manageable

A group of randoms: have probably not yet evolved to the acquired taste of creating visibility on team level. Lack of means for informed decision making causes things to happen on their own weight. Decisions are based on feelings instead of fact.

A Team: has a culture of providing visibility to the overall plan, and progress taking place. This could mean visibility on velocity, burn-down, acceptance tests, estimation, budget, etc. The Team has backbone to be brutally honest to deliver hard truths.

How it feels when done right: you know what is going on, and what is the health of the project. You have means to make informed decisions. You can make credible predictions. You are rest assured to be well informed even with bad news. You feel in control.

7. Going less risky

A group of randoms: is an unnecessary risk. Sometimes mixing a new set of egos together makes conflicts boil under. This jeopardises employee retention, motivation and project success overall.

A Team: already knows how to get along. Possible conflicts have already been solved long ago, or the Team has no problem solving them independently.

How it feels when done right: an atmosphere of professionalism and mutual respect prevails. You do not feel burdened by problems not belonging to you. You feel relaxed that the project operates on a solid chemistry between people.

8. After the authors are gone

A group of randoms: sometimes leave behind a less-than-maintainable mess with technical debt and no consistency between silos of roles and authors. Further changes cause breakage without notice. Cost of new features is prohibitively high.

A Team: has used its hive-mind -like super-powers to produce a consistent code-base (design, cleanliness, code style, testing, documentation etc.), enabling onboarding and further development.

How it feels when done right: you feel safe to scale, or to switch vendors. You are not fixed with a certain Team. You are free to have options.

Summary

The article explains why letting teams cycle projects instead of having projects cycle individuals is the better bet for risk taking, quality and value overall. This is not to say that singular items mentioned are impossible to be achieved by a group of randoms, but instead are unlikely to manifest as feasible investment in a scope of single project starting from zero.

“Finding good players is easy. Getting them to play as a team is another story”

— Casey Stengel, a baseball manager

The dead shaman does not smile as you part ways, but somehow you know that there now exists a deeper understanding between the two of you. And also the universe.

Who are we?

This article was written by Your Pals at Team: Igniter from Houston Inc. Consulting.

We are a software development team of friends, with proven tradition in professional excellence. We specialize in holistic rapid deployments without sacrificing quality.

Check us out, we just might be available for hiring ;)