Keep It Short and Simple, IT companies!
Intro
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.
This article is mainly my opinion why companies, managers, CEO’s and even clients should keep things KISS (Keep It Short and Simple). It all boils down to a single thing: waste of time. And time is money!
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:
They have all the skills and tools needed to design, develop, test and release to production, being an autonomous, self-organising team who are experts in their product area.
That being said, a squad must have members with skills sufficient enough to complete their project or product. If we’re talking about an expert in each field we can assert that we need no more than 4 developers. (I’m not including Product Owner nor Scrum Master here)
- Designer
- Front-End Developer
- Back-End Developer
- Tester
Having one of each is certainly a dangerous thing to do (you never know when one’s cat will sleep on their keyboard and prevent them from working), but then again the amount of constant work a designer will have for a project can be discussed, but let’s say he’ll spend his full-time in a project. So perhaps a good distribution for a development squad is:
- Designer
- Senior (or Mid) Front-End Developer
- Beginner Front-End Developer
- Senior (or Mid) Back-End Developer
- Beginner Back-End Developer
- Tester
So we have up to 6 development members in a squad and that is enough for most projects!
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.
In essence, when managers start bloating squads with more and more developers they’re basically adding complexity to the project instead of making things move faster. It’s not even a good complexity, but one that’ll mainly make members stressed and wasting more and more time in uncessary meetings to align things that 1/3 of them already know, 1/3 thought they knew and the other 1/3 couldn’t care less.
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!
