How to manage your StartUp

What makes startups so specific?

The startup, is it the same as a usual project that already has it’s the audience? Should they be approached in the same way using the same technologies? 

There are three core points that you need to achieve to make the development process smooth.

1. Speed – you need to prioritize development speed, rather than long standups and planning.

2. Flexibility – you need to be able to prioritize other tasks, or do a turn over without damaging the overall scope.

3. Planning – even the overall scopes may change, you still need to have a plan in the head or on paper.

Knowing all that, let’s see how usual management techniques apply all that.

SCRUM:

Benefits: Clearness of what is going on and when each feature will be released. New tasks can easily be added and removed, but only after sprint ends. With 2-4 run-up sprints team find their perfect shape and can continue working with a better speed.

Minuses: Very expensive due to the massive verity of meetings and no ability to update ongoing sprints. Therefore brings real benefits only for large or remote teams. Works exclusively of continuing development (6+ months).
Definitely not a solution for Startups because they always start with a small team, have a lack of budget, need to be flexible at any hour/minute/second and do not plan ongoing development for a long time. 2-4 run-up sprints time might be enough to finish the first MVP version, not just to become filling comfortable

Waterfall:

Benefits: Client gets a full project specification. The client will always have a fixed budget

Minuses: Do not allow to be iterative and flexible. Adding new feature require to change a lot of documents, resigning contract and a lot more painful actions.
Also will not work for startups. They do not need a highly documented product, because with every change – the documentation will be outdated. Instead, startups need flexibility in their actions.

Kanban:

Benefits: To be honest, it’s quite a good way to go for startups. It has nearly no time waste for operational work and is highly flexible when it comes to change your plans.

Minuses: When on SCRUM there are too many meetings(plan a sprint, allocate it, estimate, retrospective old dash and so on) Kanban has a lack of it. Even you’re a startup, not understanding deliverables, or ability periodically verify results and improving may quickly lead a project in the wrong direction.
Therefore we like to work with a combination. Scrumban is a compromise between SCRUM planning & Kanban speed and flexibility.

Services that we recommend to go with.

• Communication – Slack. Workspaces giving the possibility to have everything related only to this project. Have video calls, public/private channels and a lot more. Is free to use.
• Status tracking – Kanban board Trello. Gives all required features like visualization, estimation, time logging, tagging tasks, planning releases, etc. Is free to use.
• Repositories – GitLab as a remote repository. It has all the necessary features for tracking code state and performance. Github or Bitbucket can also be as an alternative.
• CI & CD – Bitrise as a continuous integration tool for a Mobile. Forge for Back-end & Front-end.
• Design – Sketch, Zeplin or Figma for developers. Figma or Invision for interactive version.

Starting your road:

• Client and his team will be invited into their own Slack and will have access to Trello Board and GitLab remote repository.
• Also, for every product, we create a Google sheet document with project description. This file will contain information about every team member, information about every platform(Architecture, central libraries, dependency manager, language), a timeline of a project with all intermediate release dates, and a payments information.
• If a client hires our QA Engineer, he will get created all test cases for his project. Test cases are a list of actions and expected result that QA use for performing regression testing. This doc might be useful to understand the scope of a project and as small documentation of business logic. It’s always helpful to have a document that explains how the app should behave from the usual user case until the strange edge cases. But rarely, Startup has a resource to create professional documentation. Then, we can always refer to our test cases.
• Every project will have allocated a responsible Delivery manager. This person will set up and control all services, will be in charge what is going on and what is the status of a project, will be collecting new client requests and transforming into described tickets, will be performing demos, will handling all documentation(invoicing, contracts, project information file, etc.) Such an approach allows the client to save his time searching for a responsible person and trying to communicate new information to every team member. From the side of developers – they will always get the latest news filled adequately on the board and will have a single person that knows everything about each moment of a product to ask their question. This will be a highly professional member of NerdzLab that will be able to help the client from any aspects and to save time for both sides by collecting all information in one place – him.
• Even Delivery manager can handle most of your request, we prefer our clients to communicate with their team actively. This is the guys that responsible for your idea, they will be leaving it the nearest time, and they are bringing the most benefit. Making an inofficial environment, where they can easily communicate with a client, gives them the ability to invent something special for you!

Process:

• First-week Delivery will create all services and documents, will setup Kanban board(Trello preferred) and communication tool(Slack preferred), will define a list of milestones and what needs to be done in each of them.
• We recommend using International approach(Design -> 50% backend -> mobile and web) and try not to go in parallel while there is no need. This will give a better product in the end.
• After development starts we recommend to have a demo(sprints) not less than every week or two. It is the minimum time to finish a good chunk of work on both backend and frontend.
• At every release, our QA will be doing a regression testing week before based on already described Test cases. This will allow us to be sure that every new change has not broken some existing functionality.

This is the flow we like. Still, each project and client is unique, so we adapt quickly to different needs and environments. It’s not our one and only religion, but the thing that proved to work and give results!