It’s quite common for organisations to be divided up into groups based on their function. For example, there could be groups for developers, server operations, product testing, a sales team, a marketing team, or many other groups, with a senior management layer above them.
Many organisations have discovered that these functional divisions can lead to internal silos with people in each one focused on their particular task. Silos exist in part because developing, deploying and maintaining software systems is a complex undertaking. Specialists are needed to deliver all of the components that make up the solution. But specialisation leads to functional grouping, which leads to silos. Each silo often adopts its own tools and jargon to better work on and discuss their part of the solution, but this makes it more difficult to communicate with other silos who are specialists in a different part. To make matters worse it is often the case that the goals of these silos are different. For example, frequent releases for Development, versus uptime and stability for Operations.
Traditionally the way to overcome these silos is through the use of meetings, conference calls and email. Everyone will know that each of these communication methods comes with its own set of issues. Even if they are working well someone needs to track actions and make sure they happen. A Project Manager for example. In the continuous Agile software development model this is not a good use of a Project Managers time. Projects should be well defined, distinct packages of work that have an end date. Continuous software development and deployment is ongoing.
Many organisations have adopted a DevOps approach to software development. As part of this they have found that cross functional teams break down silos. Instead of having separate silos as described above, teams are made up of members with all the specialisms needed to deliver the solution. Such as developers, database designers, database administrators, UI designers, server administrators, software testers, upper level software support staff, business analysts, product managers, and so forth. All working together, preferably in the same building with desks that are interleaved so that members with different skills are spread throughout. Teams that are geographically spread use collaboration and management tools allow the team to work together as a virtual team with real-time communication
Over time the goal of the cross functional team model should be internal knowledge transfer so that all members are poly-skilled and able to perform a given task. If a server needs configured for testing than a developer or a tester should be able to provision one. They shouldn’t have to wait for a server administrator to do it. Similarly, a server administrator should be able to write test scripts to troubleshoot reported issues without having to interrupt a developer or tester who is working on something else. The “it’s not my job” mantra should be seen as a relic of the past within cross functional teams. If a member of the team has the skills to perform a task then they should be allowed to do it.
When everyone in a cross functional team works together and are poly-skilled, they should have collective responsibility for the development, deployment and maintenance of their software solution. Everyone in the team should be responsible for delivering the best solution possible.