In the beginning (of any product's development process) there was a
brilliant idea, intended to make people's lives easier. That idea, eager
to become a successful product, could be implemented in a million ways.
Some of those possible implementations are meant to fail. Others aren't worth the time and money. However, just a few of them, will turn out to be the right solutions.
We help our clients implement the right solutions –the ones that maximize both usability and revenue.
believe the best way to achieve this is through our development
process, refined over the years and enhanced by our skilled team, and
the set of values to which we are all committed.
Let us tell you about the Moove-it way.
Our cause is to enable innovation in organizations, building software products that truly improve people's lives. We develop usable, reliable and sustainable solutions for both business and social purposes.
Quality over quantity
That’s the key to our philosophy. We strive to deliver high quality software products and to provide the best service by constantly reviewing and improving every aspect of our processes.
We build strong relationships with our clients, based on mutual trust, and encourage close bonds among our team members.
Heart & Commitment
We work with passion. We are enthusiastic about the work we do and the products we help build.
We respect our clients. We put ourselves in their shoes, always listening intently to understand opinions that diverge from our own, and to contribute with new ideas.
Team over individuals
We are team players. We think that the best way to achieve great things is through a sustainable, strong and professional team.
Within each team, every individual’s point of view, expertise and initiative, contribute collaboratively to create something valuable.
Happiness and flourishing
We continuously seek to improve ourselves and develop our potential.
We cultivate and foster the three L’s: listen, listen and listen.
Working hard and having fun while doing so is our key to success.
Because we love what we do.
That’s how we flourish.
We are technology partners. We help architect and quickly develop software products and services, delivering meaningful outcomes to both our clients and their customers. We also assist our clients in making smarter choices about what they create and how they create.
We pursue excellence. We are committed to a high-quality development process by thoroughly testing the software we build, performing collaborative code reviews, and continuously evaluating our work processes.
We deliver a cost-effective service. We perform daily and weekly software builds, regularly sync with our clients, and always keep them up-to-date on their project’s progress. These processes help us ensure that our software meets our clients' evolving requirements and enables us to stay within agreed timelines and budgets.
We love challenges and we are keen learners. We know that every project provides us with valuable knowledge, and we always welcome new adventures. That’s made possible by our agilist development process, which allows our clients to explore innovative ideas at low risk. In addition, every member of the crew will always be ready to jump in and offer their advice.
We are professionals and we trust our staff. We have a strong team of
people who love working with each other. We manage our teams,
respecting everyone’s opinions, constantly keeping an eye on both the
efficiency of the projects whilst encouraging self-organization.
Last, but by no means least, we constantly strive to contribute to our community in various ways, including offering educational packages, trainee programs and by making charitable donations.
In order to build the right solution, the overall goal has to be clear to everyone involved in the project. Such product vision is the true north of every project.
"The product vision paints a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product – the critical information we must know to develop and launch a winning product." From the Scrum Alliance
We help discover the product vision through understanding and challenging the problem itself, the business strategy, the intended target customers, and the product’s value proposition.
We work side by side with our clients to identify the underlying assumptions about the target market. Who are the target customers? What problem is the product idea trying to solve? How it will generate revenue? What’s the biggest technical risk?
Those are just some of the questions we attempt to answer using the business model canvas.
It helps us understand the most important and most risky assumptions, highlighting the business’ weak spots that require immediate attention.
More often than not, the ideal user we have in mind does not match the real life end user. The road to success is paved with product ideas intended for the wrong user population.
We use personas to discover and synthesize a set of profiles describing a particular customer segment. Each profile describes a stereotypical user with a real name, story and personality, representing a set of users who share common characteristics.
Personas help us to build features with a particular user in mind, and contribute to better communication among the project's stakeholders.
We strongly believe in the wireframe stage of every project.
A wireframe is a visual guide that represents the skeletal framework of the product's user interface. It focuses on highlighting functionality and information architecture, on what has to be done and where it should be placed, but not on how it should look.
Wireframes help us display the product's architecture visually, improve communication with our clients, push usability to the forefront and save time on the entire project!
Wireframes are meant to be easily changed. Our UX team uses
paper, pencils, erasers and marker pens to draw wireframes. This gives
us freedom to explore different solutions.
Once the wireframes have been validated, the product under construction is ready to jump to the next step: the mockup.
Validating the user interface (both visuals and interaction) against representative users is crucial at this stage.
High-fidelity mockups help communicate the aesthetics and behavior of the product being built.
They allow stakeholders to interact with the product user interface with the aim of gathering insights about the user experience. The goal is to validate the entire workflow, colors, logo, images and transitions.
We use InVision as a tool to create high-fidelity mockups. It makes both face-to-face and remote user testing easy.
The success of a software development project depends on two aspects: effective communication and high technical capability.
Effective communication includes having well defined tasks, the clear assignment of responsibilities, explicit acceptance criteria, frequent checkpoints, visible progress reports, an effective dialog between stakeholders and, of course, an occasional beer with our clients.
High technical capability includes mastering the tools and languages involved in the development process, using automated software testing, the ability to discover and resolve technical risks, using good criteria to make estimations, coding fast, using best coding practices, and the ability to learn from failure.
Both aspects contribute to delivering the right product on time, having gone through a smooth development process.
We follow agile development methods because we believe they are a perfect fit for achieving effective communication and developing our technical capabilities.
Each project is unique and some agile methodologies fit better than others, depending on the particular case.
Scrum fits in nicely with most of our developments. For some projects, particularly maintenance projects, we would use Kanban instead.
We put into practice the three components of an agilist empirical process: transparency, inspection and adaptation. Transparency promotes information flow and creates an open work culture. Inspection allows us to review every aspect of the process. Adaptation allows the team and stakeholders to learn from the process and then adapt it, if required.
User stories describe how the product should behave from the customer’s perspective. Thus, they also tell designers and engineers what to do.
On a regular basis, the client and the team meet to review and reorganize user stories posted in the Product Backlog, and to plan the next iteration. In general, a Product Owner –normally, a member of the client team– is in charge of maintaining the Product Backlog.
Each user story should follow the INVEST model (Independent, Negotiable, Valuable, Estimable, Small and Testable) and must be focused on the value a user gains from using the product.
An iteration planning meeting will bring the whole team and the Product Owner together to plan the next iteration, lasting a period of one or two weeks.
Before the meeting starts, every team member gets familiar with the stories that will most likely be carried out in the next iteration. During the meeting, the Product Owner sets the priorities for the iteration and answers questions from the team.
Once the priorities are set and the stories are well defined, the
team estimates the effort required to complete them. We frequently use a
technique called Planning Poker to make estimations, based on an
exponential scale (1, 2, 3, 5, 8, 13…).
A number that is too high may indicate that the story involves too many activities and deserves a closer look. User stories that are overly complex are split into smaller stories.
In agreement with the Product Owner and based on the team's
historical development velocity, the team will commit to complete a
certain number of stories during the next iteration.
We are advocates of the “done means done” philosophy: a story is complete, only when the code tests pass and the features work as they're supposed to, meaning they're ready for production.
On a daily basis, each team gets together for 15 minutes to let every member share three things:
1. What he/she did yesterday
2. What he/she’s going to do today
3. What things are blocking him/her
The daily meeting fosters peer-to-peer sharing of information,
preventing miscommunication and detecting problems as early as possible.
We use either Skype or Google Hangouts to communicate with our clients.
Retrospective meetings, or retros, are key to adaptation, through making explicit what’s working fine and what needs improvement.
At the end of every iteration (commonly, every two weeks), each team
meets together to evaluate its performance, defining actions to take in
order to improve the overall process.
To make retro meetings as efficient as possible, we organize them into three stages:
1. Reviewing the action plan from the previous retro meeting.
2. Brainstorming and discussion. We drive this section using the start-stop-continue approach.
3. Creating an action plan and assigning responsibilities for each action item.
Unless a client's development environment prevents us from doing so, we prefer to use and strongly recommend Git as a project’s version control system.
Git beats other version control systems –such as SVN or CVS– in terms
of performance, distributed collaboration capabilities, repository
size, security and branch handling.
In addition, Git is free, open source and easy to use.
We systematically pair-review our code to make it more readable, better performant, less error-prone, to transfer knowledge, and to share good coding practices among team members. We are also advocates of continuous integration, meaning that, several times a day, we deliver production-ready code.
We use a combination of tools that help us facilitate both code reviews and continuous integration tasks. They allow our developers collaboratively to work on the code and get their code reviewed, as well as to review other people's code.
Once the tests are passing and the review process has been completed, the code is ready to be merged into the main branch. This process gives us and our clients certainty that:
We normally use Gerrit as a tool for code review.
The uploaded code, organized into commits, must be verified by other team members, called verifiers, before being merged into the master branch, which is where production-ready code lies.
Verifiers review all the modifications introduced by a commit and make comments about things that can be improved or fixed. Everyone in the company is encouraged to read the comments and contribute new ones.
Then, verifiers punctuate the commit choosing from a list of options:
-2: Cannot be merged. Errors were found or it does not meet required standards.
-1: Needs enhancements or discussion before merging.
+0: Trivial comments.
+1: Ok, but someone else needs to approve.
+2: Code is allowed to be merged.
The developer can then apply any of the requested modifications, update the revision, and the process starts over.
Once the review process has finished, the commit is ready to be merged into a particular destination branch. This happens only if the Continuous Integration server, the tool we describe below, has verified that all the tests pass.
Gerrit can work as an extra repository to manage the code review and the interactions with the Continuous Integration server. Once a commit gets merged into a branch, Gerrit can be configured to automatically push the code to another repository, like Bitbucket or GitHub.
In general, we use Jenkins as our Continuous Integration tool. Jenkins continuously builds and tests the code submitted to a project’s repository.
If the code breaks the tests, it cannot be merged with the master branch. We use Jenkins to make sure that failing code never slips into production.
Steps we follow in order to analyze partnership opportunities:
Our main source of leads is referrals from current and past clients.
The person responsible for the lead follow-up is a Business Developer, a Principal, or a Managing Director in some cases.
We track and follow-up our leads with Pipedrive.
We assign our professionals, based on the skill-sets required for each project.
We are happy to introduce the team members to a client, once we are positive they are a good fit for a particular project and client.
Our recruiting process is very thorough to guarantee talented
professionals. Consequently, we do not normally have "personal job
interviews" with potential clients.
We form teams with a minimum of 2 people in each one. A team member may be involved in more than one project, so they aren't necessarily full-time on any given project. This makes it easier to rotate team members, in case someone gets sick, is on vacation or leaves the company.
Some of the benefits of working here include paid Friday tech-lunches, training courses and certifications, a relaxed working environment, cool offices, an open-minded community, chill-out areas, bicycle racks, ping-pong and table football.
We strive for effective communication.
We complement face-to-face communication with video conferences, chat, email, ticketing and project management apps, and an ecosystem of integrated communication and development tools.
The list includes:
If a project requires it, we send daily or weekly summaries to our clients to keep them up to date with the progress. In some exceptional cases, part of the team might also travel to a client’s offices to work side by side.
Every Friday around noon, the entire company will gather together to share lunch and attend a technical talk in our seminar room.
The topics for these talks are defined by the team and then prepared by a single person.
Other than sharing good food, the goal is to keep the team updated in the latest technologies.
We believe in the benefits of formal and non-formal education. In a constantly-changing world, we foster an environment in which learning is a way of life.
That’s one of the reasons we encourage our team to take training courses and certifications.
Some of the most popular courses and certifications we take include:
In the software industry, it’s hard to find talent that can combine hard work with technical expertise, soft skills and a sustainable pace. Moove-it invests in people who demonstrate the potential to develop these qualities. Being an enthusiastic learner and a committed player are key for any applicant.
Our application process comprises three steps:
We all need regular checkpoints to review what we’ve been doing well and what things we need to improve on. That’s the only way to learn and flourish.
We believe that receiving honest feedback from the people you work with is the best way to grow professionally and personally. Thus, we take it very seriously.
We also know that not everybody feels confortable about giving and receiving feedback so, at Moove-it, we work hard to build a safe zone where people can talk honestly and openly about their success and failure stories with each other.
At the appropriate times, all team members are encouraged to request feedback from other team members, and to provide feedback to others.
In addition, to make sure that everybody gives and receives feedback, every four months there’s a requirement for all team members to give feedback to the people they work directly with.
The goal of each feedback round is to identify skills that could be improved. It is meant to be a positive and useful opportunity, where two team members openly talk about their perceptions of each other's work, and to identify ways to improve. Feedback rounds are composed of:
Before each feedback meeting, every participant puts together a list by team member evaluating the issues highlighted when assessing each other’s work.
Each team member also fills in a self-assessment sheet. The goal is to help generate a fluid and productive feedback experience. This method has proven to be an effective tool in improving our overall performance at work, in finding better ways to confront problems and, above all, in promoting and encouraging actions which contribute to make our company a unique and evolving place to work.
We use Ruby as the server-side programming language for most of our web products.
Ruby helps us focus on simplicity and productivity, while the code remains elegant and easy to read.
We use Ruby on Rails in mid to large enterprise applications, and in applications that require us to get the product to market immediately.
For lightweight applications on the server side, like single page apps, minimum viable products or small-sized web apps, we would use Sinatra.
When it comes to creating mobile apps for iPhone, iPad or Android, we prefer native over mobile-web solutions. There are a lot of reasons for this and we are always open to receiving client opinions but, at the end of the day, it’s a matter of user experience: users are more familiar with the native flow than the hybrid one. In hybrid, it’s more difficult to reproduce the native feel.
For iPhone and iPad we use Objective-C or Swift, and for Android we use Java, combined with different frameworks, to craft the mobile solution our clients need.
We strive to combine the best skills and technologies to come up with the perfect solutions for our customers. Finding the right amount of each technology is the key to success.
Having a strong Java EE background, that has evolved right from when we founded the company, our experts are used to designing, developing and maintaining Java-based middleware solutions for corporate and global environments.
Naturally, we also use Java for creating stunning Android apps.
Built on top of the Java Virtual Machine (JVM), JRuby allows us to write Ruby code that natively interacts with Java objects and classes.
This feature can be very beneficial for projects that require high portability and interoperability with Java.
Also, in certain cases, performance is actually improved when using JVM rather than MRI.
As mentioned before, we also work to create mobile products using iOS and Android SDKs, as well as our own reusable components.
How can dev teams make sure that the features and fixes added in the current iteration don’t break the work we've already completed? There are two ways to expand functionality without sacrificing quality: (1) having a QA dept, that is big enough to tackle different projects at a time and quickly respond to the development pace, and (2) test automation.
We prioritize the second option. Automated testing helps us save time, keeping project goals within budget. We use a variety of libraries and tools to write automated tests, including:
Each team decides what the best testing strategy is for the particular project under development. In general, we follow a BDD approach. For small projects, requiring a minimum viable prototype to quickly validate a market, we wait a short while before writing tests.
Whatever the chosen strategy, we make sure that we have healthy test coverage, as early as possible.
We are working hard to invest more and more time towards OSS.
Check out our GitHub page to see our latest contributions.
A great deal of inspiration for this document comes from thoughtbot's playbook.
This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License.