Distributed team: process details

Last week I shared an overview of NTR’s process, because, in the final analysis, no matter how talented the techs or smart the founder, anything goes better with a solid plan.

My boss is always saying, plan equals process, but I think of process more like a map that shows how to get from here to there.

We covered the first two steps — understanding your vision, market and biz, and the necessary paperwork — yesterday, so let’s get to the interesting stuff.

When it comes to software development, we offer three engagement options:

• Project
• Virtual Offshore Development Center (VDC)
• Dedicated Offshore Development Center (DDC)

Here is what is involved with each:

Project involvement.
When requirements are well-specified and detailed we can work with you on a fixed-cost, project-based premise.

This means that you provide us with a detailed requirements document for the software and based on that we estimate the project in detail, factor in the development risks, and provide you with a fixed cost/fixed time proposal.
Substantial requirements changes will trigger change management procedures, including contract renegotiation if necessary.
We are responsible for project management, while QA can be on either side.

VDC (time-and-materials)
The development team is flexible, based on your needs. 

We track all developer working hours and bills are based on those reports. Invoices w/timesheets are submitted by email or online access and paid monthly.

Project management and QA can be on either side.
VDC is suited for fast-paced environments where the time to renegotiate a contract is too costly in terms of both deadlines and money.

DDC (dedicated staff)
The team is stable — works only on the clients business — allowing it to build a deep competence in the customer’s product, needs and processes.

We usually work iteratively and you pay either for each iteration based on time and material reports or a fixed monthly amount.

NTR offers two development process options, depending on the specific situation

• Agile
• Rational Unified

 

Agile process, typically SCRUM-based
Agile rests on four main iterative activities (listening, designing, coding and testing) with the following process highlights:

• continuous customer interaction;
• continuous testing;
• early feasibility studies;
• early prototyping;
• early detailed software design;
• early functional software;
• gradual feature addition.

Typical activities include:

• daily status meetings
• planning reminders
• code reviews
• unit testing
• weekly customer demos

Rational Unified process
A four-phase approach (inception, elaboration, construction and transition):

• starts with business needs and context analysis;
• produce the project plan and description;
• consider challenges and basic architecture;
• create development plan;
• write the code;
• complete all necessary testing and feedback-driven adjustments. This includes all customer-specific options.

Step 3

The quality and efficiency of your experience with any kind of remote work is heavily dependent on the quality of communications that facilitates the teamwork.

We use a variety of communications technology, combined with written documentation that avoids misunderstandings, mishearings or memory lapses.

As I keep saying, communications are paramount. Together we choose the optimal communication tools we set up

• a rhythm of daily or weekly meetings, along with whatever additional communications are needed;
• a solid online project management tool or issue tracker;
• a tool to collaborate and share all sorts of documents about the product; and
• tools that allow effective distributed collaboration for engineering activities.

Step 4

When applicable we build a UI prototype.

We make an interactive prototype, correct and change it depending on customer feedback, and only after that do we make the real prototype.

Step 5

Each project has a project manager and lead developer. We start coding when the spec is decided using the agreed upon development method (Agile or Rational Unified)

Step 6

We move to small one- or two-week iterations sequentially increasing the functionality of the application.

Step 7

We use a variety of technology to track errors and store the code on GitHub to facilitate full integration.

Step 8

We build effective tests into the planning process at the start, because that is the best way to assure quality and prove your application is ready to launch. Testing includes setting up measurement tools, including KPIs, if applicable.

We have our own team of QA engineers. They conduct both manual and automated testing as needed.

Step 9

Launching is always a multi-faceted process. We make sure that the marketing build-up, actual product launch, and data migration (if applicable) occur at the same time.

Step 10

Comprehensive Support

After product delivery we provide support, warranty bug fixes and usually continue developing future versions, allowing you to focus on market and monetization.

These are the details of our development process — from the seeds (AKA paperwork) to the beautiful flowers (product delivery) and berries (comprehensive support).

As NTR’s business development manager I don’t really need to know these details; even when I work with potential clients these details are beyond our typical conversation — they belong to our accounts and tech guys.

But I believe that what really distinguishes great workers from OK ones is the will to do and learn and know more.

For me, understanding how things go from idea to solid code, per aspera ad astra, really helps me  integrate into the very living essence of your company, to really feel part of it, not just a contractor, but someone who helps your dream grow and blossom — like a bee to the flower. Maybe that sounds corny, but it is how I feel.

Join me next week when I start sharing stories about our departments, people and especially the newest part of NTR — hardware. You’ll have fun. Bye!