What is wrong with combining roles? Business Analyst / Tester? Tester / Developer? Designer / Front-end developer? Project manager / Product manager?
I dislike siloing. Siloing is when two or more combinable roles are split apart across several people so that each person has their own little niche. Instead of hiring one person with a broad skillset, two or more people with narrow skillsets are hired instead. And then all of these people are expected to function collaboratively. So for a task that could take one person a small amount of time, instead a communication overhead is created and many meetings ensue. Time is wasted, miscommunications happen. Mistakes are made, corrections are made.
In many cases, when people are siloed they tend to only take responsibility for tasks that fit within their own predefined roles. For example, developers won’t test the software because that is the test team’s job. Testers won’t update the requirements documentation because that is a business analyst’s job. Testers won’t set up a virtual machine because that is a system administrator’s job. So tickets get assigned, bucks get passed, time gets wasted. When something goes wrong, the first thing to do is assign blame.
Where I work, we have the following roles: Designer, Developer, Tester, Product Manager. At first glance, it seems as if there are a few roles missing from traditional software development teams. That’s because, if we look at the skillset of each team member, it paints a different picture.
The designers are also front-end developers.
All of the testers also have developer skills.
One of the product managers is also a designer.
One of the product managers is also a developer.
All of the team members are essentially business analysts.
All of the team members also do testing.
There is no project manager as such. The whole team is responsible for keeping the projects on track. If someone sees something that needs doing, they will generally do it if they are able.
The great thing about having a small team with multi-skilled individuals is that communication becomes much easier. Instead of having to set up a meeting with four or more people to discuss the translation of requirements to design to implementation, this may only involve two people. In fact, we don’t have many meetings at all. We built our first meeting room two weeks ago and we have yet to use it.
Because most team members have developer skills, it makes it easier for everyone to understand each other even when the talk gets very technical.
Of course what works for each organization is, as always, dependant on context. And it is difficult to find and hire good people with such varied skillsets. But I personally believe that siloing leads to badness and there is a much better way.