Tearing Down Project Silos

As modern development increases in complexity, projects require more time, resources, and people. Teams become bigger and must split into focused skill sets, and work begins to move from one resource to the next. The resulting assembly line looks a little like this:

Project silos emerge along the line when team members and resources become highly independent of each other. Each ‘stop’ along the line focuses on a particular task, often engaging in processes, communication, and tools that work solely within the confines of the task at hand. 

Project Debris

As the project progresses, each silo also generates its own form of project debris:  the leftover side effects of the process on the overall project and deadline.

In an assembly line model, project debris accumulates as it moves along, much like debris floating down a river. This debris can often create blockages and negative impacts on later phases of a project, resulting in significant effort to clear it.

A Process For Eliminating Silos

One of the easiest ways to transform an assembly line flow into an effective and openly communicative flow is to create checkpoints. Each checkpoint is added to the project flow at key points, where stakeholders across the project can align on the schedule, budget, scope, and client expectations.

To maximize the impact of these checkpoints, it’s best to plan them at transitional points in the project. They should include the team actively working on the project, and those impacted by that team’s work. 

Often, the team working alongside or immediately following the current checkpoint is best. Project re-alignment early and often removes project debris from the flow before it can accumulate enough to cause severe issues.

As the project progresses, it’s important to avoid pushing off issues to later phases. Doing so will only move debris down the line, and create similar problems on the assembly line we’re looking to fix. Similarly, sacrificing QA and code review isn’t a good way to remove project debris from the flow.

Communication is a big part of the check-in process. Be sure to receive buy-in from team members impacted by project changes and decisions, without making assumptions on their behalf.

Tools for Eliminating Silos

Often, silos form from a lack of available tools and communication methods. That being said, it’s best not to buy into massive communication and alerting systems. Throwing too much information and comms interruptions at your staff can have the opposite effect, leading to confusion and withdrawal. 

Instead, look for tools and apps that successfully provide passive communication. These tools provide data at a glance, while being intuitive and relying on formatting queues to get information to the viewer. 
Great examples include commit messages on Git clients, task tagging in Trello, or task dependencies in Jira. Anything that provides information without explicitly outlining it.

Whichever tools you use, ensure they work intuitively with your team’s entire flow and existing tools, aka the “stack.” The tools should provide organized records and come with their own process definitions. Any tool that requires extensive training and process building to make it suitable for the entire staff team will inevitably require maintenance and documentation. Whenever a process becomes complex, fewer staff are likely to adopt it.

Eliminating Developer Silos: Git Flow

For developers, silos can exist at a micro level within the project’s code base. Each developer tends to operate as a free agent within the code, with limited awareness of who else is working on what. This can create costly bottlenecks on the workflow, initiate conflicts in the code being written, and overall create disjointed solutions.

To eliminate the issue, a Git methodology like Git flow can be a game changer. Within Git flow, edits are done on a “develop” branch–or a “feature” branch for longer edits that need to be versioned–and only merged into the  main branch when the changes are cleared to go live. Git flow can be used with or without merge requests, for added checkpoint effect.

In many ways, Git flow is a developer-specific exercise in communication and checkpoints. It provides passive communication on project edits, status, and potential side effects while still separating work-in-progress from canonical environments. You can learn more about using Git flow with GitKraken. 

Better Communication, Better Projects

It’s never too late to start breaking down project silos. Doing so early and often can increase staff satisfaction, eliminate project debris, and make client interactions much more positive. Similarly, planning communication avenues, tools, and processes early on can prevent trouble in the first place.

Shawna O’Neal is a co-founder and developer at Dodgy Code. She has extensive experience in developing websites and web applications, in addition to working with clients to develop bold web projects across a range of sizes and complexities.