We started in 2006 with the idea of creating top quality software products. Today that same idea drives our actions. Over the last 12 years our company accumulated successful experiences working for large companies and innovative startups. Our solid track record in creating long term relationships with our clients and employees are backed up by our values, strong work ethics, and the way we work.
Let's talk about the Moove It way.
Our company is composed of several multidisciplinary teams: Product Managers, UX and UI Designers, Developers, Solution Architects, and DevOps engineers.
With 12 years of experience in the software industry, Moove It has refined its processes and tools to have the power to work in a variety of roles and environments. Some of our clients prefer us to own the technical decisions of their products, some of them prefer to be in control themselves and we simply provide ideas and feedback.
In some cases our clients need us to provide a variety of additional services such as project management, testing, infrastructure and product consulting. Others need straight forward staff augmentation, in which case our developers and designers proactively suggest improvements and integrate themselves to become part of the team.
Whether you're looking for staff augmentation or a complete technology partner, we have the experience to work with you at the level you need. Regardless of the specific needs, what sets Moove It apart is that we always see ourselves as your technology partner. And this permeates all that we do, starting with the proactivity of our developers, whether it is improving the technology or the process. We constantly strive to improve ourselves, our service to our clients, and our client's products.
Moove It is a software consulting firm that designs, develops and deploys custom solutions for organizations that want to make an impact through technology.
That’s the key to our philosophy. We strive to deliver the best service and highest quality products by constantly reviewing and improving every aspect of our process.
We build strong relationships based on mutual trust with our clients and encourage close bonds among our team members.
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 contribute with new ideas.
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.
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. We flourish because we love what we do!
From our employee culture to our clients and projects, we empower social responsibility and global change.
We use a set of tools and procedures that can be adapted to each company. We know each company has different needs that have to be worked in different ways.
Our strong work ethics, values and principles are focused on creating strong long-term partner relationships with clients and employees.
We become deeply involved in our projects. We are enthusiastic technologists who love bringing real solutions to each client’s problems through a deep understanding of their market, solution and vision.
Moove It products are developed with intention to retain their high quality as our clients scale their growth. Using the latest technologies and following our methodology and good practices, we deliver evolving quality.
When working with Moove It, you will typically start with some variant of our initial services: Product Discovery, Product Development or Staff Augmentation. Our services are not locked into these of course, but they cover almost all of them.
The Product Discovery is geared towards engagements where the requirements are not fully fleshed out. We design, validate and test your concept before developing a real product. This process reduces risk and improves efficiency. Best of all, it allows us to get the product details right.
This is the natural follow up to a Product Discovery. In this type of engagement we agree to a scope of work to deliver and using Agile development processes, our development team brings your product to life. It is often followed by ongoing maintenance where we keep your product running.
Some of our clients simply need staff augmentation. In this scenario our developers plug into your team and adapt in a way that you'll not think of them as being a separate team. Our developers bring their skill, proactivity and our strong process experience to help continuously improve the team as a whole.
All our staff augmentation clients think of us as just another part of the team. There's no "us" and "them".
To implement an idea, you need to be certain it is not based on the wrong assumptions about the target market, and that it’s properly communicated to the development team.
We help you challenge the idea against reality, and mitigate the risk of miscommunication. This process achieves two main goals: help everyone to be on the same page about the product and deliver valuable assets, which are needed in the development phase. Every project needs some if not all phases of Product Discovery. 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.
Who are your target customers? What problem is the product idea trying to solve? What’s the biggest technical risk?
These are just some of the areas we focus on to make sure we're building the right product.
We use personas to discover a set of user profiles describing a particular customer segment. Each profile is a fictitious representation of a typical user from the target audience. We give them a name, story and personality. Personas are based on real data from the target audience. This adds a human touch to the research, and helps drive the user experience design.
To create a persona we:
A key element to every persona is their use case. We want to understand how the product will address their needs and help achieve their goals. During this whole process, a persona should not stay static, but needs to evolve as our understanding of the target audience evolves. This can be caused by client feedback or real user interviews.
Tied in with personas, we identify what the main high-level user stories are. Different types of users will want to use the product in different ways and for different purposes. It's important at this stage to understand these interactions, as they are key to validating features and help shape the initial user experience.
A Wireframe is a visual guide that represents the skeletal framework of a software product. It focuses on highlighting functionality and information architecture, closing the gap between what has to be done and where it should be placed. In other words, it focuses on what a screen does, not what it looks like.
Expect black and white wireframes. The goal is to validate the internal flow, components, information hierarchy and product intuitiveness. 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.
We use wireframes to quickly draw up ideas for the user experience. "A picture is worth a thousands words" captures exactly what wireframes are all about. There is nothing that sparks creativity, quickly discards some ideas in favor of others or create "aha" moments than when our clients see a quick draw of what we intend to do. It is a crucial step that makes sure we're all on the same page about what we want to build.
The last stage of the Inception is to create these high fidelity mockups. Our team applies emotion, color and aesthetics to the wireframes to create high fidelity mockups. These mockups are then linked together to simulate the product flow. Even though it doesn't provide the real experience of a web page, it is highly effective in providing an actual look and feel for the final user experience.
Our designers use Mockups to validate the user interface (both visuals and interaction) against representative users which is a crucial part of any project. High-fidelity mockups help communicate the aesthetics and behavior of the product being built, and allows stakeholders to interact with the product user interface so they can gain insight into 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.
A key aspect of this process is to get feedback from potential users. Understanding their reaction to the interface and the user experience will confirm or discard out hypothesis. Jumping right into development could be expensive in the long run if we don't validate our design and user experience assumptions.
Software prototyping is the activity of creating Prototypes (early samples, models, or releases of a product built to test a concept or process or to act as a thing to be replicated or learned from) of software applications. These are incomplete versions of the software program being developed, however, they are incredibly useful to get user feedback and understand if we're on the right track or not.
The last stage of the Product Discovery directly ties into the development phase with the Product Backlog. Using all the information gathered during this phase, along with the high fidelity mockups, we compile the list of user stories that make up the Product Backlog.
The Product Backlog is a prioritized list of user stories that describe the requirements of the Product that needs to be developed. The backlog is used to create an estimate and a development plan which later on guides the developers during the development phase.
We consistently create best‑in‑class software products that deliver measurable results for our clients. Our secret is the process. Anchoring all the elements of the Moove It methodology are two main strengths:
We recognize that all project and business needs are different, we tailor our methodology to each of them. Here we explain how.
Our starting point is always the client. After all the product is about you. So we undertake research and discovery to understand your goals – why do you need this software product? Who will use it? How will it add value to your brand? Through our discussion with you, we get to know your end‑user, the competition and the immediate and long‑term software solution to address your pain points.
Because change is an inherent part of software development, flexibility is important. The Agile methodology gives our team the flexibility to anticipate and respond to the unpredictability that comes with building software.
Our Agile principles can be summarized in simple terms:
Scrum is one of the Agile frameworks that Moove It uses to manage software development work. Our teams of developers break their work into actions that can be completed within timeboxed iterations, called Sprints, and track progress in daily 15-minute stand-up meetings, going over what they did yesterday, what they will be doing today and if anything is blocking them from going forward. One key to Scrum's popularity and success is that it has a simple set of roles, responsibilities, and meetings that never change.
In Planning we discover things that belong to the project. An important task in creating a software program is extracting the requirements from customers who typically have an abstract idea of what they want as an end result but do not know what software should do. Our skilled and experienced software engineers recognize ambiguous requirements at this point. Once we have gathered all the general requirements from our client, we analyze the scope of the development and make sure it is clearly stated. This is often called a scope document.
Each project starts with a prioritized list of work requirements known as the Product Backlog, which:
The product manager prioritizes Product Backlog Items (PBIs) based on considerations such as risk, business value, dependencies, size, and date needed. The Backlog is visible to everyone on the team but may only be changed with the consent of the product manager, who is ultimately responsible for ordering Product Backlog items. The size (or estimated effort) of each item is determined by the development team.
Here is an example of what the Product Backlog might look like:
|User||As a user I should be able to login|
|User||As a user I should be able to reset my password|
|User||As a user I should be able to edit items|
|User||As a user I should be able to export data|
|Admin||As an administrator I should be able to define KPIs for my sales team|
|User||As a user I should be able to view my data on mobile|
|Admin||As an administrator I should be able to send alerts when new leads come in|
|User||As a user I should be able to create a report of my data|
|Admin||As an administrator I should be able to configure views of data|
A User Story helps us to create a simplified description of requirements set out in the Product Backlog. The User Story is an informal description of the features of a software system, written from an end user perspective. It describes the type of user, what they want and how they will use the product to be developed. It also define features, bug fixes, non-functional requirements and whatever must be done to successfully deliver a Minimum Viable Product (MVP). The project manager usually writes the User Story and records it in JIRA, the preferred project management software at Moove It.
We log User Stories in the Product Backlog and size them in story points using the rounded Fibonacci scale. This is called Planning Poker, a consensus-based technique for estimating relative size of a User Story. In planning poker, our team members make estimates by laying numbered cards face-down on the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, our team refrains from biased assessment.
The Fibonacci scale consists of numbers that are the summation of the two preceding numbers [0, 1, 1, 2, 3, 5, 8, 13, 21…] We have learned that using this scale reduces complexity, effort, and doubt when determining development time required for a task. This way also our project manager finds it easier to influence ordering of Product Backlog items. For example, if two features have the same business value, our project manager may schedule earlier delivery of the one with the lower development effort, because the return on investment is higher.
At Moove It, we have a standard way of writing User Stories and we avoid confusing and ambiguous terms. We always use the active voice so that each User Story is simple, concise and easy to understand. We follow this format:
“As a [who] I want [what] in order to/for [why]”
It is important to understand who the user is, their objectives, as well as the problem to be solved by the product. The user is always mentioned first.
A concrete action or objective the user wants to accomplish, stated in simple terms without getting bogged down in details, which can be counter-productive.
Understanding user benefits and motives is necessary in order to propose the best solution.
For example, our User Story may state:
"As a sales manager I want a report with the top weekly sales to forward to my superior".
Knowing that the goal is to send the report to the superior, it is valuable to create a functionality that automatically sends the report to the superior without the user having to do so. If this story had no "what for", the automatic sending would not be considered.
Where the User Story is a complex one, we use the JIRA description field (to allow more comments), and the Acceptance Criteria, as described below.
Acceptance Criteria are the conditions that must be met before a User Story can be considered ready. The project manager and our client agree on this information through active conversation, before it is added to the User Stories.
The Acceptance Criteria should be SMART: Specific, Measurable, Actionable, Realistic, Time-Based.
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.
We divide user Stories into Epics, which are chunks of work with a common objective. This allows us to plot the functionality of a product without committing to the details. An Epic can be a feature, customer request or business requirement. In the Backlog, an Epic is a placeholder for a required feature with a short description of the final output of user needs.
We break an Epic into smaller and more detailed User Stories until they are clear, feasible and verifiable. An Epic usually takes more than one Sprint to complete. In agreement with the project manager and based on the team's historical development velocity, the team will commit to complete a certain number of stories during the next Sprint iteration.
Retrospective meetings, or retros, are a fundamental part of our process, it is the key that allows us to adapt. During retros, the team openly discusses practices that are working well and those needing 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. We review the action plan from the previous retro meeting. We brainstorm and discuss using the start-stop-continue approach, creating an action plan and assigning responsibilities for each action item.
This acts both as an early warning system of problems that are starting to happen as well as a source of infinite ideas for improvement. Though not the primary focus, often times a by-product of these meetings are new feature ideas for the client's product.
While User Stories are useful for capturing the functionalities of a product, they are not good for describing the visual design or the user's journey. We use support tools and techniques such as History Maps, Flow Diagrams, Sketches, Scale Models or Graphical Scripts to ensure a good user experience (UX).
We believe it’s best to design the user interface before source code is written, to avoid having to make expensive changes. We use wireframes, Mock-ups and Prototypes to visualize the product before it is actually developed. Although those terms are often used interchangeably, they are quite different. While a software mockup looks like the real thing, it does no useful work beyond what the user sees. A software Prototype, on the other hand, will look and work just like the real thing.
We systematically pair-review our code for readability, uncovering bugs, to transfer knowledge, and to share good coding practices among team members. We deliver production-ready code. Using a combination of tools that help us facilitate both code reviews and continuous integration tasks, our developers work collaboratively to review each other's code.
We normally use Github's integrated code review feature to streamline this process. We also integrate automated tests that are triggered automatically once new code is submitted for review.
A new change is considered ready once it has been approved by a developer and passes the automated testing as well.
This process ensures that:
In general, we use Jenkins or CircleCI as our Continuous Integration tool. They continuously build and test the code submitted to a project’s repository. If the code breaks the tests, it cannot be merged with the master branch. This helps us prevent failing code to ever make it to production.
To make sure the features and fixes don’t break the current work, we use test automation and a Quality Assurance team that can tackle different projects at a time and quickly respond to the development pace.
Automated testing saves 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, making sure that we have healthy test coverage throughout the project.
To learn more about our preferred languages and frameworks please visit moove-it.com/technology
We like to work in our offices. We feel that we are a community of people sharing the same values. Moove It employees make up a team of passionate, tech-savvy professionals. Always hungry for new challenges and ideas, the team thrives on a collaborative and positive workplace culture that puts a premium on personal development, open communication and mutual respect.
We strive for effective communication, complementing 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 of tools includes:
For all projects, we encourage at least one weekly call with the client. If a project requires, we send daily or weekly summaries to our clients to keep them up to date with the progress. In some cases, part of the team might also travel to a client’s offices to work side by side.
We are one team, and each of us is assigned and participates in multiple smaller teams. There are several ways to look at how our team internally works so let's dive into it.
A Pod is essentially a team assigned to a specific client or project. A pod is typically composed of Developers, a Team Leader, a Technical Architect and a Principal. Developers and Team Leaders are typically involved in one or maximum two projects. Typically Architects and Principals are shared across multiple projects.
The role of Developers and Team Leaders is clear, they are in charge of the every day development. Team Leaders are often developers themselves. Depending on the context of each project, a team leaders tasks can range from minimal tasks like keeping work on track and coordination to more involved project management like prioritizing the backlog, creating a roadmap and hosting planning meetings. Team Leaders also coordinate external requests to the Design or DevOps teams for example.
Technical Architects involvement varies over the life of the project. They are very involved in the beginning, helping with the initial setup and with decision about the architecture, frameworks and technologies. Over the lifetime of the project, they will do a general assessment of the project and be involved whenever a major decision comes up for a feature that requires an architectural change.
Across pods, and involving all sorts of roles, we have guilds. They are formed around a specific technology and are a way for developers to share and increase their knowledge. Members of a guild will collaborate on initiatives and bring forward goals that they want to achieve in a certain technology. For example, the React guild created a new component that speeds up development across projects. The Mobile guild has come up with templates of how new mobile projects are started and how they are managed, bringing good practices and a standard way of doing things across the company.
Guilds are fluid, they come and go as technology interest does.
The design team has its own members and a team leader as well. This is important for us because all projects need design, but not enough to warrant a dedicated person to that project. Hence, our design team works on all projects that have that need, whenever that need comes up. Usually the team leader from a project coordinates requests with the design team leader. The design team is a big part of the product discovery as well. Bringing their knowledge and expertise together to create new, intuitive and beautiful product propositions.
The DevOps team operates in a similar fashion to the design team. It takes care of setting up the infrastructure for our projects. They are in charge of creating test and production environments including everything our clients need. They take care of everything from configuring domain services and security certificates to installing servers, web services and setting up alerts and monitoring to make sure the application stays up and running.
We believe in the benefits of education. In a constantly-changing world, we foster an environment in which learning is a way of life. We encourage, enable and provide our team with 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 combines 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.
More information about our Open source activities please refer to www.moove-it.com/technology
Since you were curious enough to read until the end, let's continue the conversation!
If you are exploring your software careers, please check out our careers page.
If you are looking for a technology partner, contact us!