When we deliver

Our delivery is geared to support the most efficient and value-producing outcome for the project. This means we may operate under different methodologies (Scrum, Kanban, etc.), and shape our team according to you and your project needs. 

Who is the Delivery team?

Our Delivery teams are composed of multiple team members, brought together under the guide and direction of a Project Manager and Engineering Manager, to work collaboratively towards each task, sprint, goal, milestone and launch. Our Delivery team often looks like this:

1. Project Manager

Your main project point of contact. The person who is responsible for keeping the project on track, the team steadily working and you well informed.

2. Engineering Manager

Spearheads the technical solution to achieve the desired outcome of the project. Responsible for the solution staying aligned throughout the development, and supporting all developers in their tasks.

3. Developer(s)

Work through tickets defined by the Project Manager and Engineering Manager producing ongoing valuable output. 

4. System team

Provide support for any hosting (server) related setup and configuration. 

5. Designer(s)

Handles all design needs from user journeys to formal mock ups.

6. QA Engineer

Ensures that what we have built is bug free, and performing as intended, prior to coming to you, and your team, for User Acceptance Testing. 

7. Account Manager

Outside of the direct Delivery team, we also have dedicated Account Managers assigned to each of our Clients/Projects. This team member stays up to speed on the project, and is responsible for touching base with Clients on a regular basis to validate that all project components are moving as expected, and expectations are being met.

Where is our Delivery team located?

We have team members all over the world. While the majority of our team members reside in Pune, India, we have coverage 24/7 due to our comprehensive team’s varied location, and our flexible work schedule. This means there is always someone online in the event an urgent need arises.

If you are an Americas-based Client, we ensure a minimum of 4 overlapping hours between our core delivery team, and you/your team. 

What development methodologies are used?

There are 2 main development methodologies that we leverage on projects, Scrum and Kanban. At times we blend the two together, always looking at the goals of the project and which specific working models will yield the strongest Delivery. 

1. Scrum

Scrum emphasizes iterative progress through short, focused work periods called sprints. Our sprints generally last 2-4 weeks depending on project needs. At the heart of Scrum are daily standup meetings (asynchronous), where team members share progress, challenges, and plans. By breaking down the development process into manageable chunks and encouraging frequent feedback from Client stakeholders, Scrum ensures flexibility, transparency, and the ability to adapt to changing requirements. Ultimately, Scrum enables us to deliver websites efficiently, with a focus on continuous improvement and Client satisfaction.

2. Kanban

Kanban allows our Project Managers to manage and visualize workflows. Kanban uses boards with columns representing different stages of the development process, from backlog to launch.. Tasks move across these columns as work progresses, providing a clear, real-time view of the project’s status. Unlike Scrum, Kanban does not prescribe fixed time frames (sprints); instead, it emphasizes a steady flow of work, ensuring teams focus on completing tasks efficiently without overloading resources. This approach enhances flexibility, minimizes bottlenecks, and allows us to prioritize tasks based on immediate Client needs, thereby optimizing website development delivery.

What kind of meetings occur during the project lifecycle?

Having set meetings that follow a specific structure to keep things moving smoothly. Below are the standard meetings conducted daily, weekly and monthly throughout the duration of the project. Do note these specific meetings may vary based on project needs. 

1. Daily

• Standup – a daily sync (can be async) covering what was done the day before, what is being done today and any impediments (note: rtCamp uses a hybrid model for this, utilizing a slack workflow for daily async standups and a 3 x 30 min weekly internal team sync to address topical items needing calls)

2. Weekly to Monthly

• Team Syncs – these may be combined with other meeting needs, such as Planning or Grooming, but Team syncs exist as a routine touchpoint between our team and yours, so we have a space to answer/ask questions, provide status updates and review completed and upcoming work.
• Planning  – a per sprint/per development cycle meeting where the upcoming tasks are planned, estimated (if needed still), assigned and committed to.
• Backlog Grooming (optional) – a meeting dedicated to prioritizing the backlog, reviewing the higher priority tickets and ensuring they are fully defined and there are no open questions/clarifications within them.
• Demo – a demo of sorts at the completion of each sprint or development cycle, reviewing the work that was done.
• Retrospective – done either on a sprint x sprint basis, or at a set routine outside the sprint cadence that allows the team (internally and optional externally) to review what is working, what is not working, and action on improvements.

How do we communicate?

There are a few tools we utilize to maintain constant and transparent communication/alignment. Of course, if there are specific tools you utilize for communication, we are happy to integrate into those as well/alternatively.

• GitHub Project Board – we utilize GitHub Project Boards as our default Project Management System. This tool integrates well with our GitHub repos, and allows us to granularly track tickets throughout the project
• Slack – Slack keeps our team connected and organized. It’s our virtual workspace for instant messaging, file sharing, and team updates. 
• Email –  email remains our formal space for any major project updates/changes.

What type of project reporting can be expected?

We want you to be informed every step of the way. One of the ways we facilitate this is through routine reporting. At any given time during a project you will be able to access the Project Management System and see all of the various tickets and work being done. However, on a routine cadence (e.g. weekly, fortnightly, monthly depending on project type), you can expect a detailed report accounting what has been completed, what is being worked on, and what is coming next. Our reports also highlight overall project status, blockers/risks and any noteworthy topics — keeping all of the details you need in one, easy to read, place. 

