Remote Software Development Process

This is our remote software development process at BeautifulCode. We compiled this article from our five years of learning and continue to refine it on a quarterly basis as we retrospect on what is working and and what is not. Our area of specialization is setting up effective remote engineering teams and our model is a variation of the traditional scrum model that we have employed to launch several products to market for our clients.

The Team Setup

What is a remote engineering team?

A remote engineering team typically sits away from the company “headquarters”. Two main reasons for working with such a remote engineering team are technology competence and cost efficiency. Often times the remote engineering team is a third party outsourcing company.

What are the roles and responsibilities?

To put simply, you as a client, are responsible for communicating what has to be built. Ideally one person, call it product manager or the product owner, from your company will work with the remote engineering team to get your mobile or web application built.

The remote engineering team actually builds the software. Since the actual building process requires distinct competencies several people are involved.

  • Client:
    • Product manager:
      • Document and communicate the requirements
      • Answer any questions the remote team might have
      • Work with the end users to test UI prototypes
      • Do UAT testing after the feature is delivered
  • BeautifulCode’s remote engineering team:
    • Product owner:
      • Ask questions and understand the user story(requirements) completely
      • Act as a local point of contact to help developers understand the requirements.
      • Work with the in house designer to come up with prototypes.
      • Responsible for the delivery of the user story on time.
    • Engineering lead:
      • Ask questions and understand the user story(requirements) completely
      • Come up with an architecture to implement the user story.
      • Break down the user stories into sub-tasks
      • Lead story point estimation exercise for the sub-tasks.
      • Code review.
    • UI designer:
      • Prepares click through prototypes for the user stories.
    • Developers:
      • Code the feature
      • Write unit/integration tests
      • End-to-end testing
What kind of projects are done at BeautifulCode with the remote engineering team setup?

Projects at BeautifulCode last anywhere from a couple of months to several years. Some of our clients are interested in testing out an idea and want us to build an MVP version of the software in 4-6 weeks. On the other hand we have worked with large businesses that have a roadmap of several years. Here are examples of some of our projects.

  • Mobile application and an admin site: A serial entrepreneur from Los Angeles approached us with a business idea. We translated his ideas into product definition. The goal of this project was to build an minimum viable product(MVP) version of an iOS application and a Ruby on rails based portal for admins. This project took us about 6 weeks.
  • A customer facing portal for a large company based out of San Francisco: BeautifulCode built a customer facing portal and automated several processes of the operations. This is a multi-year project that began with rolling out of MVP in 6 weeks. Post MVP launch and feedback from the users, the product management team and the BeautifulCode team have been working together to define and launch new features.

Here is our portfolio

The Software Development Process

Let say that you want to build a web application. You have done enough field research and now you know that customers love your idea and you believe that they will actually use your product.

MVP Phase

At the beginning of this phase all you have is an idea and some data points on the potential of your idea. The goal of this phase is to translate this idea into reality as soon as possible and put the software in front of real world users.

At BeautifulCode, we are loyal fans of the google design sprint. We’ve used the google design sprint on multiple occasions and experience has proved to us time and again the benefits of focussed team work in solving a problem. The design sprint team consists of a product manager, end users (the product manager could proxy for them), UI designers, engineering lead and a couple of developers. We plan to dedicate a week to immerse in the challenge and go hard at solving it.

Here is a typical week of execution that produces a prototype for the idea.

  • Day 1 – Understand the problem: We try to understand the problem that we have to solve. We ask a lot of questions to our clients on this day.
  • Day 2 – Diverge: Form multiple teams or think individually to see how you can solve the problem. At the end of the day all the teams will walk the rest of the team through their solutions.
  • Day 3 – Converge: Today is the day to sit together and come up with a best solution by borrowing ideas from multiple versions in the previous round.
  • Day 4 – Prototype: Now that we have the best solution on paper it is time to convert it into a high fidelity click-through prototype. We tend to use the Sketch software. But you could use powerpoint, photoshop etc..
  • Day 5 – Testing: Put the prototype in front of the end users and check how they are using the prototype. You could also interview them to get more feedback.

Feedback collected on the clickable prototypes would be incorporated the following week and the development of the MVP can be started with confidence. The design sprint experience converges multiple stakeholders thinking and sets up the developer team to focus on execution with a clear picture of the end goal. Depending on the scope of the project, development of the MVP would be done in about 4-6 weeks.

Post MVP Development

Now that you have developed the MVP and the users are loving it, you are eager to add the next set of features to the software. You identify and define new functionality as part of the product roadmap planning. The development team gets into a sprint cycle rhythm and cranks out the code. Simple. Right? Not really.

