Specialization and information loss

We had two bags of BAs, a full QA department, and one Ops just to push the release button. Not that we needed all that for work, but once you get locked into serious specialization, the tendency is to push it as far as you can 1.

Specialization

But now (in my main team) I don't have BAs, QAs or Ops*. The developers in my team can grab all the information they need from the stakeholders themselves, test their work themselves, and release it whenever they want. But don't think we didn't have this whole zoo of specialists. We did, but we gradually got rid of them, even though ...

SPECIALIZATION HAS ITS pros

Of course, specialization has its advantages. You can set up an IT production line relatively quickly and easily. The classic BA → Dev → QA → Ops scheme is widely used and works somehow. You don't think about the workflow process because it has all been already invented before you.

The job market is full of those specialists. Online courses offer everyone to become a manual QA in 2 months. No one is offering to be T-shaped because it's too long and no one would buy it. And maybe it's actually good for the industry - a lot of new people come into IT because of such a low entry threshold.

Managers also contribute to this situation. In an attempt to speed up their developers, they take away all the boring work, leaving only the actual creativity. It's easy to hire a couple of BAs and QAs and give our golden kids more time to create. It is such a pleasure to make them happy and see them sigh with relief and start working faster than ever.

BUT...

After a while, that performance will diminish if your range of tasks is wider than just hitting a nail with a hammer. Everyone will start to cultivate perfectionism, trying to focus on doing their job well instead of focusing on making a good product. And perfection takes time. A lot of time, in fact.

There is no way to avoid it. People have an internal desire to do everything as well as they can, but what that "everything" will be is defined by a set of their responsibilities. If you make developers focus on a specific part of the work, making them specialists, you are literally telling them to forget how to analyze tasks and check the results of their work.

And that's not the last con. By creating new links in the production chain and increasing the number of hand-offs, you inevitably get information losses.

Information loss

In our childhood, we had a game called Chinese Whispers (or Telephone in the USA). The members of the game would pass a message to one another by whispering it from person to person. Eventually, your initial "word" might turn into something like "Mordor" 2.

The longer your production chain, the greater the chance of losing something important along the way. Especially if you are not communicating face-to-face. But even if you do it in person, regularly, and often, you're still going to lose information (and a lot of time). Most people just suck at putting their thoughts into words.

BETTER SYSTEM

In my opinion, the best system is one in which there are only

1. a performer who has the desire to do the work and the ability to modify the software
2. and a competent customer who knows what they want

That's it. You do not need anyone else to do the dirty work. If you can avoid creating a new production phase that you don't have now to fix performance problems, please do it.

So, we should fire everyone except developers?

No. But they need to work a little differently.

Business analysts should be verifying and removing weak hypotheses from your backlog instead of forming requirements out of the words of stakeholders. They are not secretaries. They shouldn't be writing highly detailed technical specifications. No doubt they are smart people, but usually these specifications are useless or overly restrictive for developers to work with.

QAs should help developers check their work, rather than doing it themselves only after all the work is done. They could write test cases and put them in a ticket before a developer takes it.

Ops should build systems to deliver code automatically. Their mandatory presence in every release could prevent you from making more frequent releases. Continuous Delivery is a common concept, only the deaf have not heard anything about DevOps. If you want to begin to understand it, you can start by reading Phoenix Project.

Conclusion

You don't need BAs, QAs, and Ops in a delivery chain. At least not to do the work they normally do in an average team. Their skills can be useful, but only if they start doing things a little differently.

References