01

Our Work Culture

Why Remote?

We’ve been a remote-first company since day one, and it’s helped us attract and retain some of the most talented designers, developers, data scientists and project managers from across the country. We only hire highly motivated individuals with excellent communication skills. Because we designed our company as a remote workplace, we’re able to give clients a seamless working experience, even though we’re not onsite.
 

How We Communicate

Every client engagement is a highly collaborative partnership. We work fast, and it’s crucial to have consistent check-ins with our clients to make sure we’re always working on the most important things. We use video conferencing to have face-to-face interactions with each other and with our clients. Because we have a tightly defined communication cadence with our clients, our customers feel just as involved in the development process as they would if we were on-site.

working-remotely-3

Our Remote Code of Conduct

To ensure that our work style is at least as effective as working together in person, we have a code of conduct that all Very team members adhere to. The Code of Conduct includes:

A Professional Workspace

Each team member is responsible for having a distraction-free workspace, whether they choose a coworking space or have a home office.

Minimum Bandwidth Requirements

To make the video conferencing experience as seamless as possible, all team members must have access to at least a consistent 5Mbps connection.

Audio Requirements

Team members must either use a headset with an inline or attached microphone or a podcast-quality desktop mic.

Core Working Hours

Our core working hours are from 9 a.m. - 5 p.m. EST. We work with clients for 32 high-quality hours/week, reserving the remaining 8 hours for professional development and internal projects. 

very-client-thrive
"Very was truly our partner in launching Thrive Global's digital media presence. In a short time-frame, they designed and problem-solved alongside our team seamlessly. They are flexible, creative, and focused on quality."
- Arianna Huffington, founder and CEO of Thrive Global

 

Collaboration Tools

Your Very team will be available to you for active collaboration during regular business hours. We’ve tested many different collaboration tools, and we only use the best of the best. Here are the five must-have tools we use to collaborate with each other and with our clients. 

  • Communication: We exclusively use Slack to communicate. It's much more efficient than email, has native mobile clients and allows us to integrate with third-party tools, like Pivotal and Google Drive.
  • Video Conferencing: We use Zoom to do voice/video calls. It supports large teams concurrently, provides a quick and easy way for us to communicate with clients face to face, and is by far most reliable video call service.
  • Project Management: Pivotal Tracker serves as the backbone for our development workflow. We represent all work needing to be done as a Pivotal Tracker Story. Stories can have task lists, attachments, and conversation threads. They are grouped and organized to fit the evolution of your product. 
  • Document Management: Google Drive is our primary repository for all project-related documentation, from contracts and proposals to design files. You've been shared on the root project folder and can collaborate in real-time on any documents in your folder.
  • Code Repository: We will store one of your most important assets — your application’s code — on Github. Its version control tooling allows multiple developers to work on your application at the same time without overriding each other’s work.

 

When We’ll Travel

For a typical client kick-off, we have team members fly out for an in-person release planning meeting. We put together a tight agenda in advance and typically work a couple of full days together. Our product managers are also available to come onsite for additional release planning meetings on an as-needed basis.

02

Kicking Off Your Project

We begin by learning everything there is to know about your business, your customers, and the problems this project will solve. We also identify unvalidated assumptions and knowledge gaps, so we can start managing uncertainty. From there, we make plans to fill the riskiest knowledge gaps and validate, or invalidate, the riskiest assumptions. We also review all existing research and conduct an analysis of competitive products.

What is Release Planning?

During a project kickoff, we go through a rigorous Release Planning process that takes place over the course of several days. Throughout Release Planning, we work to define the business needs, the end users, and the solution we're bringing those users. We identify the situations in which they will use the product and its features, and we determine their motivations. Together, we decide what success looks like — for the whole project and for customers.

The goal of Release Planning is to:

  • Develop a phased product roadmap that provides the most value to users, as quickly as possible
  • Understand and document the full scope of requirements for launching your product
  • Mitigate project risk through technical research spikes to understand cost, complexity, and time required to build and launch the features of the application
  • Determine the correct technology stack to support the functionality, design, platform performance requirements, and constraints

release-planning-session3

Needs | Wants | Desires

The next working session is about getting to a finer level of granularity and talking about specific features. This is where the rubber meets the road and we begin to ground the concept. Together we'll work on an exhaustive list of user-facing features, necessary administrative functionality and general platform foundation. For this activity, our goal is to determine which features are critical to the business and customers and helps us start thinking how to define the Minimal Viable Product.