The reality is messy and while theoretically the traditional development sprints work, we’ve seen some recurring problems.

  • Insufficient detail on the user story: Ideally, the product team should be able to provide all the details so that the developers can focus on implementation. While this thinking works for lower complexity features, there is a good chance that the product team would have to flush out more details after going through a discussion with the developers. This puts both the product and development teams under pressure to resolve the missing details and implement in the same cycle.
  • Lack of mock ups for the feature: Most of the time the developers clearly understand the user story. But in some cases the feature gets complicated or several screens are involved in the user flow. In such cases it is always advisable to prepare high fidelity prototypes and get the buy in of the product manager before the development starts. Having such “approved” mocks will make sure that the developers are building the right thing.

    There is one more reason to do a high fidelity prototype. If you are making a UI change or implementing a complex feature and you don’t know if your customers will like it or not it is advisable to prepare multiple versions of the prototype and put them in front of users well ahead of the development sprint. Developers time is best used if they gave life to a “user-approved” mocks.

  • Multiple ways to architect the solution or split responsibilities: In most cases the your remote engineering team will be building a standalone web/mobile application. This simply means that all the user stories will be developed by the remote team without any external team getting involved. But if there are user stories that needs involvement of other teams in your organization, it will be wise to involve them in advance and spill out the responsibilities before the development sprint starts.
  • Dependency on third party teams/APIs: From time to time you’ll run into cases where you want your remote team to use third party APIs or work with another remote team. If the APIs are stable and you know the other remote team well, having dependency on them does not pose any major challenge in the development sprint.

On the other hand if the APIs are untested or you have not worked with the third party team there will be surprises when the development work starts.

The chances of running into the above issues go up as the product complexity goes up over time. We’ve modified the traditional sprint process to solve for these practical problems.

Run two parallel sprints: Product sprint and Development sprint

The key idea is to implement a process that focuses on detailing and estimating the product feature much before the development team is ready to take it up for implementation. While there is an element of this process in the traditional scrum, the product team is under pressure to provide the detail so that the development team can implement it in the same sprint. The aim of the Product sprint is detail features about two sprints in advance so that the Development sprint is a case of simple execution as the team has sufficient detail of what each user story entails.

The Product sprint

Goal: The goal of this sprint is to make sure that there are no open questions or blockers once the developers pick the user story and start the implementation in about two to four weeks time. So, obviously product sprints must run ahead of development sprint. But do note that it is not advisable for the product sprint to be several sprints ahead of the development sprint. In such a case the requirements could get stale by the time the developers can start working on the sprint. The agility of the scrum process gets lost if developers are working on stale requirements.

Sprint Cycle: Usually the product sprint cycle duration matches the development sprint cycle. If the development sprint is 2 weeks long, so is the product sprint.

What do we do in the product sprint?
  • Understand the user story: Now is the time to really understand the nitty gritty details. This is also a good time to understand external dependencies and data dependencies. If other teams are involved in this the product manager can start the conversation with them as well. Though agile development process prefers code over documentation a PRD becomes necessary when the team is distributed.
  • Prepare click through prototyping: Once we have understood the feature it is time to crank out one or two versions of clickable prototype. If the user story is straightforward this step is optional. On the other hand if there are complex workflows, the clickable prototypes are highly recommended. Once prototypes are ready the product manager can talk to a few end users and collect feedback to be incorporated.
  • Story points estimation: Since the whole team is deeply involved in the feature at this stage it makes sense to think about breaking the user story into sub-tasks and estimate the effort required to implement the story.
Development sprint

Goal: Thanks to the Product sprint, the product manager can prioritize a set of user stories for implementation and the development team can get started on the development right away. Recall that the developers too participated in the Product sprint during ‘Story Time’ sessions to better understand the user story and identify technical challenges if any. This helps the team to think of various nitty gritties in advance and primes them for quality development. This sprint focuses largely on development practices such as feature implementation (with tests), code reviews, product signoffs culminating in the release of the feature to the users.

Sprint Cycle: 1-3 Weeks. 2 week sprints are more common.

What do we do in this phase?
  • Sprint planning meeting: The sprint starts with a sprint planning meeting. Thanks to product sprint, all the product backlog items are the top of the list are well defined. The goal of the meeting is to prioritize and pick the user stories that will be worked on in the sprint.
  • Demo: Towards the end of the sprint the product owner will demo the newly implemented user stories to the product manager. This gives the product manager a chance to see the feature in action and provide feedback.
  • Launch to Staging: After incorporating the feedback from the product manager, the code is launched to staging for UAT testing.
  • Sprint retrospective: The sprint concludes with a retrospective. This gives the development team a chance to reflect on what happened in the sprint and learn from it.

After a few of these sprint cycle you would have launched most of the features from your roadmap.

© 2019 BeautifulCode