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.
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.