Remote - Agile Best Practices

August 5, 2020

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 verballyIf 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 releaseDon’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 taskUsing 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 estimatingEstimation keeps the plan on track, and monitoring it against actual effort helpsearly detection of deviation and allows the team to take immediate correctiveactions.5- Plan for sprintsA 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 optimumvaluable feature with minimal waste.6-Report earlyProblems and development issues happen all the time among all team membersregardless of their level of seniority, but maturity comes from early and continuesreporting of any issue that shows to be an embedment.That helps at most to take corrective action very early before disasters happen.7- RetrospectivesA 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 tothe “development” branch, at least one time-a-day.
  2. Isolate environments:You should work on multiple – at least 2- environments (Branches) of codea. Developmentb. Testingc. Production/ReleasesAt the beginning of every project, only “development” is required, thenwith the first deliverables of the first feature, you need “testing”, when youhave 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 portionof 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 reviewsReviewing the code should be a habit among development teams, thatevery written code should be reviewed before merging by someone, asenior developer or even a peer developer can do.
  2. Merge to master branchMaster 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 processUnder the pressure of work-overload, or a manager decision, sometimesdevelopment 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.

CONCLUSIONManaging 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.

Read More