Thanks to our decades of enterprise-level software engineering experience and deep product development expertise, we have evolved a development process that enables us to successfully deliver high-quality code at a breakneck pace that we call the Quality Software, Faster process (QSF).
Here’s how we do it:
Kickoff Meeting
Every software development project should begin with a kickoff meeting for all stakeholders to get everyone on the same page. The goal is to dive into your vision and goals and begin to outline the project specs.
Design and Discovery
We begin software projects with our 4-6 week design and discovery process which kicks off with a 1–2-day discovery workshop. In the workshop, we'll work with you to identify the most salient information before designing a wireframe prototype that outlines your product's content areas and pages.
After the workshop, design a wireframe prototype that outlines the content areas and pages of your application, and which allows iteration and exploration without the distraction of a high-fidelity visual design or costly development.
Based on the wireframes, next develop a visual design for your app, which will be used as a guide as the final features and pages of your application are developed. We also suggest creating a detailed list of user stories, or descriptions of software features that describe the user and identify how any code changes might impact them.
We've built several review checkpoints into the process, which allow you to provide feedback and make any necessary UX and UI adjustments.
Learn more about The Gnar’s Design and Discovery services.
Next, development begins.
Software Development with The Gnar
We typically work in weekly sprints, so we can learn quickly and adapt priorities as the project progresses. We borrow the term "sprint" from the Agile Product Development framework and define it as chunks of planned time – typically 1-2 weeks – to complete development work. One important benefit of working with Gnar is that the engineers on your team work solely for your team, so they can immerse themselves fully in each sprint of your project.
First, we'll work with you to populate the project board with user stories and features, set up any required accounts and continuous integration, and schedule Sprint Planning and Backlog Grooming meetings in advance. Then, our software development process occurs in seven steps.
1. Sprint Planning
We begin with Sprint Planning meetings, in which we’ll move the highest-priority features from the backlog to the current sprint.
Before we move the highest-priority features into the sprint's backlog, we assign a level of complexity – which we refer to as a "Story Point" – to each ticket. This allows us to track work and understand the team's capacity over time, measured in Story Points, for each Sprint. It also allows us to communicate the complexity of each ticket in the Sprint to other stakeholders and members of the product team.
2. Test-Driven Development
Now that we have a sprint plan, the engineering team can move forward with its agile, test-driven development work. In test-driven development, each new feature includes writing a test (in code) to assert the behavior of the feature. Including a test, and not just focusing on implementation, ensures that the developer stays committed to the requirements of the feature.
The tests also help future proof the feature: tests written for the feature now, help easily catch any future development that break it. This not only reduces the development time to market but it also reduces software bugs by 40 - 90%!
3. Peer Code Review
An integral part of our development process is the Pull Request (PR), which allows our engineers to alert others to changes they've made to the codebase. Upon receiving a Pull Request, Gnar engineers review the proposed changes, and discuss them with the team before the codebase is updated. We've found that frequent PR reviews keep the internal and external teams aligned and engaged and enable managers to proactively identify potential issues.
4. Run Automated Tests via Continuous Deployment
Once a feature is successfully developed and PR reviews are conducted, code is verified by an automated build that runs automated tests via Continuous Deployment to identify any issues before deployment.
5. QA Test on Staging Site
Once those tests pass, the code is deployed to a staging site. This allows you to complete a QA Test on Staging, where you will have the opportunity to review and approve the feature before it goes live.
6. Deploy to Production
Once our team gets the go-ahead from the Approvers, we deploy code to production using a Continuous Deployment methodology, a strategy that helps engineers focus their efforts on shipping features and getting your high-quality software live as quickly as possible.
7. Sprint Grooming Meeting
Toward the end of the sprint, we have a Sprint Grooming meeting, in which we’ll review the top features in the Ideas or Icebox column and move any appropriately defined ideas to the backlog column. We review the highest-priority tickets for the upcoming sprint to ensure the development team understands and adequately schedules the requirements during Sprint Planning. We’ll also confirm the priorities of the remaining features in the backlog.
Project Launch
Once the product is launched the job doesn’t end. When a product is in use, you will continually identify areas where it could be improved, add them into future sprints and iterate the product as new features are released.