Our approach to product development is Agile.
We do not however implement fully any existing framework like SCRUM or KANBAN. We take out a few things from each of them and check. We implement only those which improve our productivity.
The diagram above shows Software Development Life Cycle in Dataedo.
As you can see on the diagram, we split our SDLC into few phases.
We are planning development for up to 12 months. This kind of plan is done without going into details. We are using the ICE scoring model.
Plans are shared with the clients through our Roadmap. Plans however are not commitments. We understand that what today seems to be certain, might change in the future.
We gather feedback and requirements from multiple sources:
Our clients. We talk with clients on daily basis. We do our best to figure out:
- What problems are our clients trying to solve?
- What solution do they imagine?
- What do they see we are missing?
- What did they like about the new features (and what we can improve)?
Our strategy. It’s sometimes challenging to merge clients’ requirements with our point of view, that’s why we constantly ask ourselves if an imaginary solution fits into our strategy?
Competition and market. We keep our fingers on the pulse and check what others are doing. Technically we are gathering all Ideas in our Project Management tool, which is JIRA.
We start with high-level design, where we prepare a basic description of functionality and the first mockups in Figma. There are multiple iterations of this part.
When we are happy with the high-level design, we then add low-level details to it, like:
- Database architecture
- Detailed tasks description
- Clickable mockups
Estimation and technical validation
The technical solution is discussed with other developers, before implementation. We are doing this to both avoid errors and use the best design pattern for the case. In this phase, we are also scheduling delivery and organizing tasks in JIRA.
During the implementation, we use distributed version control system GIT. Before merging to the main branch, each change is reviewed in terms of code quality. We have also our own code style guide to keep the code clean and clear. To keep the quality we create unit tests, that are automatically run during the build process. The application build process is also automated. We have a set of scripts, that allow us to avoid mistakes in repetitive activities.
What is important is that during development we are adapting the scope, based on new discoveries, and sometimes repeating the Design phase.
Each new feature is tested by our QA team. The QA team also creates test documentation (test cases), according to which we can verify quality and correctness. Before releasing a new version of our product, we do regression tests, that check the correctness of the previously existing functionalities
When the release is prepared, we publish the new version of the software on our page.
The release also means that we are publishing updated repository schema and updating articles in our knowledge base .
Last but not least, we update our clients (with mailing and webinars) and instantly start gathering feedback on just-released software.
We often release new features in minimum viable scope and improve them in later releases, because we believe that frequent validation and adaptation is a key for successful product development.
So we repeat above process in order to constantly improve our Product.