Building an agile culture for your remote development team from the Philippines has some challenges because of the lack of physical presence. However, there are some ways for you to build the developer culture virtually. A few things are discussed below.

Conduct Code Reviews to your developers

Code Review or also called as Peer Code Review will play an important role in building an agile culture to your team.  Code review is a process of checking with fellow programmers and developers each other’s code for mistakes, wrong implementation or ensure to follow some best practices in order to accelerate development.

It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. Code Reviews are done in different forms such as pair programming, informal walk throughs, and formal inspections. Since people from the Philippines and other parts of the globe have different timezones, distributing knowledge of the code between offices makes support and maintenance much easier. If the production issue will come out when the team is not online, other office can easily step in to support and resolve the issue. That is was you gain when dealing with a remote team. You’ll gain the expertise to handle cross-team or cross-location code reviews.

Build good relationship with your team

It is important in any program, especially agile program, to have a strong relationship and understanding across the team. Personal connections builds trust, alleviate self-organization, reduces missed expectations, and uplift morale. In your office, take time to get know everyone in the team and if possible, do the same with the team  you work with in the remote offices. Personal connections are essential in building good relationship with the team.

Build a united developer culture

There are four simple ways teams can make working across geographies easier and share a common developer culture:

1.) Overcommunicate decisions across all geographies

Ineffective communication is one of the work problem that may occur in a workplace. Over-communicating with the other team members may bring burden with them especially in a remote team. One way that will become a team united is through communication, by sharing ideas or problems in achieving milestones could be a best example. Making your communication tool better, a clear planning method, and having regular meeting with your team are ways to over communicate with them but will never annoy them.

2.) Minimize the friction in setting up the development environment

Wikipedia defines readme as: a file contains information and documentation about other files and directory of computer software.

And given the lists of the following contents:

  • Configuration instructions
  • Installation instructions
  • Operating instructions
  • A file manifest (list of files included)
  • Copyright and licensing information
  • Contact information for the distributor or programmer
  • Known bugs
  • Troubleshooting
  • Credits and acknowledgments
  • A changelog (usually for programmers)
  • A news section (usually for users)

 

3.) Clearly define the acceptance criteria

Acceptance criteria is important in building the right product/project. This will be the basis of the success or failure of a project or product. Acceptance criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system, these are also set of statements, each with a clear pass or fail result, that specify both functional and nonfunctional requirements.

4.) Define guidelines for filing bug reports

In order to have a good output of project or product, you need to know and test if it is really working well especially when it is already used by a customer or user. In testing project, there are bugs that may found and you need to have a time to resolve these issues as outlined by musescore , these are the things that you need to know in writing bug

  1. Isolate bug– the first step in writing bug report, wherein you need to know what the problem is.
  2. Check if you are using the latest version– update the version that you are using and check if the bug will still exist or not.
  3. Check if the bug is known- check if the bug is already documented in order to know if this issue has already existed.
  4. File each issue separately– in dealing with multiple issues, better separate them in order to solve and track them easily.
  5. Create a new issue– in this step you will need to answer several questions that are used in filling for the bug report
  6. Title– Title should be clearly and properly describe the problem.
  7. Description-know the right instruction or steps so that others can duplicate it.
  8. File Attachments– if you have other files that can help in resolving the issue then attached it.
  9. Submit– “Save” bug report and submit to the issue tracker
  10. Following up– even if the bug is already fixed by the developer, it is important to assure that it is completely fixed.

 

It is hard to build this culture even with your team in a co-located office, how much more to a distributed team, communication really becomes significantly harder. The challenge to train the team to understand that and to follow the best practices the team must adapt. It may sounds so easy but we overlook these trivial situations and we forget. Take time to build that agile culture within your team and tweak as much as you can until it fits to your team culture.

 


 

We understand Agile. We understand how Agile can help make or break your startup. At Bootyard, we’ve developing Ruby on Rails applications since 2011 using Kanban. If you are currently building your MVP for your startup, we’d love to have dialogue with you on how Agile can help you move forward efficiently. Shoot us an email at info@bootyard.com.