Our process - How we work
There's no one size fits all approach to building software, instead we practice a flexible, iterative process that allows us to adapt to the needs of each project.
Discovery
We'll work with you to understand the business, the users, and the goals of the project. We'll also work with you to understand the technical landscape, the resources available, and the constraints.
This entire process is iterative; we'll frequently return to "discovery" as we revise the roadmap and introduce new initiatives based on business goals.
Outputs
- Technical Specifications
- Roadmap
- Fat Marker Sketches
- Initial Wireframes
- User Stories / Tickets
- Confidence to begin building!
Build
With a roadmap in hand (typically in the form of user stories written into tickets) we'll begin the build phase.
Our team likes to work in 1-4 week sprints, depending on the project. A "sprint" follows a loose structure and is an effective way to help a team organize and collaborate on delivering value to the business as quickly as possible without sacrificing quality or sanity.
Software development is an organic process that is hard to plan accurately at scale. Sprints (ie: short focused bursts of development) enable teams to react to changing requirements from the business-side of an organization, while also addressing unknown complexities that are discovered as a project is built out.
A project or feature may require one or many sprints; typically a SaaS project will leverage sprint-based development indefinitely.
Sprint Process
- Stakeholders. These are the main decision-makers in regards to the strategic direction of the product or project. Our clients typically provide one or two key stakeholders to act as our primary points of contact, but it's also possible that every department head will act as a stakeholder representing their team.
- Grooming. We'll frequently review our list of features & tasks and ensure they are well-defined, account for any shifting requirements and priorities.
- Kickoff. At the beginning of each sprint period, the product development team and stakeholders will meet to review and agree on immediate priorities to be worked on next. It's important to consider this a negotation as we balance priorities to get the most valuable features released to market quickly.
- Build. During the sprint period the product development team will remain focused on the work they agreed to during the kickoff.
- Test. Our in-house QA team will test every feature as it is released into a staging environment.
- UAT. User Acceptance Tests will be performed for larger features that require a stakeholder or other internal customer to validate our approach to building out a feature or solution.
- Demo Day. We'll host a demo of all work completed during the sprint; this is an opportunity for stakeholders to vet features before they are released into the wild.
- Retrospective. Primarily an internal meet; we strive to improve our processes through regular introspection as a team.
- Deploy. Whether it is immediate (continuous deployment) or scheduled, we'll establish a release cadence with you, at which point we deploy all completed work.
Learn (then Iterate)
It's valuable to take a step back and evaluate our progress and whether what we are building is delivering the value to the business and its customers that we had initially hoped for.
There are several methods of learning and iterating, including:
- Retrospective. An opportunity for the product & development teams to review and improve upon their processes. What worked, what didn't work, and what can we improve in the next iteration?
- User Interviews. It's important to validate that the features we're releasing are meeting customer expectations and our own goals. User interviews and surveys are a helpful way to validate and inspire next steps.
- Ticket Grooming. Our product managers will regularly review our backlog of tasks (features / user stories) with the stakeholders in order to adapt to immediate requirement changes and keep the next few iterations prepared.
- Roadmap Refinement. Your roadmap contains the bigger picture plan; it's helpfult to revisit and refine the roadmap, adapting to what we've learned and changes to requirements accordingly.
- React to Changing Business Goals. Likewise, business goals can shift, reacting to market changes, or big learnings as we release new versions of the product and feature set.
Tell us about your project
Our offices
Remote first
We're a fully remote team with a presence in Brooklyn, Colorado, Canada, Brazil and the Czech Republic.
Reach out to us at: hello@twobit.solutions- Brooklyn
Suite 513
155 Water Street
Brooklyn, NY, USA