C H I L I

Chili Labs Delivery Culture.

We care about product delivery and we will maximally involve you to the development process to make it happen with greater pace and top-notch quality. We dream big and aim high. And once committed — WE DELIVER!

Chili Labs teams are facilitated by certified Alliance© Scrum Masters and following the best Agile / Scrum practises. We have gathered a unique expertise in delivering complex, world-class, online and offline products. People in Chili Labs are embracing changes & meetings for constant team improvements.

1. Project start

Before we grab a project - we investigate available materials and resources, get all the possible information about the project, business and people we will work with. Always asking crucial for project engagement questions and details, get familiar with clients business.
How they are making money? Is that a huge project to them, side project or just an experiment. Will it impact their current business?


Why do we need to know this?
It determines how involved the client is, how much of the time / effort they will dedicate to us. The more responsive client is, the better success app has! We believe it should be meaningful to both parties, as even from our best intentions without involvement from the client there is no success.


2. Scoping the project

Based on all of the information above we create a ballpark (very rough) estimate of the planned functionality.

The main idea is to split all the development functionality into small parts and estimate them separately. It’s valuable  — because we better understand the product you are about to create and by breaking down the project scope and understand on what the technical difficulties are ahead.

From the client side - it gives you the idea on studio overall pricing (what part of the app costs what). Helps you to compare studio with competitors and ensures that you can reevaluate the scope and remove some functionality, which means — reducing the price!

Development can almost always be split into separate modules. Therefore, it allows to remove/add functionality.

We always encourage clients to have MVP first. It’s always a safe option to have. You don’t risk that much money at the start of a project and can test, if your idea/app is viable. Remove unnecessary functionality from the estimate, to reduce the price — like: Two-factor authorization, FaceID, TouchID, etc., it can be added to the app later on and would not affect the app itself. Later on, when you realised that the idea is working, we can add development tempo and extra hands to catch up and make even better results in development the project for you.

3. Understanding the project

Without proper specification there is very low chance that you will receive correct result. Either you are working with Agile methodology, with rapid changing of a scope, or we create a detailed technical documentation on what actually should be delivered by us to you.

3.1. Drawing the map:

The first step would be to draw functionality or a “mind map”. The goal is to put all the possible transitions, screens, states and events on a whiteboard. It’s done to make sure we haven’t forgotten anything. You can clearly see all the navigation and logical components/epics of the upcoming app. It also helps you to entirely understand the app, whether there are some strange moments and bad transitions / missing screens, etc.


Bullets + image of xmind:
  • Helps you with states
  • You understand how the app will work
  • Have a clear navigation model within the app
  • 3.2. Specification document:

    Based on visual functionality map, we create a document with detailed technical specifications:

  • Generic requirements
  • Mobile specific requirements
  • Logically split by modules, epics
  • Description of what should be done
  • Designs
  • Example with image?
    3.3. Timeline

    The purpose for Gantt chart is to understand the development plan on a timeline. For Agile projects — you should still create a timeline for project delivery. It can be done by sprints planned (usually sprints are done by modules / interconnected functionality). For Kanban projects (support projects) — Usually there is no need to draw a timeline, however, if it’s needed — you can use release versions to put milestones on a timeline.

    4. AGILE processes:

    Our teams are facilitated by Scrum Masters and are following the best Agile practises and the necessary meetings for constant team evolution. We work with Atlassian software, to maximize transparency in all of our projects. You will have full access to project boards, tickets, backlog and time reports. We will involve you to participate in Sprint planning / grooming sessions to identify issues for your business to be solved as a first priority.
    4.1. Planning

    Sprint planning
    — One of the most important “rituals” of the Agile. It consists of explanation and estimation of tickets (using scrum poker) and make sure that you and developers / QA understand what can be done. We use scrum poker, so the developers can’t be biased by their skill and knowledge, while estimating the tasks. Let’s say senior developer thinks the task is easy and estimates it for 1 hour (1 story point, no matter), then if it’s not hidden by poker. The less experienced programmers will have a pressure to put down a number that is higher than displayed by developer.

    Estimation
    —  The importance of estimate is essential as it helps us and you to plan workload of teams, budgeting and project completion.

    Team retrospective
      — Very important part of the sprint. Where we discuss what was done, what you did successfully, what not so good and what you can improve. Each iteration your team should be better than a week/bi-week before. Usually it’s a “closed curtain party”, as we are dealing with internal team tensions, but from time to time, we invite clients to take part in the retro’s to have an impact in the importance of a project, give a goal, overview or just see how the team is doing.

    4.2. Backlog grooming

    Backlog grooming
      — Preparation of tasks, in a way, that YOU understand it. You should use the good old component, epic, task system to split tasks by logics. Based on that you have to write a user story to each task and an approximate “To Do” as you understand it.

    Sprint grooming
    — Includes working with client priorities and setting the sprint goals from the business perspective. (Example — the client wants to have a learning module to be first on a staging server so they can finalize the requirements by that module to the third-party supplier, etc.)

    4.3. Weekly Demo

    Weekly demo
    - It is the most important meeting from the clients perspective —  each week showing the progress on a real device or by sharing the screen for the completed job with comments and guiding through the issues. Based on that, client can correct the team / PM’s work by setting the priorities and giving a feedback.

    Next sprint
    - By the end of a demo we indicate the next goals for upcoming sprint (module or functionality, that you would face on), for the client to be informed and QA team to be prepared.