Why Remote Software Development Works? The Story Of A Startup #tagvenue From London

What is this story about?

I dedicate this story to all the people I’ve recently met in London. Sometimes it's hard to believe that remote software development works, but by sharing this story I want to prove that with the right team and the process you can build your dreamed startup from scratch in a couple of months.

Many folks are trying to find a technical partner to build great online startups. I wrote an article about that recently. The same happened to Maks and Artur they were in need of a great team, as they wanted to build an online portal. Time and budget were limited.

This is a story of startup owners who found the right technical partner. The story of testing assumptions and continuous learning during the process of building the product in an iterative, agile way. Story of an aware product owner taking responsibility for the backlog, which allowed our team to deliver the product live, while still having to built part of the initial scope. And most of all this is a story of growing mutual trust, even though the project was built with 100% remote cooperation between #tagvenue owners - Maks in London and Artur in Krakow - and our software house in Gdynia.

Do you want to know, how we did it? Let’s see!

First Date and challenges

Artur found DeSmart online in one of the software houses catalogs. He checked our website and decided to get in touch. After the first call we knew we can build something interesting together. Since he had some concerns and his business partner Maks wasn’t 100% sure that we are the right team, we have decided to convince both guys. Piotr and I flew to London where we met Maks in Pret à Manger and had a really interesting discussion, after which we have decided to move on with the project.Meeting face to face helped both sides to engage in the project and consequently, sign the agreement.

The process at first

Artur and Maks told us, that they want to build a portal where users can find and book a venue for a specific event - a conference, a company party etc. A simple database with a search engine and profiles. The goal was to create a great user experience while booking the venue and help the venue owners get some additional profit from the reservations.

Creating software is not a simple task, as we know very well after years of working in software development. You can have extensive experience, but stil every project is unique - different functionalities, different client. Even if you ask for a copy of Uber, you won’t get it. You need to accept that your product will differ on many levels. That’s why we have explained to Maks and Artur that although there are similar portals, their website needs a bespoke touch.

Maks wanted to make sure that we will be effective and deliver the promised piece of #tagvenue at a specific time. To make such a commitment we had to build a prototype first. Working with Agile process, we never promise anything without knowing what we are about to build. You need to be flexible in software development. With proper methodology, the distance (in remote development) or project management will not constitute a problem. Everything was under control from the beginning. The business owner wants to build a great product and he has the business side, but we are the tech craftsmen, who know how to build things properly. Guys from #tagvenue were skeptical at the beginning, but we gave it a try and it was a good decision. Maks said once “we need coders not advisors” when we started rejecting his ideas or suggesting some other solutions. Later on he was happy that we were arguing, because he realised, that this is what it’s all about - arguing, finding better and more effective solutions together and building the online product the users want.

Education before work

Before we started working on this project, we had to teach Maks how the Agile process works and why it requires his attention. He wasn’t familiar with the approach, so it was challenging at first. Initially, he was skeptical, but at the end of the day he found that working in weekly sprints makes sense and it allows us to deliver software according to our assumptions.

Special force - team needed

After first meetings we have decided to put the following folks into the game: 1 front - end developers, 3 PHP developers, 1 UX Designer, 1 tester and 1 product manager.

Maks and Artur from #tagvenue were assigned the role of the Product Owner, one of the most important roles of the project, the leader who makes decisions. They became a part of the team and were pushed to meet regularly to see all updates, demos and to confirm, that we’re heading in the right direction. The role was challenging for them and required a lot of effort but it paid off.

Let’s draw it - prototyping phase

Knowing the team, we started working on a prototype in March 2015. Maks created user stories (like “as a user in order to find a venue for my conference matching the size of an event, I want to be able to filter results by venue capacity”) and based on that our UX Designer - Ewa started building a prototype with UXPin. It was continuous work. Every view required a consultation and was commented on a number of times. Some people think prototyping is easy. That’s just partially true. In many cases, it’s a bunch of iterations to get the right information infrastructure and feel about the software. Look below and see how many comments (green dots) were exchanged between Maks and Ewa on only one screen.

The whole prototyping phase took over 1,5 months and required attention from both sides of the team.Prototyping is crucial because you can change something really fast and it doesn’t require work from developers. It’s flexible, you can think about the user experience details, which you don’t have in your requirements or brief.

Maks and Artur even regretted that they didn’t test everything on the prototype with the users. During the development process some issues were unclear and we had to focus on different ones that had lower priority. The most important features required bigger attention and verification on user's site.

In general, I recommend everyone - don’t write 30-pages briefs or requirements. It doesn’t make sense at the beginning. Build a prototype instead you can see what you finally want to achieve and where you will find a bottleneck. If you build a startup you also need to be flexible - change is an inevitable part of the process. You create something, you test it with users and see if they can complete the task and then leave it or re-build it. Don’t be a smart-ass guy, test your product with users properly and make sure you build a product that people really want.

When we have finished the prototype we had clarity on the online product we need to create and all challenges ahead (business and tech issues). Now we were able to estimate, how many sprints it will take to launch the website.

We have assumed that we need around 15 sprints to build #tagvenue.

Crafting time

Time to develop stuff. Since we are believers in an iterative delivery of business value, where after each iteration the client can see part of working product, we have worked in weekly sprints. The first sprint started on Wednesday with Sprint Planning. During planning the whole team discusses what to create in upcoming week. The goal is to define finished functionalities, which will be delivered within this week.

During the following sprints, each Wednesday at 1 PM the team and the client were gathering for 3h to review the previous sprint, plan the next sprint and do the retrospective. Every review took around 1 hour when every team member was presenting what he has accomplished, where he has noticed some challenges and what was good and bad in the process. It was followed by planning of the following sprint for another 30-60 minutes and finished with around 1-hour of retrospective. Maks and Artur never did retrospectives before but found it very helpful to express their feelings and to find out what the team thinks about the process (and themselves). It united the client and the development team. Honesty and trust were really important part of the process. It was like a marriage - you need to say what you think to make sure, everyone is on the same page.

