Remote – Agile Best Practices

In fact, we are considering remote-agile as a new methodology of agile, same as SCRUM and Kanban, as we mentioned earlier in this article. Besides this, as every methodology, it has its own rules and processes, and expecting that anyone sticks to these rules and follows those processes will achieve his objective and deliver his product successfully, as we have done many times over the last 4 or 5 years. You will find below some rules that will help you to overcome the challenges of working – remotely, or to implement remote – agile methodology:

1- Don’t accept requirement verbally

If we all agree that comprehensive documentation is wasting time and effort and hard to maintain, that doesn’t mean we can neglect it.

2- Plan for the first release

Don’t bother yourself or your team by planning too much for the future, instead, keep the focus on the first release and include all the basic and valuable features – as much as you can – in that release. This called an MVP – Release.

3- No work without a task

Using task management tools can make that easy, as anyone – if agreed – can add a task to himself to work, or some should be responsible to do that, as we highly recommend.

4- No work without estimating

Estimation keeps the plan on track, and monitoring it against actual effort helps
early detection of deviation and allows the team to take immediate corrective

5- Plan for sprints
A week or 2 weeks’ sprints are more than enough to deliver something valuable,
even not complete, don’t worry, continuing delivering will return with an optimum
valuable feature with minimal waste.

6-Report early

Problems and development issues happen all the time among all team members
regardless of their level of seniority, but maturity comes from early and continues
reporting of any issue that shows to be an embedment.
That helps at most to take corrective action very early before disasters happen.

7- Retrospectives

A reviewing meeting that should be held at the end of every sprint called a “retrospective” meeting, where everyone in the team gathers to discuss and determine the following 3 points:

  • What should we stop doing?
  • What should we start doing?
  • What have we done and should continue doing?

P.S. KPIs and progress indicators with some graphs will help much more for justification.

Rules for Developers:

Developers should do:

  1. Merge on a daily basis:
    Every day and before leaving, a developer should merge his code to
    the “development” branch, at least one time-a-day.
  2. Isolate environments:
    You should work on multiple – at least 2- environments (Branches) of code
    a. Development
    b. Testing
    c. Production/Releases
    At the beginning of every project, only “development” is required, then
    with the first deliverables of the first feature, you need “testing”, when you
    have reached a number of features that could be a candidate for a release, then create the “production”. (P.S. keep them all isolated.)
  3. Write unit tests:
    A unit test is a guarantee that every time you change a line or portion
    of code you don’t inject bugs, or affect a working one. At the end of each release, you will have a full regression test tool that ensures your code is clean, workable, and ready to launch.

Developers should not:

  1. Avoid code reviews
    Reviewing the code should be a habit among development teams, that
    every written code should be reviewed before merging by someone, a
    senior developer or even a peer developer can do.
  2. Merge to master branch
    Master branch is a reference for all environments, and it should contain the “latest working line of code”, which is – most of the time – the most recent published release. Merging to the master branch is coming at last, when every authorized person agrees to go-to-Market, and then merge back to master, also it is highly recommended to be done by someone other than the developer.
  3. Violate the pipeline process
    Under the pressure of work-overload, or a manager decision, sometimes
    development tends to violate the process for faster delivery, NEVER ever do that, it may break the pipeline and that could generate a lot of serious issues in addition to delivering un-verified code – No quality test –, pipeline has never been an obstacle for fast delivery, actually, it always gives the confidence to publish fast and regularly unless you have an issue in your setup.


Managing a remote and distributed team will stay a challenge for many companies’ managers, technical teams, and even Startups, as dislike the onsite team, you don’t have much control for every individual working with you, and even you may have to accept some changes of things you used to have in old ages, such as team structure, applied policies, trust code, management tools, and even team productivity and individuals’ utilization to keep your projects run, meet your Time-to-Market and ensure customer satisfaction. However, with applying a proper and effective process you can even reach more than you have expected, we advise you to go with remote-agile.


Medhat Oraby


Development Manager & Co Founder talentvar


Hackquarters is a startup accelerator and

corporate innovation partner

Join our network of 20.000 individuals !

Was this helpful ?
  • Share on :

Leave a Reply

Your email address will not be published. Required fields are marked *