Speed is the key of success in a startup like Geoblink: we have to attract new clients and we have to make current clients happy as we have to stand out among emerging competitors. So a fast process to develop new features is needed.
We lean on Agile methodology to assure fast development of every task, which is an alternative to traditional project management. We use Scrum as way of applying Agile methodology. Every company does this differently, at Geoblink we use this framework:
Sprint: our unit of time is called sprint. A sprint lasts two weeks, and during every sprint we have some meetings often seen in Agile methodology.
Daily stand up: the Core and Data teams meet up during 15 min every morning so developers quickly go over what they did yesterday, what are they doing today. Dependencies are also shared to avoid blocking anyone of the team.
Sprint status: at the middle of the sprint we meet to agree which tasks will be completed before the end of the sprint or not.
Sprint preparation: before the end of the sprint, the leads of each team (Core, Data and Product) meet up in order to define which tasks should be done during the next sprint.
Company Demo: due to the high rate of changes that the product suffers, it is very important to communicate them to the rest of the team.
Retrospective: at the end of every sprint the Tech team talks about what went well, what did not and what should be improved. This is very useful to avoid repeating failures or inefficiencies.
Introducing new features: from idea to production
The are different ways to come up with a new feature, implement it and validate it. This is the cycle we normally use at Geoblink:
Utility: When the Product team thinks about a new idea (or we are asked about a new feature), we test its utility either asking a few clients or discussing it internally.
Feasibility: once we consider a feature adds value to our product, we talk with the Tech team to discuss its feasibility and estimate time to implement as we create a mock.
Implementation: developers build the features.
Validation: when features are built it’s time to validate new changes.
This is my main task at Geoblink. Thanks to Jira not only we can assign the tasks to different developers but we can also distinguish the different states of the tasks: this is very important as I can go directly to the Geoblink app in a preproduction environment to test any new changes. Apart from my validation, developers previously approve the code relying on Bitbucket, a code repository that includes a peer review tool. At this point there is a little bit of back and forth between the Product and Tech team: it is very important to define every task needed to implement the feature so we avoid as much as possible friction during this process; however even if you define every task thoroughly, things might have to change when implemented which means further iterations.
When tasks are validated (might not be perfect, but they meet the definition of done) they are deployed to production and tickets closed in Jira. Now it is time to show these brand new features to our clients.
http://tech.geoblink.com/wp-content/uploads/2016/10/GeoblinkTech.png00Ricardo Boludahttp://tech.geoblink.com/wp-content/uploads/2016/10/GeoblinkTech.pngRicardo Boluda2017-05-02 12:00:462017-05-23 14:07:38Working in a SaaS product department