DIDI (Discover-Ideate-Develop-Iterate) is our name for our SCRUM Development process that we have effectively used to build high-quality Software for over 13 years now.

– Anup Marwadi, CEO – HyperTrends Global Inc.

We follow an Agile Model of Software Development to rapidly iterate and deliver the highest quality software. More specifically, we follow the SCRUM approach of building a Product that allows us to adapt to complex and changing needs of our customers while still delivering the highest quality product.

Our SCRUM process is termed DIDI (Discover-Ideate-Develop-Iterate) and we work very closely with product owners and stakeholders to prioritize product features to deliver working software in an iterative manner. We named our process DIDI to identify how simple, yet effective our development process is and how easily it can be applied to develop complex software projects.

We undergo the following Software Development process:

Discover

We, along with the stakeholders, undergo a Discovery process that will allow us to identify the core deliverables of the product we are about to build. It is through this discovery process that we are able to understand the product from the eyes of the market and build our deliverables accordingly.

This process often involves building consumer personas, defining core usage scenarios, product components, roadmaps, user journeys and related elements to fully understand and formalize the product.

Based on our findings, we build a master SCRUM Product Backlog that recaps the entir product to be built. This backlog is prioritized based on stakeholder needs.

Backlogs are usually stored in JIRA (https://www.atlassian.com/software/jira) or Trello (https://trello.com/) or even Asana (https://asana.com/) depending on the type of the product. Asana and Trello allow easy and fluid management of project backlogs using simple drag-and-drop features while JIRA offers a more traditional SCRUM alternative.

Ideate

In this phase, we start playing around with ideas, build wireframes and UI designs, write up user stories, perform proof-of-concept development to validate assumptions, identify deployment/go-to market strategies and present them to the stakeholders for approval. We may also produce a Product Roadmap with contingencies.

This phase allows us to dig deeper into the stakeholder needs and perform Proof-of-Concept theories to eliminate any unknowns that may significantly increase Software risk.

UI Designs may be created using tools like Adobe Photoshop, Illustrator or Sketch (https://www.sketchapp.com/) while wireframes may be created using Balsamiq tools (https://balsamiq.com/).

Develop

This is the core development phase where we undergo a Spring Planning session to build a Sprint backlog that contains the items that the development team will work on for the next sprint. Each sprint usually lasts 3-4 weeks and will allow us to develop a fully working product.

During the development process, the entire development team meets on a daily basis for about 15-minutes (usually termed as the Daily Huddle) and discusses their progress and reports blockers (if any) and identifies a possible plan for resolution. This allows everyone to communicate freely and collaboratively to make sure nothing slips through the cracks.

Each Sprint also has a Sprint Retrospective to inspect the sprint and its progress and also re-evaluate the Product backlog if needed. Stakeholders will be notified of the progress made during the sprint and will be presented with opportunities to review and revise the Product backlog and its priorities if needed. Work on a given sprint may allow stakeholders to reconsider their priorities and re-order items in terms of product value.

While the product may not be released to market, it will still be something that stakeholders can fully-test and review as per the specifications.

We may receive some valuable feedback from stakeholders and may add additional items to the Product Backlog for further refinement.

All of our development follows a GitFlow model of Source Control Management (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) and allows us to build feature branches for each sprint. Different teams working on different sprints may each have their own feature branch which will finally be merged into a release branch that will be released to a QA or a Production environment depending on the stakeholder needs.

Iterate

Once stakeholders approve the Sprint, the product can be incorporated in the master source code and released internally (or to the market) depending on the stakeholder needs.

For many customers, the true test of the product begins when the product is released to market. We collect huge amounts of data on user behaviors, other key performance metrics including user journeys across the application, error/usage metrics, page load times etc. to identify core areas of improvement.

Bug Tracking & Issues Resolution

Given that majority of our Software Development happens in an Agile manner, bugs and any issues identified are usually resolved in an agile manner as well.

Any reported bugs will be prioritized based on the following priorities:

• Blocker– These are reserved for catastrophic failures – exceptions, crashes, corrupt data, etc. that (a) prevent somebody from completing their task, and (b) have no possible workaround. While these are extremely rare, they should be treated as a priority and must be fixed immediately (same-day) and deployed as hot-fixes. A new hot-fix branch will be created and rolled to production.

• Critical– These may refer to unhandled errors or other “serious” bugs that only happen under certain specific conditions. A practical workaround is available. Not all customers may see this bug, and steps to reproduce may not be as easy. There is no hard limit for resolution time but such bugs should be fixed within the week (hot-fix) and must be fixed by next release. They key distinction between (1) and (2) is not the severity or impact but the existence of a workaround.

• Major– Usually reserved for performance issues. Anything that seriously hampers productivity but doesn’t actually prevent work from being done. Such bugs can be fixed by the next release.

• Minor– These are smaller ‘nusiance’ bugs. Examples of this type of bugs include: a default setting not being applied correctly, or a read-only field showing as editable, or a misleading error message, and so on. These bugs should be fixed in a release if there are no higher-priority issues.

• Trivial– Cosmetic issues. Majority of these are UI/UX related issues, including typos, alignment, spacing, layout related issues. These get fixed if the fix only takes a few minutes and someone is working on that part of the application. No guarantee is attached to these.

Any reported bugs will be triaged and prioritized after consultation with the stakeholders and necessary actions will be taken depending on the above-mentioned severity.

So there you go! This is our simple SCRUM based Software Development Process and our Bug Tracking process as it pertains to the priorities.