Why Agile should be adopted for remote working

Agile methodologies have been around for many decades even before the words Scrum and Kanban jumped into the spotlight. The core notion of Agile is that eliciting requirements and working out effective solutions is the responsibility of the entire team including stakeholders. Back in the day, software development mostly occurred in a single location, meaning that all teammates worked face-to-face day in and day out. It was easy to turn your head and say “’Hey Bob, I’ve just created a pull request. Can we review it together?”.

Nowadays, remote teams/employees are commonplace. So when you create a pull request Bob might be asleep. At first blush, you may think that Agile and remote style of work are incompatible. Well, that’s not true. Agile with a very few adjustments works for remote teams exceptionally well yielding tangible outcome.
Here is how we practice Agile in Bekitzur. (Sidenote: Hereafter the word Agile is used in the context of The Manifesto for Agile Software Development, without ties to any particular methodology.)

Team structure and development culture

As a rule, a remote team comprises multiple remote clusters of professionals in a single location/office, even if the cluster is a tiny team of two people. It stands to reason that each cluster should work on the same part a project or cover the same area of responsibility (like QA, front-end development or UI design). This way the cluster can harness the opportunity to communicate face-to-face across a full working day and be relatively autonomous.

There are two ironclad practices we utilize in Bekitzur for every project and each iteration: shared understanding and regular sync calls. All clusters within a project must be updated on the goal of the iteration and responsibilities of each cluster; thus, all clusters are working in a single direction with no dissipation of energy. Iteration planning and product roadmaps are the vehicles to bring in and promote shared understanding. In order to maintain this concentrated focus, all clusters do have regular sync-up calls and have a structured reporting system.

Since the remote team operates as several clusters, a high value should be placed on knowledge transfer. Practically speaking, knowledge transfer can be done either on a rolling basis or once per iteration. The former suggests that each pull request is ought to be reviewed by a peer in another cluster; the latter implies checkout of code base once an update lands into production. As it turns out, the second path is more preferable because it excludes dependency on a peer in another cluster, which in turn means that the entire process stays streamlined.

There are a couple of tips that can instantly make knowledge transfer more rewarding and productive.

  • Schedule knowledge transfer in advance: allocate sufficient time slots and make sure that both the reviewer and reviewee are within their standard working hours. What everyone involved wants is to have their questions answered so the lack of time or late evening hours doesn’t undermine the process.
  • Come prepared: the reviewer should have at hand the list of questions/topic to touch upon, whereas the reviewee should have the list of points they deem important to go over;
  • Most importantly, during knowledge transfer, both people must literally stay on the same page. To that end, they may want to share screens via a number of means: Google Meet, Slack, Skype, etc.

Great products are primarily the result of great team commitment and empathy. However, there are a number if unambiguous prerequisites ensure keep team focus to guarantee high delivery quality. We ensure this by adhering to a strict development process. It starts with a concise task specification and definition of ‘done’ with an optional user story for complex features. Once the feature is programmed, it is reviewed by another team member and pushed to the sandbox environment, where manual and automated QA are performed. Once the ‘go-ahead’ is given from the QA team, the feature is pushed to staging where the final checks are performed. Along the way, QA and software engineers work closely with the product owner to ensure that everyone is on the same page, ensuring a successful release to production.

Reporting system closes the communications gap

One of the most important goals is to provide a clear picture and status update not only to the management but to the whole team in general. That’s why it is important to use such agile artifacts like meeting summaries, release notes, monthly reports, etc. These signaling actions are a critical failsafe that make or break a project.

A designated meeting leader needs to distribute meeting minutes, archive meeting documents, and provide follow-ups to ensure that ideas discussed during a meeting were put into action. Providing information between remote clusters specifying what was done and what is planned is a very good tool for reducing communication gaps, showing the latest updates for each person even if he/she was absent on the call or had Internet connection issues. It’s also a robust forcing function to drain inevitable ambiguities that happen between meetings.

Each sprint ends with a prepared release notes document, describing what was implemented and listing all completed tasks regarding new features and core functionality changes.

Monthly reports are typically prepared at the beginning of the month to provide an overview of progress for the previous month and list project activities and implemented tasks. These reports also show analysis of current risks and known issues, provide information about upcoming activities focus, holidays and vacation plans.

It’s not unusual that project and feature release needs to be completed in very limited time frames. In these cases, we adopt a reporting system to signal priorities and provide updates on a daily basis, using Gantt charts and other diagram types upon request. It helps identify weak points if they arise and provide information regarding how close we are to the final release date.

During a sprint, a client can see the progress in real-time via JIRA boards. Every task is tagged with the sprint number and has a standard flow of “Assigned → In Progress → In Review → Testing → Done” flow. This can then be easily searched with a JIRA filter. A yet more detailed report is provided as a separate helicopter-view table format where additional important details are specified, e.g. the date when a feature has been pushed to production.

Once the sprint is over, a retrospective meeting is held where we discuss sprint results and lessons learned. Usually, we combine our retrospective meeting with the planning meeting for the next sprint as this helps ensure continuity of the overall development flow.

As a result of this approach, we ensure timely delivery of planned features and products as well as agility in handling unforeseen requests, which altogether keeps the client extremely satisfied.

Planning: strategic and tactical approaches

We start with outlining product priorities before the new year begins. As a result, we compile a presentation which contains the exact list of products to be improved or developed in the year ahead, specifying the key benefits such products will bring to client’s business and key features to be introduced.

As a next step, we formulate high-level vision is formed for each product and stored it as a JIRA epic for client review and approval. Finally, a preliminary estimate of what’s required to deliver the epics is defined and relevant resources are reserved for the client.

We use weekly or bi-weekly sprints depending on business requirements. The sprint plan is prepared by product owner based on the delivery timing for products defined in the high-level roadmap and individual priorities for every product. Final prioritization also takes current business needs of the client into consideration; we refine these in daily sync-ups with the client and store in the issues as appropriate in backlog. For instance, a sprint may contain a set of features for a new online reporting system of the client, with integrated modules of a current system using third-party tools and updates for backend engine which define how ad campaigns run. The sprint may also contain such ‘infrastructure features’ as QA automation scripts, CI/CD pipeline creation or security-related constraints.

During a sprint planning meeting, we discuss tasks inside the team and define the estimates. Every feature gets allocated an appropriate time slot for coding, testing, and fixes. In addition to planned features for each sprint also we reserve 20% of team capacity for urgent “ASAP” tasks and 10% for meetings and code review. The ASAP slot gives the client the required level of agility in case critical tasks break the surface so that they can be handled in mere hours. The meetings and code review slot guarantees that the team has enough time to discuss potential issues and deliver high-quality code. Also, every 6 sprints (i.e., every 3 months) we run a refactoring sprint mostly aimed at stabilizing the code.

Once scope, priorities, and resources for the sprint are defined, the product owner shares it with the client for final approval in the form of a concise table. Once the scope is confirmed with the client the tasks get created in JIRA and assigned to appropriate team members.

Bekitzur can help

Here at Bekitzur, we handle all possible ways to implement and release mobile apps, B2B and B2C services, as well as different platforms. Our teams have substantial expertise in establishing the most suitable strategies for the projects we work on, as well as analyzing the overall picture and tweaking everything on the fly, leading to the best possible results. Our teams are highly experienced and have all the necessary subscriptions and tools to make your project the best it can be. There’s a tremendous difference between product vision and product execution success. If you want to see how you can lock-in that success, we can help with deliberate, disciplined steps to create, maintain and improve your product strategy. Please feel free to contact us. We make a long story short.

Artem Trofimov, Project Manager

View posts by

Talk to Us