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.
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.
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.
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.
Here is our portfolio
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.
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.
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.
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.
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.
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.
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.
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.
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.
After a few of these sprint cycle you would have launched most of the features from your roadmap.