Keep It Short and Simple, IT companies!


I’ve been working in the IT field for a bit more than 7 years now and despite few companies or projects I regularly see large companies putting more and more members in a squad or bringing multiple squads before a project or product has even started. Don’t take me wrong, these companies or projects that I mentioned before which don’t this is mainly because they can’t afford for a bigger crew or they’d certainly have it.

The more, the better! Is it thou?

It’s not my idea to bring the discussion here whether agile culture has actually worked or not, but it’s certainly brought many benefits for our current working environment. In SCRUM we know the definition of squad is:

  1. Front-End Developer
  2. Back-End Developer
  3. Tester
  1. Senior (or Mid) Front-End Developer
  2. Beginner Front-End Developer
  3. Senior (or Mid) Back-End Developer
  4. Beginner Back-End Developer
  5. Tester

Communication Issues

More members in a squad means you’ll have to manage and keep the way they communicate with each other clean and tidy. So far I haven’t seen any company actually concerned that communication between members can be a real issue. Most executives or managers think a developer can simply join a running project, put his hands on a keyboard and… magic! We all know that’s not true and we also know the amount of threads and different topics will make the project hell.

The larger a squad is the harder is to keep track of all discussions and topics related between each other

To Sum Up

This is a call to all developers, clients and managersout there. Whenever you feel a project is far more complex than it should and it’s hard to keep yourself aware of the business essence of your project you’re not wrong. Your company has probably added unecessary complexity to it by bloating things up. Big companies don’t need big teams just to inflate their ego! Big companies need to Keep It Short and Simple!

Great Related Content

If you’re looking for a far more informative content regarding this issue you can check out this article (written by Agile Pain Relief) which has lots of insights and great content that emphasizes the issue behind big teams and their relationship. This article nor I have any relationship with the owners of the referred article, but great content must be shared!

C# / .NET developer eager to jump into the mobile development world! (also a Godot enthusiast!)