For our hour-based projects, in addition to this routine reporting, you can also expect a monthly time report, outlining in detail all of the hours consumed throughout the prior month, and in some instances the time reports are sent as frequently as weekly.

What happens if something needs to be escalated?

While we aim to identify any risks, challenges and potential escalations up front, and mitigate them, time-to-time escalations do arise. An escalation is a situation when things are not working out or happening as expected, which if ignored, are likely to affect the healthy outcome of the project. At rtCamp we handle all escalations, regardless of whether they are large or small, promptly and with the most serious attention. 

Examples of possible escalation include, but are not limited to:

1. There was an unplanned delay in delivery of task/milestone
2. The team was not available at and agreed time period
3. The quality or details or what was delivered was not as expected

When an escalation arises, we have a formal process in place to guarantee immediate mitigation occurs. We utilize an escalation matrix to create clarity on role/ownership which can be seen below:

Ultimately, we run our projects, escalations included, as transparently as possible. If things arise that need more support than just the initial project team, you will be kept in the loop throughout the escalation remediation action.

How does testing happen?

We have an in-house QA Engineering team, with QA support assigned to each project.  Each developed solution, or feature,  is thoroughly tested on the latest versions of major browsers and within popular mobile resolutions. If there is an existing site data about the browsers and mobile resolutions is collected from the Analytics platform and testing is performed accordingly. 

Development is tested on the latest version of major browsers on desktop as well as mobile devices as in the below table:

If the project is geared towards launching the first version of a website, we will convey which standard browsers and mobile resolutions will be considered, and define these up front with you ahead of QA taking place. 

To perform cross browser testing we use Browser Stack service. This allows testing the websites in different browsers on different platforms and mobile devices.

If any issues are found by the QAE, they are  reported in our Project Management System, where they are then addressed by the Engineering team. A final round of testing is performed by the QAE before handing over the website to Client UAT.

While we do aim to catch as many bugs as possible ahead of UAT, and Launch, testing is geared at identifying common issues. Therefore, not all nuanced issues may be captured during QA, which is why a thorough UAT is critical ahead of launching.

What does launching look like? 

To avoid exposing unnecessary risk, we always recommend launching  Monday through Thursday, and during the time when there is the least traffic on the website. Well-defined operating processes are shared ahead of time outlining pe-launch, launch and post-launch activities and explorations. Our launch documentation specially highlights who is responsible for each action, and when. This ensures alignment of all involved parties on what, and when, everything is happening.

Such operating processes look like:

1. Pre-launch

1. Decide the date and time for the launch
2. Do the code and content freeze 3 days prior to the launch date
3. Have a launch checklist in place
4. Do the URL search-replace
5. Verify the site once again by making an entry in the local machine’s hosts file
6. Communicate any DNS switching details to the Client so that they can convey the same to respective stakeholders within their team
7. Inform about reducing the TTL to the lowest possible value to ensure least to no downtime during DNS switch
8. Setup a “Pre-launch sync” meeting with project stakeholders for a day prior to the launch day
9. Setup a live bridge (“Launch” meeting) with necessary stakeholders for the launch day

2. During launch

1. Check the live traffic on the website through Analytics platform
2. If there is least or no traffic, then request the Client’s team to switch the DNS
3. Ensure the SSL certificate is installed and configured
4. Open the site for SEO from “Settings > General” screen on WordPress dashboard
5. Verify the /robots.txt has correct rules and sitemap.xml is present
6. Check top level pages and test form submissions

3. Post launch

1. QAE to review the entire site, form submissions and email delivery
2. Standard WordPress tests e.g. Add/edit/delete of post/page/taxonomy/media/user
3. Ensure there are no warnings/errors in the browser console, e.g. all URLs are https and there are no mixed content warnings
4. Connect Jetpack, GTM, Analytics, etc.
5. Verify the traffic is being captured in the Analytics

What happens after launch?

Once a project is live on production, we shift into a support window (offered to all Clients) for a stipulated time period. If any bugs are found during this support window (which is part of the scope), we will address them without any additional cost.

After the support window is over, all Clients are offered a Managed Services contract where rtCamp can continue support on r additional/ongoing enhancements or new feature development work.

Separate to support, With your permissions we prepare a draft case study, and put you in contact with our Marketing team who will likely seek a testimonial.. The final draft of the case study is shared with you for review and approval before publishing on our website.

How do invoices get sent?

You will find all payment terms within the Statement of Work, so expectations are set up front on when payment will be due. Depending on the project type, we operate under different payment terms. Some of the most commonly used at rtCamp are:

• Milestone based invoicing: this payment method is used for Fixed Price projects, issuing an invoice after each agreed upon milestone is complete. 
• Monthly invoicing: this payment method is used primarily for Staff Augmentation and Time & Material projects. A monthly invoice will be sent based on the hours consumed by the team for the month in arrears. Invoices are generated monthly based on the hours invested by the engineers.
• Pay as you go: we utilize this payment method for most of our retainer engagements. Blocks of hours are purchased, and paid for, and the team then works against those purchased hours over an agreed upon timeframe.