A weekly sprint is a short period of time, but it gives you flexibility. You control the scope and costs which are really important, with limited resources.

On top of it we have organized weekly Backlog Refinement meetings each Monday at noon - a time dedicated to discussing details of user stories and possible implementation of user’s story goal. When the story was clear, the team could estimate it, and based on the estimation and business value of the story Maks and Artur were able to prioritize the task. It wasn’t uncommon for them to find they would rather drop the story for the time being and invest team’s effort into something more valuable at the time.

Product Owner is the King

Maks and Artur were really involved in the project. They knew the importance of being prepared for each meeting. Running many tests with the users, they were collecting feedback for developers. As decision makers, Maks and Artur had to give clear instructions and make sure there is an understanding. Building software with a remote team required a lot of patience and honesty from them and it was a great lesson for both sides.

During the process, before even all major features were delivered, Maks and Artur decided to launch the website ASAP to verify, what people think about it. With such info, we could discuss the product again and make some changes to make it more suitable for the user's needs.

Additionally, hearing a really positive feedback from users was very motivating and satisfying for everyone.

Every Startup Owner needs to pay attention to the product and cooperate with the tech team closely. Without good communication skills, maturity and trust you might have some issues during the development phase.

Tools and communication

When you work remotely you need proper tools to achieve your goal and make sure people will feel comfortable and communicate properly. We were using the following:

• Pivotal Tracker- a project management tool, where people clearly see what needs to be done and when. It’s used by the Product Owner and the Team to manage Product Backlog,
• Our Whiteboard- the tangible and visual board is always better than online tools like Trello for the team that sits together in one room. You can focus on one task at hand and things are done quicker,
• Nico - Nico Calendar- it helps people to express their feelings about the project and pick up on some negative fluids during the week. You can quickly solve a problem when you see that someone has issues and is in need of your support,
• Slack- we’ve implemented Slack a long time ago and so far it’s been the best communication tool we’ve ever used at DeSmart. A dedicated channel was created for the team and the Product Owner, where they could easily reach each other,
• Skype- this is important, except the first meeting in person with Maks in London, we’ve never seen each other personally. We prefer to catch up with clients and even meet them in our office, but sometimes they are quite busy. In this case, Maks was very disciplined and it worked out.

Building the #tagvenue we proved that remote development works effectively, but with a couple of conditions:

• The client and the team need to communicate very often and need to express their feelings,
• Both sides need to trust each other,
• They need to be disciplined to participate in every Demo Day when they are prepared for the next week,
• Both sides need to take part in the discussion and understand each other's need.

What do clients say about building their startup?

We always say that we work with partners, not clients. And it’s true - the client knows the business side, we are the tech experts. As a team, we can achieve great results. I decided to ask Maks about his experience with building #tagvenue because he can share some valuable insights and is the most reliable person to do it:

It’s a first time we did such a software project. We were going to start cooperation with the carefully-selected but still unfamiliar team. So there was a lot of uncertainty.

From the beginning, I was impressed with DeSmart’s project management skills. The team seemed to be experienced and knew how to approach software building. They understood startup culture and seemed to be the right people to advise us on the implementation.

However, in the beginning we still weren't confident that we are going with the right team and how it will work out. What helped me to build trust was transparency of all software agency activities. Right now my trust in the team is much bigger. I know they will do a proper architecture, testing and are focused on our goals. We acquired confidence with each delivered Sprint with a set of features.

I would say designing a good quality product with great functionality. You discover many new things during the project and you have to make sure you know what you are doing. There are also times when developers are ahead of you, i.e. the development is going faster than product planning. It creates additional pressure and this is where agile process helps.

DeSmart uses some good tools like Pivotal Tracker to keep the process truly agile, transparent and efficient. They have a lot of knowledge about how it should be done and what works and what doesn't.

I’m very open to remote work. True, you can have a better visibility over developers when they are in-house, but when you need to build a big software product fast and need a well-rounded team with experience that can work well together - good agency can be a better option. For in-house, I would have to hire 5 developers straight away that have complementary skills and can work as a team - it is very difficult and time consuming. DeSmart guys produced good quality code and their communication skills are great so I think they are a good solution. ​

If you have a budget and you want to build a nice product quickly - it works. You will receive a lot of advice from them and can learn a lot from how their team functions. They develop the product in such a way that it is easy for a smaller inhouse team to take it over. So for support and ongoing development you can hire someone internally.

• What was your biggest worry about building the online product at the beginning?
• How did you feel about working with DeSmart at the beginning and how did it change during the development process?
• What was the biggest challenge in the role of the Product Owner?
• How do you find remote software development as a way of building a startup?
• Would you recommend this method to young startups, looking for tech experts?

London and Poland - an opportunity for software development success

I’ve been to London recently and I know, that many people are searching for a good tech team. The startup scene is getting bigger and bigger. Financial London meets creative people who want to change the world. Many are non-tech and here is where we can help. By building #tagvenue we proved that such a cooperation can work and be beneficial for both sides. There will always be some obstacles and issues, but don’t be afraid to talk about them. Communication and transparency are the keys to successful software development.

Check this out: tagvenue.com

I hope this story opens your eyes to cooperation. Each such project is challenging, but the more we create, the better is our process and we make sure people who build a startup with us will deliver the right product at the right time.

Maybe you are a person who wants to create something awesome? Let me know and let’s start talking about your great idea (send a message to [email protected] or use our contact form)

Author: Damian Winkowski, New Business Developer, DeSmart