An Argument for Larger Dev Scopes

Conventional wisdom says to scope down your initiatives and make small tasks for your team members. It’s best if each can easily work on a single task in a silo, so they can get the project done with the least overlap and delay. But, what are we losing with this methodology?

What I’ve Done

In the past, I’ve gotten large projects or initiatives and broke them down into tiny bits of work. I was able to split my work into 3 to 5 silos and I had each developer work on that project. Towards the end, we needed some integration, sure, but I was super proud of what I did.

I had 5 streams of work in progress. No one was really waiting on anyone else.

The Flaws

I had created silo workers around business processes. One developer was very familiar with the finance portion. One was very familiar with the integration with third parties. The other was the Salesforce back office guru. My project got done, but now I had 5 people who I didn’t want to ever let take vacation - or God forbid - quit!

I also noticed that it seemed to be going slower than I expected. Now, I’m not saying that this was a conscious choice by the developers, but it seemed odd. As I thought about it, I realized that with 5 projects going on at the same time, its easy to imagine that the other projects are more important. It’s easy to take a little bit of extra time reading the news or texting friends. After all, 4 other developers are furiously working on some part of the project and we’ll all be fine.

Finally, the biggest flaw I saw was that the code wasn’t that great. With no one to run checks and balances, not really interrupting each other because they were all consumed with a different silo, each dev did something different. And, oddly enough, it seemed to be the worst of their work, not the best versions of it. I honestly haven’t figured this part out yet - I would try to make mine the best version. But, I always try to do my best work. :)

The Solution

While I still believe in scoping projects down, I no longer believe in single developers working on a single task apart from others on a team. I think there should be between 2 and 3 on a task: 2 normally, one group of 3 if you have an odd number. These groupings should rotate.

Now, this sounds like it would be slower: people stepping on each other’s toes, not moving through the projects as we used to, having to tell stakeholders that while we have 5 devs, we can’t do 5 simultaneous projects. There are challenges, yes, but the benefits out weigh them. Let me explain.

Cross Training

First, the developers on a project task get cross-trained. As they work together, they can’t help but learn at least something about each other’s work. If you have two people working on a finance portion of an app, they both know something now about finance. Maybe not all of it, but they have a much larger chance of knowing what’s going on.

As part of the process, they should be reviewing with each other their code as well. This way they’ll gain more insight as they review someone else’s implementation of a feature they didn’t work on. That brings me to my next point:

Higher Quality

Whether it’s competition, pride, or just the joy of sharing a job well-done with someone else, the code quality will be better. When they’re calling each other out on their successes and failures, the code quality can’t help but be raised.

In addition, having someone to ask questions that knows about your process is very useful. When you’re asking questions of someone cross-silo, the set up for the question can be so daunting, you might just give up. Or even if they do catch what you’re saying, they may help you make an incorrect quality or logic decision; they know even less than you about this subject.

Faster

When you have developers working with each other on smaller tasks, they know they have to combine their work more often. This helps develop code that is more likely to be integrated easier and is more tested. This also means that last step of combining all the silos is going to go much faster.

It’s also hard for two people to both slow down and “not care” compared to just one. Again, we’re not talking about anything malicious. But, when you’re your only driver, it’s easy to just “do that tomorrow.” When your team member depends on you for something, you’re more likely to get it done - for them.

Final Thoughts

Scope large projects down, but don’t create silos. Team programming is beneficial for a lot of reasons like quality, cross training and speed. We’re not talking about robots here - so let’s stop deploying our devs like they are.