The session starts with everyone creating cards, in person or virtually, and placing them where they feel the cards fall in priority. The three choices are:

  • Needs: Must have, top priority
  • Wants: Nice to have
  • Desires: Would love to have someday

Once everyone has completed the first task, we process every card as a group. This is where it's critical that all stakeholders are collaborating. We want to meld the viewpoints of engineers, designers, domain experts, and product owners. We'll reorganize everything, write new cards as needed, throw cards away and ultimately end with a high-level roadmap for the project. We'll record all these cards on the Pivotal Tracker board, which you'll learn about later.
 

Risk Mitigation

Each project has its own unique concerns and constraints. We do our best through this process to identify potential bottlenecks and roadblocks as early as possible. Oftentimes, this comes in the form of evaluating some external service or piece of software, but as your product complexity increases, we will need to do Research Spikes on the riskiest pieces, which may include:

  • Does your project require machine learning? Are the tools you aim to use readily available as a service, or will we be needing to build models from scratch?
  • Does your project involve a cryptocurrency or leverage a blockchain based technology of some kind? If so, are we aware of the legal and technical limitations of the current frameworks on the market?
  • Does your project involve custom hardware development? Do you have manufacturing cost limitations? Have you identified a manufacturing partner? Are there strict security considerations?

We take whatever time is necessary to dig into the the specifics here and put together some initial suggested paths forward.
 

Writing Job Stories

Job stories are the fundamental units of functionality we build and deliver. We think of them as vertical feature slices that stand on their own and add value to the end user. Job stories define a given situation, a user's motivation for acting within that situation, and the expected outcome of the action.

59610d9c27470170e959b67b_Jobs to be done

Using the "Jobs To Be Done" framework, we walk through the Job Stories, key activities and flows that users will take through the application. Then, we assemble them into a working list and prioritize them. This is a crucial step in defining the user experience and user interface, and it heavily informs the overall design of the application.

Estimation

After we draft stories needed to accomplish user goals and business objectives, we estimate each job story with points. Points indicate the complexity of various job stories, as well as supporting detail. We break down more complex stories into smaller ones, reducing exposure to risk.

This provides us a clearer understanding of how much effort is required to build the pieces of the application. We also account for system concerns such as performance, compliance, scalability, fault tolerance, and maintainability. During development we will learn much more about how to build solutions to meet to user's goals, so we will continue refining stories and our release plan.
 

Product Development Roadmap

At this point, we look holistically at development needs. We build out a product development roadmap, organized into releases and weekly iterations so that the coming releases are clearly defined. We construct a release plan by sequencing work based on technical dependencies, risk, resource utilization, and just-in-time planning.

595679f83f0b1132bc0ec0f2_diagram-kanban

We've turned over most stones, and in some cases, performed research spikes to reduce uncertainty and verify assumptions. At this point, we should have a decent idea of what it will take to bring your vision to life. We will provide you with what we believe is your best path forward, along with some timing and cost estimates.

Using Pivotal Tracker

Pivotal Tracker is a task management service and the backbone of our workflow. All work that needs to be performed is represented on a Pivotal Tracker Story. Stories can have task lists, attachments, and conversation threads. They are grouped and organized to fit the evolution of your individual product.

At the end of our Release Planning meeting, we look holistically at development needs. We build out a product development roadmap, organized into releases and weekly iterations so that the coming months are clearly defined.

03

Team Composition

Your team will work an average of 32 focused hours per week, and they will be dedicated solely to your project for the entirety of our engagement. By working with the same team day after day, week after week, we’re able to reduce waste and increase efficiency to keep your project moving forward at a fast and predictable pace.

product-managers

Your Product Manager

One of our senior team members will serve as your product manager and primary account manager. During your Release Planning phase, we'll determine if they need to serve in a dedicated capacity, working only on your project, or if they can be effective managing your project in addition to other client projects. Their role is about driving the project forward. By providing unbiased product development insights, they will serve as your advocate throughout the development process.

Depending on your project needs, your team will be a tight-knit group of:

Designers

User experience (UX) designers are a critical part of modern application development. But too often, UX designers create a mockup, hand it off to developers and move on to the next project. At Very, our UX designers are also front-end engineers, bridging the divide between design and development. 

Full-Stack Engineers

Our full-stack engineers work in teams of two using a process called pair programming. This approach leads to better quality, fewer defects and greater levels of overall efficiency over the lifecycle of the project. It also gives every project an added level of redundancy.

Data Scientists

