3 Signs Your WordPress Development Team Is Not Actually a Team

petersuhmThis post was contributed by guest author Peter Suhm. Peter is a web developer from the Land of the Danes. He is the creator of WP Pusher and a huge travel addict, bringing his work along with him as he goes.
 


If you run a typical WordPress agency, I will be bold enough to say this: Your WordPress team is probably not working as a team. Ouch!

Developer productivity and workflow strategies are my passions. I try to talk to every WordPress developer I meet about how they work and what problems they face. If you ever used WP Pusher, signed up for one of my crash courses on Git, or if for any other reason I have your email address, there is a good chance that I have talked to you about this as well. I have spoken with hundreds of WordPress freelancers and agencies in order to get insights about how they work. You will be surprised to hear how many WordPress agencies are working as small one-person teams, instead of actually working together. The reason for this is a lack of some of the most basic enablers of teamwork.

Here are 3 things that will make it very obvious to me that your WordPress team is probably not as much of a team as you would like to think:

1. Lack of version control

Did you read this headline thinking “Great, we’re committing everything to Bitbucket already, so we’re fine”? To be honest: Having an account on Bitbucket and pushing all your code there is not enough.

Git is not just about backing up your code on Bitbucket or GitHub. It is one of the most basic collaboration tools for your developers. Git gives them the freedom to collaborate on the projects they work on, but only if used in a certain way. If the commit log is a big mess of huge commits with meaningless commit messages, it won’t be very helpful to the rest of the team.

However, if a commit represents a small, isolated change and a commit message is well-written and concise, suddenly Git becomes a tool that your team can use to stay on top of what everyone else is working on. In teamwork, communication is key and Git is a great way for your team to communicate what is going on within the different code bases they are working on.

2. Lack of a code collaboration platform

The main reason to use a code collaboration platform like GitHub or Bitbucket is not to have a backup of your code. Dropbox would probably be easier to use in that case.

GitHub in particular is a great place for code collaboration. The way pull requests are implemented on GitHub makes reviewing code very enjoyable. Pull requests are a way for your developers to act as a team, by helping each other out with knowledge sharing and feedback. By opening a pull request early in the process of building a new feature, you can invite your co workers to follow your progress and chip in with their knowledge. I have written in detail about pull requests on the WP Pusher blog if you want to learn more.

Of course, GitHub is also a great place to see the current status of your team spirit. Are people sharing their work and asking for feedback? What are they getting it in return? Are people helping each other out? Are they working as a team?

The culture is important as well. Giving each other feedback needs to be the norm. Using pull requests and having a list of well-written commit messages on GitHub is the first step, but the culture needs to be embraced as well. Asking for help should be rewarded and not frowned upon.

3. Lack of a deployment strategy

How are you going to review something that was edited live on a production site? The truth is, you are not.

When your team is up and running with Git, a proper deployment strategy is a no brainer. It is the natural next step. If you do not have a proper strategy for your deployments, it tells me two things: 1. You are probably not using version control properly. 2. Your developers are manually uploading files over FTP – files that were never reviewed by any teammate.

If you are using version control, having a deployment process that kicks in when code has been reviewed and is ready for production is easy. The lack of a deployment strategy is a very clear sign that something is missing in your processes.

If you read this far and are realizing that your WordPress team is not really working as a team, here is my number one recommendation: Get every single technical person on your team on board with Git. Build a culture where communication and collaboration are the norm. In practice that means at least two things: First, when you look over the commit log on GitHub, you can actually see what happened and when. Second, when you go through the pull requests, the team spirit should be obvious from the way feedback is given and code reviews are done.

My hope is that this post has convinced you that Git is more than just a backup tool. In fact it is one of the most important enablers for teamwork among developers. Without the foundation provided by Git, working effectively as a development team is almost impossible.

6

6 responses to “3 Signs Your WordPress Development Team Is Not Actually a Team”

    • Feel free to replace Git with whatever version control system you prefer (I don’t see why you would though ;-)). Without version control, collaborating on code is very difficult – hence, it’s difficult to work as a team. It’s at the bottom of the pyramid!

  1. Thanks for the step by step, Sarah. Having positive support from other development teams around the topic of version control and collaborative work, i.e. using GitHub, just makes it more mainstream and that is very welcome in this case. This is obvious but even if you’re just one developer working on an instance of WordPress, GitHub keeps you honest and is helpful when you need to come back to work on something you haven’t seen for months.

  2. Good article, and Aye, it does not matter what Collaboration tools or VCS you use, or what deployment services you use. The key here is that you have process. The message: ‘Have a dedicated process for versioning, code review and deployment’ . Don’t leave home without it.

    We simply use SVN and Beanstalk, and have a robust system that manages hundreds of checkins and deployments weekly. All code flows through a dedicated dev -> test -> production branch system, with QA Gates along the way. Think SDLC concepts for all projects, and you cannot go wrong!

    Thanks much!

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.