If you have a look at the structure of an IT department, well actually any department within a large organisation and you will see everything is usually grouped based on specialties.
For example, you have the people who are in charge of the CRM systems. The ERP systems. Billing systems, Integration systems etc which is all fine and dandy for day to day operation, but what happens when some new work needs to be done? New work is usually done within projects. How are these projects resourced? Well, sometimes people will be taken out of these departments, and they are put onto the project. Other times, resources will be outsourced to the likes of Wipro, Capgemini, Accenture and so forth. This is all well and good, and gets the work done, but what happens at the end of the project?
Handovers are done to the support teams, you may have a warranty period where the developers are around to fix any “defects” and inconsistencies, and eventually the teams break up or in the case of our outsourced resources, they go back to the proverbial bench to be picked up for the next project.
What happens to all that learning on how the system works, the improvement of the development process, the working as a cohesive team? Well, quite frankly it all goes “poof”.
It doesn’t matter if the project is a Waterfall project or an Agile project. All the learning of how to work together, work cohesively, improve the development process all disappears. The worse thing is that this is considered normal.
This is siloing of resources.

This is the concept of Bring the people to the work. You have a job or a piece of work that needs to be done, so you gather the people that have expertise. Do the work and then once they are done, disband them. I see the allure of doing this. You only keep the people you need for the duration of the work to be done. So costs are reduced.
The problem with this paradigm is that it works well with manual low skilled labour or where there is a specific one off job.

The problem comes when the work is more ongoing. Specialized. For example, building a house, or creating software. Sure you can get away with bringing in people short term, but what you will find is that if you bring them in for the long haul, then things get better.

For the example of building a house, a building company will have its own carpenters, plumbers, concreters, bricklayers, electricians etc. They still move from house to house, but the team remains pretty much constant. The team when done right will work cohesively. They work together in each others interests. They get the job done quicker and better.

The same with Software. You have a team that consists of multiple skills. Developers with a range of technologies and systems (CRM, ERP, EAI and Billing systems etc), DBA’s, testers, BA’s etc. Then when you have a new project that needs to be worked on, you bring the work to this team. This team knows how to work together. If they have used Agile methods, they have improved over time. They know how to get things done quickly. This team is long lived.
You may have different teams with a slightly different mix. They work on other segments of the same project or on different projects. To make things even more interesting, these teams also run the system, not just do project work. In this scenario, all learnings during the project remain and continue to the next project, and the next and the next etc. If the people also run the systems, then there is little to no handovers required.
If you use external vendors, then rather than keep these people on the project for the full duration, slowly replace them over time with your own people and have the vendors teach them the technology that you are not proficient with. I have seen too many times where external vendors a brought in, do the work. Hand over to the BAU team, bug out then the BAU team is left scratching their head when something goes wrong because they lack the one thing that would have helped – Experience.

The second problem is within the teams. You have developers, DBA’s, BA’s Testers etc. Each person does their specialty. If the skillset is not present, then everyone continues and work banks up until that skillset comes back.
This is the second level of Siloing and it prevents things from getting done.
In Scrum, there is the concept where there are only 3 roles. The Scrum Master, Product Owner and Developers. There are no sub roles such as Tester, DBA, BA etc under Developers, just Developers. It is expected that each person with that role is willing and capable to an extent to do the job of all roles. Some may be better than others, some may have no experience, but that is irrelevant. Those in the role of Developer are encouraged to understand all disciplines even though they may specialize in one.
For example, say a project has no tester – they are on sick leave. Programmers (as opposed to Developers) continue coding. Work mounts up ready for testing. Nothing gets tested and then at the end of the sprint/iteration, nothing is marked as complete. What happens then? From my experience, either someone external is brought in to do the testing at the last minute – it may even be the scrum master or product owner or the work is taken to be OK and is marked as “Done” or any issues found later and bug tickets are raised or everything goes back onto the backlog until the tester is back. Then they have a large batch of work to get through.
One thing that I have never seem in my limited experience with Agile is for the developers to step up and do the testing. I don’t see the problem with this. There are no sub roles in scrum. Everyone is a Developer, everyone is a tester, everyone is a BA. Everyone has the duty to test. This is the tearing down of the inner silo.
I know, if you test your own code, you may still have bugs from misinterpreting the requirements. Well, testers can have the same problem if the requirements are not clear enough. The concepts of Specifications by Example should take care of situations like this.
Another reason I have been told that this isn’t a good idea is that as a developer testing your own code, you can just pass it through. My thinking on this is that if you are willing to do this, then you are not being professional. Secondly, if you are willing to do this, then there must be an underlying problem with the team, is the team not feeling pride for its work. It may be because the team are being dictated to and have therefore lost engagement, team members may have personal problems, team problems such as not getting along or something else altogether. I don’t believe anyone wants to sabotage their work intentionally.

If you still are unhappy, then have another team member – any member of the development team check the work.
I’m not saying get rid of testers, but I’m saying that if there is no one else available you need to step up and help.
This also holds true if the tester is inundated with work. Step in and bring that WIP down.

I’m reminded of a story in Team of Teams, at least I think that is where it came from. I’m paraphrasing here but…
If you are shot in combat, you don’t want to be sitting there bleeding away while the medic is either working on someone else or shot them self. You want for example the communications officer to be able to patch you up even though they do not have the full training.

So break down the silos. Everyone should learn a little about everything, even though they may specialize on one thing. We are all in it together, we should be helping each other out.