With the increased popularity of artificial intelligence, big data, and machine learning, we've found that many clients need dedicated data science engineers to be responsible for data strategy. This role can be responsible for crafting data acquisition strategies, defining internal workflows and applying state-of-the-art technologies and techniques to your project.
 

In-House and Onshore

We get a lot of questions about the way we work. The most common one is, "Do you outsource work overseas?" The answer is an emphatic, "no." We are a 100% US-based company with full-time W2 employees based in 16 states. We believe in the team and culture we've built, and having full-time resources is crucial.

People also wonder if we outsource work to contractors and other agencies. We only do this in special circumstances where other teams have skills that would better meet your needs. If this were to happen, we’d work with you in advance to weigh the pros and cons of working with an additional agency. If you decide that's the best path forward, you'll contract with that person or firm directly.

04

Our Meeting Cadence

Instead of planning every detail of a product at the beginning of the project, we allow for changing requirements over time. This approach relies on deliberate, consistent feedback from our clients. To ensure we're always on the same page, we have a set meeting cadence that we follow rigorously for each project. 

Standups

Daily: 5 minutes, optional

Each team member says what they worked on the previous day, what they plan to work on that day and if they have any blockers. This meeting is highly structured and intentionally kept short. Any blockers or issues raised during the standup will be triaged by your product manager after the meeting. You are welcome to join daily standups, but they are not mandatory.

Iteration Planning Meeting

Weekly: 40 minutes, required

During an Iteration Planning Meeting (IPM), your team will determine how much of the backlog they can commit to delivering during the upcoming iteration. In order for your project to go smoothly and meet your expectations, we need a designated product owner from your team to attend every IPM. You can expect planning meetings to occur each Monday and last less than an hour.

smart-tank_quote-1
"At the beginning of our engagement, I thought, 'Meeting every day is going to be tough. And how much benefit am I going to get from being involved?' But after the first week, the benefits were obvious."
- Dennis Milford, General Manager, KollerProducts

Iteration Demo

Weekly: 30 minutes, required

After the iteration ends, the team will present working software and work-in-progress in order to demonstrate value delivered and obtain product feedback. We then assess how this iteration advances us towards our current release.

Iteration Retrospective

Weekly: 30 minutes, optional

Before planning the next iteration, we reflect on how we worked together and how we can improve our effectiveness as a team. We proactively identify and solve problems to improve performance.

05

Agile Product Development

Our highest priority is to deliver valuable, working software in a predictable way. We believe customers should be able to change their requirements, even late in development, because their business environment is constantly changing.

 Why Agile?

The best products are built when business stakeholders and product teams work in a highly collaborative way. For all of these reasons (and many more), we strictly adhere to an Agile software development approach.

Agile software development is an approach that’s based on making incremental improvements to a product with frequent cross-functional check-in points. Instead of planning every detail of a product at the beginning of the project, the Agile methodology allows for changing requirements over time and relies on constant feedback from stakeholders and end users.

MVP

With Agile development, cross-functional teams work on an iteration — a single development cycle — of a product over a period of time. Work to be done is organized into a backlog, which is prioritized based on business or customer value. The goal of each iteration is to produce a working product.

When using an Agile approach, business stakeholders and the product team must work together to align the product with customer needs and company goals. 

Lean Development

The concept of lean software development emphasizes optimizing efficiency and minimizing waste in the development of software. The approach has its roots in the lean manufacturing movement, but is now considered an key part of the Agile software development methodology. Lean principles aim to streamline every part of the software development lifecycle, centering on the idea that less is more.

Extreme Programming

Extreme Programming (XP) is a disciplined approach to delivering high-quality software, quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing and planning, and close teamwork. Software is delivered at very frequent intervals — typically every one to three weeks. Ultimately, XP creates flexibility for changing business and product needs. It provides insights into the cost and time to build out features and deploy them.

59567a44ed965e4d0f429ece_Extreme Programming

Pair Programming

We practice pair programming (sometimes simply called “pairing”), an agile software development technique where two programmers work together at a single workstation. One, the driver, writes code while the other, the observer, reviews each line of code as it is typed in. The two programmers switch roles frequently. While it may seem like an ineffective use of resources, pair programming can increase project velocity because coding mistakes are caught and fixed immediately.

Building a Connected Fish Tank for the Smart Home

Koller Products teamed up with Very to design and build Smart Tank, the first internet-connected desktop aquarium on the consumer market, and a cross-platform mobile application.

View Case Study

Let's Work Together

We bring skill, speed, and precision to every project, so you can test harder, build faster, and go confidently into the market.