Product Development Process at Nivoda

A question we get often is - what is the (product) development process at Nivoda? What methodology do we follow, how long do sprints take and how are new updates being released?

In this post we'll explain our current process. We'll start by splitting up the Product and Development cycles - even though they are super linked, it's important to make the distinction.

Product Cycle

Let's start with what we broadly define as the deliverable of the Product Cycle: to have stories & collateral (design, wireframes, prototypes, acceptance criteria) ready for development to start working on them. 

The first step in the whole cycle is to prioritize the "features" for product to work on. The product team takes continuous input from multiple areas in the business: feedback from customers (either direct or from support or sales), our own ideas about the future, the feedback and requirements from different departments in the company and finally the backlog of any bugs & tech improvements that have been identified.

Together with the department heads, the top 4 large items are selected. The product & development team commit to having those done in the next quarter. Depending on when those are finished, the same exercise is repeated to get number 5, 6 and so on.  This is done together with the department heads so that the different tradeoffs can be discussed and understood by everyone at the same time - we've found that this is helpful in getting understanding and agreement on the prioritization.  

A concrete example of what those items have been for Nivoda:

• adding melee to the platform (adding a completely new product category)
• adding holds to the platform (an integrated feature for customers, suppliers and Nivoda support)
• launching an Excel plugin for suppliers (to sync Excel inventory to the platform)
• improve performance of the platform (a multi-sprint effort to improve almost all aspects of the codebase / architecture)

After the priorities are decided, the product team starts interacting with design and key stakeholders for that specific feature to map out the exact requirements, get the designs done and figure out the acceptance criteria.

To speed up the development and understanding of the feature, the developers who will be working on it are pulled in the ideation stages when they are concrete and touch on implementation. This ensures a shared understanding and we've seen that this results in better developed features and often great ideas from within the team as well. 

This cycle can take different amounts of time, depending on the feature - but we aim to have completed everything within 2-4 weeks for large features.

Development Cycle

The next cycle is the development cycle. At Nivoda, we currently use 2 week sprints, however, we plan to bring this down to 1 week sprints, as this would shorten the release cycle.

We use a dedicated sprint branch, which gets pushed to QA after the sprint completes.  For larger, multi sprint features, we use a dedicated branch which gets backmerged into the sprint branch at the end of each sprint. 

For the top 4 priority items, we usually have a kick-off meeting to clarify all questions and concerns prior to starting development. Because the devs were involved previously, this is usually a very smooth meeting.  After the meeting, the devs start working on the tickets. We check in on progress during our daily standups. 

For each feature which requires signoff from stakeholders, we have dedicated QA environments. The devs work closely with QA to make sure the feature is reviewable, and then work with the stakeholders directly to get the signoff. Once that's done and code review is complete, the feature gets merged in the sprint branch. 

Prior to releasing each sprint, QA does a full test cycle as well to make sure that everything still works together. Note that we do this in addition to automated frontend and backend tests (both unit and integration). 

Any bug-fixes or small feature improvements that customers would benefit from having as soon as possible (e.g. to add a feature specific for a customer to help with sales, or to add new information during the delivery updates that is important for customers), get merged in the main branch as soon as possible and are tested by QA on ad-hoc basis. In urgent cases, the dev can take responsibility for pushing a new update to production in case QA is not available.

Post Development Cycle

To keep the rest of the company updated on our progress, we do 2 things: 

• Share a pre-sprint document with the intended features to deliver in the #general channel in Slack for everyone to see. Stakeholders would be up to date in terms of their features but we've found it's important to share what is being done exactly with everyone in the company.
• Post release notes in the #product-updates Slack channel as and when they happen (ad-hoc or end of sprint) 

In case the feature is customer or supplier related, we also work on a small video or deck demo-ing the feature for future reference, or have a small meeting with the sales & support teams, and work on any support material needed.

Depending on the feature, product will also regularly checking on key metrics to measure its success, which in turn will influence the product cycle.

Want to help us?

If you think you would do well in the process we've described above, we would love for you to join us. We're hiring on all fronts - product, design and development. You can see all open positions and apply directly on our career site: careers.nivoda.net 

Continuous Improvement

As the company, team and the people within it keep growing, our processes will evolve as well. We have a bunch of anticipated changes coming and we constantly review our processes to make sure we are as efficient as possible whilst keeping sure we're building the right things, in the right way.